ALT-BU-2022-6785-26
Branch p10 update bulletin.
Package kernel-image-rpi-un updated to version 6.0.2-alt1 for branch p10 in task 308735.
Closed vulnerabilities
Modified: 2024-09-30
BDU:2022-03162
Уязвимость функции ath9k_htc_wait_for_target драйвера беспроводного адаптера Atheros ядра операционной системы Linux, позволяющая нарушителю получить доступ к памяти ядра, что может привести к сбою системы или утечке внутренней информации ядра
Modified: 2023-03-15
BDU:2022-04090
Уязвимость функции nft_set_desc_concat_parse() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
Modified: 2024-09-30
BDU:2022-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-04686
Уязвимость модуля nfnetlink_queue ядра операционных систем Linux, связанная с некорректной обработкой вердиктов с однобайтным атрибутом nfta_payload, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-13
BDU:2022-04725
Уязвимость функции clear_bss ядра операционных систем Linux, связанная с ошибками при очистке начального символа блока (.bss), позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-04733
Уязвимость функция nft_set_elem_init файла net/netfilter/nf_tables_api.c компонента User Namespace Handler ядра операционной системы Linux, позволяющая нарушителю получить root доступ
Modified: 2024-09-30
BDU:2022-04876
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-04878
Уязвимость ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-04-03
BDU:2022-04965
Уязвимость подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-10-22
BDU:2022-05140
Уязвимость подсистемы netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код.
Modified: 2024-12-05
BDU:2022-05178
Уязвимость функции route4_change (net/sched/cls_route.c) ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код или вызвать аварийное завершение работы приложения
Modified: 2023-11-13
BDU:2022-05539
Уязвимость функции pxa3xx_gcu_write ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-05633
Уязвимость компонента POSIX CPU ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-07
BDU:2022-05654
Уязвимость компонента drivers/firmware/efi/capsule-loader.c ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-05664
Уязвимость функции xfrm_expand_policies (net/xfrm/xfrm_policy.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-05-06
BDU:2022-06024
Уязвимость функции ismt_access() драйвера i2c-ismt ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-06029
Уязвимость функций dvb_demux_open() и dvb_dmxdev_release() драйвера модуля dvb-core ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-06054
Уязвимость функции stex_queuecommand_lck() ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-06-19
BDU:2022-06056
Уязвимость функции bpf_sys_bpf() подсистемы BPF ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-24
BDU:2022-06169
Уязвимость функции unmap_mapping_range (include/asm-generic/tlb.h) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-06170
Уязвимость функции SNDCTL_DSP_SYNC ioctl звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-06228
Уязвимость функции roccat_report_event (drivers/hid/hid-roccat.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2022-06272
Уязвимость функции cfg80211_update_notlisted_nontrans файла net/wireless/scan.c ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2022-06273
Уязвимость функционала подсчета ссылок в режиме BSS (Basic Service Set) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2022-06274
Уязвимость ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2022-06616
Уязвимость функции devlink_param_set/devlink_param_get (net/core/devlink.c) компонента IPsec ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-06903
Уязвимость компонента net/rose/rose_timer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-19
BDU:2022-07314
Уязвимость драйвера xen-netback ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-07345
Уязвимость функции постановки в очередь sch_sfb ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-07348
Уязвимость функции kcm_tx_work() (net/kcm/kcmsock.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-07349
Уязвимость драйвера drivers/usb/mon/mon_bin.c ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2022-07350
Уязвимость функционала подсчета ссылок в режиме BSS (Basic Service Set) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-07351
Уязвимость ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2023-12-26
BDU:2022-07354
Уязвимость ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-13
BDU:2022-07355
Уязвимость функции bpf_tail_call() подсистемы BPF ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к данным
Modified: 2023-12-20
BDU:2022-07356
Уязвимость драйвера drivers/char/pcmcia/synclink_cs.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-07357
Уязвимость драйвера drivers/video/fbdev/smscufx.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-07365
Уязвимость подсистемы XFRM ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код, вызвать отказ в обслуживании или оказать другое воздействие на систему
Modified: 2024-09-30
BDU:2022-07401
Уязвимость функции smb2_tree_disconnect (fs/ksmbd/smb2pdu.c) модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-01-10
BDU:2022-07480
Уязвимость функции smb2_write (fs/ksmbd/smb2pdu.c) модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2024-06-10
BDU:2022-07502
Уязвимость подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-06-10
BDU:2022-07503
Уязвимость подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю удалённо вызывать отказ в обслуживании
Modified: 2023-12-26
BDU:2022-07504
Уязвимость подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-10
BDU:2022-07512
Уязвимость функции smb2_write (fs/ksmbd/smb2pdu.c) модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2024-06-19
BDU:2023-00153
Уязвимость функции kfree_skb() драйвера xen-netback ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-08-14
BDU:2023-00360
Уязвимость сетевой файловой системы Network File System (NFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-19
BDU:2023-00456
Уязвимость функции read_bbreg_hdl() в модуле drivers/staging/rtl8712/rtl8712_cmd.c Wi-Fi драйвера rtl8712 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-00631
Уязвимость функции nilfs_new_inode компонента BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-01199
Уязвимость подсистемы USB модуля drivers/usb/core/hub.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-01207
Уязвимость функции nf_tables_updtable (nf_tables_api.c) межсетевого экрана ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2023-01213
Уязвимость функции malidp_check_pages_threshold() (drivers/gpu/drm/arm/malidp_planes.c) драйвера Mali-DP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-01-29
BDU:2023-01283
Уязвимость компонента net/unix/diag.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-01301
Уязвимость подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или, возможно, выполнить произвольный код
Modified: 2024-06-18
BDU:2023-02348
Уязвимость драйвера netdevsim ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-02363
Уязвимость функции verity_ctr() в модуле drivers/md/dm-verity-target.c подсистемы device-mapper ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код и подключить уязвимое оборудование
Modified: 2025-01-29
BDU:2023-02397
Уязвимость функции udmabuf_vm_fault() в модуле drivers/dma-buf/udmabuf.c ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код
Modified: 2024-03-01
BDU:2023-02408
Уязвимость функции virt_to_bus()/bus_to_virt() драйвера dpt_i2o ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-01-29
BDU:2023-02525
Уязвимость реализации протокола sctp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02628
Уязвимость функции ext4_xattr_set_entry() в модуле fs/ext4/xattr.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных
Modified: 2024-06-10
BDU:2023-02634
Уязвимость функции x86_emulate_insn компонента arch/x86/kvm/emulate.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02738
Уязвимость функции kvm_steal_time_set_preempted() в модуле arch/x86/kvm/x86.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2026-01-20
BDU:2023-03163
Уязвимость функции prepare_to_relocate() в модуле fs/btrfs/relocation.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2023-03728
Уязвимость функции seg6_genl_sethmac ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-10-02
BDU:2023-03780
Уязвимость реализации протокола Amateur Radio X.25 PLP (Rose) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-30
BDU:2023-04272
Уязвимость функции idt77252_exit() в модуле drivers/atm/idt77252.c сетевого драйвера ATM idt77252 операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-06-04
BDU:2023-04898
Уязвимость функции btrfs_get_dev_args_from_path() в модуле fs/btrfs/volumes.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю с повышенными привилегиями оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-04901
Уязвимость функции dbFree() в модуле fs/jfs/jfs_dmap.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-07631
Уязвимость драйвера файловой системы NILFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-06-04
BDU:2023-08897
Уязвимость функции free_pipe_info файла fs/pipe.c ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-24
BDU:2023-09094
Уязвимость компонента net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-00582
Уязвимость функции wb_inode_writeback_end() в модуле mm/page-writeback.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01697
Уязвимость функции i2c_put_adapter() драйвера шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-08-16
BDU:2024-03709
Уязвимость функции context_close() в модуле drivers/gpu/drm/i915/gem/i915_gem_context.c драйвера Intel 8xx/9xx/G3x/G4x/HD Graphics ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-08-16
BDU:2024-03710
Уязвимость функции flush_all_cpus_locked() в модуле mm/slub.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-03711
Уязвимость функции scmi_domain_reset() в модуле drivers/firmware/arm_scmi/reset.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-03756
Уязвимость функции mctp_sk_unhash() в модуле net/mctp/af_mctp.c реализации протокола MCTP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04150
Уязвимость компоненты io_uring ядра операционной системы Linux в функции io_msg_ring(), позволяющая нарушителю повысить свои привилегии
BDU:2024-04154
Уязвимость функции damon_sysfs_add_target() в модуле mm/daemon/sysfs.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-18
BDU:2024-04235
Уязвимость функции amu_fie_setup() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-04571
Уязвимость функции adev_release() драйвера Platform Environment Control Interface (PECI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-16
BDU:2024-04572
Уязвимость функции unflatten_dt_nodes() драйвера Device Tree ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-10
BDU:2024-04573
Уязвимость функции erofs_workgroup_unfreeze() файловой системы EROFS (Enhanced Read-Only File System) ядра операционной системы Linux в однопроцессороной конфигурации, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-08-16
BDU:2024-04574
Уязвимость функции nvme_tcp_io_work() драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-08-16
BDU:2024-04586
Уязвимость функции tcp_build_frag() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-10
BDU:2024-06284
Уязвимость функции kmalloc() в компоненте mm/slub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06310
Уязвимость компонента gpio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06320
Уязвимость функции of_xudma_dev_get() в компоненте dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06335
Уязвимость функции request_threaded_irq() в компоненте gpiolib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06336
Уязвимость компонента ipvlan ядра операционной системы Linux, позволяющая нарушителю оказывать воздействие на целостность и доступность системы
Modified: 2024-10-10
BDU:2024-06337
Уязвимость функции nf_osf_find() в компоненте netfilter ядра операционной системы Linux, позволяющая нарушителю оказывать воздействие на конфиденциальность системы
Modified: 2024-10-10
BDU:2024-06338
Уязвимость функции mmput() в компоненте IB/core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06339
Уязвимость функции brcmstb_pm_probe() в компоненте brcmstb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06340
Уязвимость компонента RDMA/srp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06341
Уязвимость функции ft_chain_release_hook() в компоненте netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06342
Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06343
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-08-19
BDU:2024-07839
Уязвимость компонента vt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-08072
Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08078
Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-27
BDU:2024-09375
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09392
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09710
Уязвимость компонентов drm/radeon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09713
Уязвимость компонента mpt3sas ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-25
BDU:2024-09760
Уязвимость компонента emu10k1 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09762
Уязвимость компонента usb-audio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09766
Уязвимость компонентов sched/debug ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-01-20
BDU:2024-09860
Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-25
BDU:2024-09918
Уязвимость компонентов s390/dasd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-09986
Уязвимость компонента mt7921e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-09987
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10000
Уязвимость компонента spi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10011
Уязвимость компонента qla2xxx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10013
Уязвимость компонента sfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10014
Уязвимость компонента sfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10015
Уязвимость компонента enetc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10016
Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10018
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10020
Уязвимость компонента bonding ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10021
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-02-24
BDU:2024-10022
Уязвимость в функции cgroup_get_from_id() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10023
Уязвимость компонента bnxt ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-24
BDU:2024-10024
Уязвимость компонента fsdax ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10025
Уязвимость компонентов drm/gma500 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10026
Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04335
Уязвимость функции find_css_set() модуля kernel/cgroup/cgroup.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-04336
Уязвимость функции nft_unregister_flowtable_type() модуля include/net/netfilter/nf_tables.h ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-04416
Уязвимость функции ___slab_alloc() модуля mm/slub.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04417
Уязвимость функции igb_clean_tx_ring() модуля drivers/net/ethernet/intel/igb/igb_main.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04419
Уязвимость функции __mptcp_close_ssk() модуля net/mptcp/protocol.c реализации протокола MPTCP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04420
Уязвимость функции bond_3ad_unbind_slave() модуля drivers/net/bonding/bond_3ad.c - драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-04421
Уязвимость функции cleanup_srcu_struct() модуля kernel/rcu/srcutree.c подсистемы синхронизации в многопоточных системах ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04422
Уязвимость функции efx_ef10_pci_sriov_disable() модуля drivers/net/ethernet/sfc/ef10_sriov.c - драйвера поддержки сетевых адаптеров Ethernet Solarflare ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04449
Уязвимость функции int3400_setup_gddv() модуля drivers/thermal/intel/int340x_thermal/int3400_thermal.c - драйвера управления температурой ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04472
Уязвимость функции iio_sysfs_trigger_remove() модуля drivers/iio/trigger/iio-trig-sysfs.c - драйвера поддержки различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-04473
Уязвимость функции tipc_exit_net() модуля net/tipc/core.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-09669
Уязвимость модулей net/bluetooth/eir.c и net/bluetooth/mgmt.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-12488
Уязвимость функций ndo_uninit(), dev->priv_destructor() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12804
Уязвимость модуля fs/nilfs2/segment.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14243
Уязвимость функции efx_siena_hard_start_xmit() модуля drivers/net/ethernet/sfc/siena/tx.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14244
Уязвимость функции smb3_insert_range() модуля fs/cifs/smb2ops.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
BDU:2025-14245
Уязвимость функции smb3_collapse_range() модуля fs/cifs/smb2ops.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2025-14249
Уязвимость функции __ext4_ext_check() модуля fs/ext4/extents.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14250
Уязвимость функции smcr_link_init() модуля net/smc/smc_core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-25
BDU:2025-14566
Уязвимость функции crtc_debugfs_init() модуля drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-14601
Уязвимость функции __nvmet_req_complete() модуля drivers/nvme/target/core.c драйвера поддержки NVME ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-15323
Уязвимость функции psb_gem_free_object() модуля drivers/gpu/drm/gma500/gem.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-26
BDU:2025-16079
Уязвимость функции write_same() драйвера SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01252
Уязвимость функции ext4_bmap() модуля fs/ext4/inode.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01259
Уязвимость функции binder_inc_ref_for_node() модуля drivers/android/binder.c драйвера связи с Android ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01341
Уязвимость функции SMB2_negotiate() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01504
Уязвимость функции pot_hole() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01510
Уязвимость функции __ieee80211_scan_completed() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01514
Уязвимость функции optc1_enable_optc_clock() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01516
Уязвимость функции convert___skb_to_skb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01520
Уязвимость функции usb_udc_uevent() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01521
Уязвимость функций ext4_mb_clear_bb() и ext4_free_blocks() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01522
Уязвимость функции raid5_end_write_request() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01523
Уязвимость функций lpfc_debugfs_multixripools_write() и lpfc_debugfs_nvmestat_write() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01524
Уязвимость функции prepare_to_relocate() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01546
Уязвимость функции attempt_restore_of_faulty_devices() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01549
Уязвимость функций scpi_init_versions() и scpi_probe() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01550
Уязвимость функций usbnet_stop() и usbnet_disconnect() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01558
Уязвимость функции meson_encoder_hdmi_init() модуля drivers/gpu/drm/meson/meson_encoder_hdmi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02021
Уязвимость функции ieee80211_ibss_finish_csa() в модуле net/mac80211/ibss.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02022
Уязвимость функции attach_default_qdiscs() в модуле net/sched/sch_generic.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02023
Уязвимость функции ovs_dp_cmd_new() в модуле net/openvswitch/datapath.c поддержки маршрутизаторов Open vSwitch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02024
Уязвимость функции udmabuf_dev_init() в модуле drivers/dma-buf/udmabuf.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02025
Уязвимость функции record_func_key() в модуле kernel/bpf/verifier.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02026
Уязвимость функции storvsc_probe() в модуле drivers/scsi/storvsc_drv.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02027
Уязвимость функции hugetlb_mcopy_atomic_pte() в модуле mm/hugetlb.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02028
Уязвимость функции wb_inode_writeback_end() в модуле fs/fs-writeback.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02031
Уязвимость функции dma_resv_add_fence() в модуле drivers/dma-buf/dma-resv.c 2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02036
Уязвимость функции enter_rtas() в модуле arch/powerpc/kernel/rtas_entry.S ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02037
Уязвимость функции check_func_arg() в модуле kernel/bpf/verifier.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02060
Уязвимость функции tgl_get_bw_info() в модуле drivers/gpu/drm/i915/display/intel_bw.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02180
Уязвимость функции inode_init_always() в модуле fs/inode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02204
Уязвимость функции common() модуля arch/x86/kernel/asm-offsets.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02206
Уязвимость функции rt700_jack_detect_handler() модуля sound/soc/codecs/rt700.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02226
Уязвимость функции mpol_rebind_preferred() модуля mm/mempolicy.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02227
Уязвимость функции spectre_v2_select_mitigation() модуля arch/x86/kernel/cpu/bugs.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02228
Уязвимость функции mc_probe() модуля sound/soc/intel/boards/sof_sdw.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02229
Уязвимость функции tipc_sk_create() модуля net/tipc/socket.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02231
Уязвимость функции raid5_add_disk() модуля drivers/md/raid5.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02252
Уязвимость функции xive_irq_bitmap_add() модуля arch/powerpc/sysdev/xive/spapr.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02253
Уязвимость функции validate_region_size() модуля drivers/md/dm-raid.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02254
Уязвимость функций con_font_set() и con_font_default() в модуле drivers/tty/vt/vt.c драйвера виртуального терминала консоли ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02255
Уязвимость функции raid_status() в модуле drivers/md/dm-raid.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02256
Уязвимость функции put_entry() в модуле security/selinux/ss/policydb.h ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02257
Уязвимость функции raid10_remove_disk() в модуле drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02281
Уязвимость функции k3_r5_cluster_of_init() в модуле drivers/remoteproc/ti_k3_r5_remoteproc.c драйвера подсистемы удаленного процессора ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02337
Уязвимость функций sg_read() и sg_get_rq_mark() в модуле drivers/scsi/sg.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02345
Уязвимость функции usb_reset_device() в модуле drivers/usb/core/hub.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02346
Уязвимость функции mceusb_gen1_init() в модуле drivers/media/rc/mceusb.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02356
Уязвимость функции ftrace_startup() в модуле kernel/trace/ftrace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02359
Уязвимость макроопределения rcu_assign_sk_user_data_nocopy() в модуле include/net/sock.h поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02360
Уязвимость функции hidraw_release() в модуле drivers/hid/hidraw.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02361
Уязвимость функции pvr2_hdw_create() в модуле drivers/media/usb/pvrusb2/pvrusb2-hdw.c драйвера мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02362
Уязвимость функции loop_set_status_from_info() в модуле drivers/block/loop.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02364
Уязвимость функций hda_dsp_ipc4_irq_thread() и hda_dsp_ipc_irq_thread() в модуле sound/soc/sof/intel/hda-ipc.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02365
Уязвимость функций cnl_ipc4_irq_thread() и cnl_ipc_irq_thread() в модуле sound/soc/sof/intel/cnl.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02366
Уязвимость функции ext4_resize_fs() в модуле fs/ext4/resize.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02369
Уязвимость функции gaudi_parse_cb_no_ext_queue() в модуле drivers/misc/habanalabs/gaudi/gaudi.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-02561
Уязвимость функции memory_info_update() в модуле sound/soc/sof/debug.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02571
Уязвимость функции rxrpc_send_data() в модуле net/rxrpc/sendmsg.c поддержки сокетов сеанса RxRPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02572
Уязвимость функции nf_flow_table_free() в модуле net/netfilter/nf_flow_table_core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02573
Уязвимость функции nft_tproxy_dump() в модуле net/netfilter/nft_tproxy.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02574
Уязвимость функции ice_xsk_pool_setup() в модуле drivers/net/ethernet/intel/ice/ice_xsk.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02575
Уязвимость функции pn532_uart_remove() в модуле drivers/nfc/pn533/uart.c драйвера NFC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02576
Уязвимость функции cdns3_wa2_remove_old_request() в модуле drivers/usb/cdns3/cdns3-gadget.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02577
Уязвимость функции qcom_mhi_qrtr_probe() в модуле net/qrtr/mhi.c поддержки маршрутизаторов Qualcomm IPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02578
Уязвимость функции hda_dsp_dump_ext_rom_status() в модуле sound/soc/sof/intel/hda.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02579
Уязвимость функции iavf_reset_task() в модуле drivers/net/ethernet/intel/iavf/iavf_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02580
Уязвимость функций iavf_init_asq() и iavf_init_arq() в модуле drivers/net/ethernet/intel/iavf/iavf_adminq.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02581
Уязвимость функции qat_dh_compute_value() модуля drivers/crypto/qat/qat_common/qat_asym_algs.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02582
Уязвимость функции early_init_devtree() в модуле arch/powerpc/kernel/prom.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02583
Уязвимость функции fastrpc_cb_probe() в модуле drivers/misc/fastrpc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02624
Уязвимость функции pmac_cpufreq_init_MacRISC3() модуля drivers/cpufreq/pmac32-cpufreq.c - драйвера поддержки масштабирования частоты ЦП ядра операционной системы 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-02646
Уязвимость функции kvm_ioctl_create_device() модуля virt/kvm/kvm_main.c подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02651
Уязвимость функции qat_rsa_enc() модуля drivers/crypto/qat/qat_common/qat_asym_algs.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02652
Уязвимость функции gpio_fan_set_cur_state() в модуле drivers/hwmon/gpio-fan.c драйвера мониторинга оборудования ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02653
Уязвимость функции raspberrypi_discover_clocks() в модуле drivers/clk/bcm/clk-raspberrypi.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-02655
Уязвимость функции fastrpc_cb_probe() в модуле drivers/misc/fastrpc.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02656
Уязвимость функций iforce_serio_xmit() и iforce_serio_irq() в модуле drivers/input/joystick/iforce/iforce-serio.c драйвера устройств ввода ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02657
Уязвимость функции cmd_hdl_filter() в модуле drivers/staging/rtl8712/rtl8712_cmd.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02658
Уязвимость функции kcm_attach() в модуле net/kcm/kcmsock.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02659
Уязвимость функции adf7242_remove() в модуле drivers/net/ieee802154/adf7242.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02660
Уязвимость функции f2fs_new_node_page() в модуле fs/f2fs/node.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02662
Уязвимость функции sun6i_dsi_setup_timings() в модуле drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02663
Уязвимость функции sja1105_setup_devlink_regions() в модуле drivers/net/dsa/sja1105/sja1105_devlink.c драйвера коммутаторов семейства NXP SJA1105 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02664
Уязвимость функции mv88e6060_setup_port() в модуле drivers/net/dsa/mv88e6060.c драйвера DSA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02665
Уязвимость функции vt8623fb_set_par() в модуле drivers/video/fbdev/vt8623fb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02764
Уязвимость функции ttm_bo_validate() модуля drivers/gpu/drm/ttm/ttm_bo.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02791
Уязвимость функции meson_vpu_has_available_connectors() модуля drivers/gpu/drm/meson/meson_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02799
Уязвимость функции can_follow_write_pte() (mm/gup.c) и can_follow_write_pmd() (mm/huge_memory.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02800
Уязвимость функций steam_recv_report() и steam_send_report() модуля drivers/hid/hid-steam.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02801
Уязвимость функций lock_pages() и privcmd_ioctl_dm_op() модуля drivers/xen/privcmd.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02802
Уязвимость функции afu_allocate_irqs() модуля drivers/misc/cxl/irq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02803
Уязвимость функции dcn303_stream_encoder_create() модуля drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02804
Уязвимость функции csdlock_debug() модуля kernel/smp.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02805
Уязвимость функции dm_pool_register_metadata_threshold() модуля drivers/md/dm-thin-metadata.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02806
Уязвимость функции dmar_parse_one_rhsa() модуля drivers/iommu/intel/dmar.c драйвера IOMMU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02807
Уязвимость функции begin_new_exec() модуля fs/exec.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02808
Уязвимость функции set_current_kprobe() модуля arch/x86/kernel/kprobes/core.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02809
Уязвимость функции qla2x00_eh_wait_for_pending_commands() модуля drivers/scsi/qla2xxx/qla_os.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02810
Уязвимость функции arkfb_set_par() модуля drivers/video/fbdev/arkfb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02811
Уязвимость функции arkfb_set_par() модуля drivers/video/fbdev/arkfb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02812
Уязвимость функции __graph_get_type() модуля sound/soc/generic/audio-graph-card2.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02813
Уязвимость функции task_can_attach() модуля kernel/sched/core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02814
Уязвимость функции sof_ipc3_control_load_bytes() модуля sound/soc/sof/ipc3-topology.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02815
Уязвимость функций hisi_acc_vfio_pci_open_device() и hisi_acc_vfio_pci_close_device() модуля drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c драйвера устройств VFIO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03106
Уязвимость функции vc_uniscr_alloc() модуля drivers/tty/vt/vt.c драйвера виртуального терминала консоли ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03107
Уязвимость функции security_read_state_kernel() модуля security/selinux/ss/services.c подсистемы обеспечения безопаности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03123
Уязвимость функции intel_eth_pci_remove() модуля drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c драйвера сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03124
Уязвимость функции msb_data_clear() модуля drivers/memstick/core/ms_block.c драйвера карт Sony MemoryStick ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03125
Уязвимость функции sienna_cichlid_set_ppt_funcs() модуля drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03126
Уязвимость функции pure_initcall() модуля kernel/bpf/core.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03129
Уязвимость функций copy_from_bpfptr_offset() и strncpy_from_bpfptr() модуля include/linux/bpfptr.h ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03130
Уязвимость функции joycon_set_rumble() модуля drivers/hid/hid-nintendo.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03131
Уязвимость функции chuwi_hi8_init() модуля drivers/platform/x86/x86-android-tablets.c драйвера устройств X86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03132
Уязвимость функции md_stop() модуля drivers/md/md.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03133
Уязвимость функций arch_dup_task_struct() и copy_thread() модуля arch/s390/kernel/process.c поддержки платформы S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03134
Уязвимость функции btrfs_get_dev_args_from_path() модуля fs/btrfs/volumes.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03178
Уязвимость функций aq_nic_service_timer_cb() и aq_nic_get_stats() модуля drivers/net/ethernet/aquantia/atlantic/aq_nic.c драйвера сетевых адаптеров Ethernet с чипсетом aQuantia Atlantic ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03179
Уязвимость функции __driver_attach() модуля drivers/base/dd.c драйвера шинных устройства ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03180
Уязвимость функции __kernfs_remove() модуля fs/kernfs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03240
Уязвимость функции xrx200_alloc_buf() модуля drivers/net/ethernet/lantiq_xrx200.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03249
Уязвимость функции reuseport_stop_listen_sock() модуля net/core/sock_reuseport.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03251
Уязвимость функции get_nodes() модуля mm/mempolicy.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03252
Уязвимость функций sf_pdma_alloc_desc() и sf_pdma_desc_residue() модуля drivers/dma/sf-pdma/sf-pdma.c драйвера движка DMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03253
Уязвимость функций __msc_buffer_win_free() и msc_buffer_get_page() модуля drivers/hwtracing/intel_th/msu.c драйвера трассировки HW ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03254
Уязвимость функции irdma_destroy_cq() модуля drivers/infiniband/hw/irdma/verbs.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03255
Уязвимость функции siw_proc_mpareply() модуля drivers/infiniband/sw/siw/siw_cm.c драйвера Infiniband ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03257
Уязвимость функции mcp_smbus_write() модуля drivers/hid/hid-mcp2221.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03261
Уязвимость функции power_pmu_disable() модуля arch/powerpc/perf/core-book3s.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03262
Уязвимость функции jbd2_journal_dirty_metadata() модуля fs/jbd2/transaction.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03263
Уязвимость функций rxe_qp_init_misc() и rxe_qp_init_req() модуля drivers/infiniband/sw/rxe/rxe_qp.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03264
Уязвимость функции fbtft_framebuffer_alloc() модуля drivers/staging/fbtft/fbtft-core.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03265
Уязвимость функции snd_pcm_oss_sync() модуля sound/core/oss/pcm_oss.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03290
Уязвимость функции proc_dou8vec_minmax() модуля kernel/sysctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03373
Уязвимость функций cifs_close_deferred_file() и cifs_close_all_deferred_files() модуля fs/cifs/misc.c файловой системы cifs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03374
Уязвимость функции soc_info() модуля drivers/tty/serial/ucc_uart.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03375
Уязвимость функций mptcp_sendmsg_frag() и mptcp_subflow_get_send() модуля net/mptcp/protocol.c реализации протокола MPTCP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03376
Уязвимость функции __xfrm_policy_check() модуля net/xfrm/xfrm_policy.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03377
Уязвимость функции __nfs42_ssc_open() модуля fs/nfs/nfs4file.c поддержки клиентов NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03378
Уязвимость функции btrfs_cache_block_group() модуля fs/btrfs/block-group.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03396
Уязвимость функции xive_get_max_prio() модуля arch/powerpc/sysdev/xive/spapr.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03397
Уязвимость функций trace_spmi_write_begin() и trace_spmi_read_end() модуля include/trace/events/spmi.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03398
Уязвимость функций get_eprobe_size() и process_fetch_insn() модуля kernel/trace/trace_eprobe.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03399
Уязвимость функций btrfs_split_delalloc_extent() и btrfs_merge_delalloc_extent() модуля fs/btrfs/inode.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03400
Уязвимость функции ice_reset_vf() модуля drivers/net/ethernet/intel/ice/ice_vf_lib.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03401
Уязвимость функции netlink_policy_dump_add_policy() модуля net/netlink/policy.c поддержки интерфейса мониторинга сокетов NETLINK ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03403
Уязвимость функции ohci_hcd_ppc_of_probe() модуля drivers/usb/host/ohci-ppc-of.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03404
Уязвимость функции lpfc_issue_cmf_sync_wqe() модуля drivers/scsi/lpfc/lpfc_sli.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03405
Уязвимость функции dw_axi_dma_chan_slave_config() модуля drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c драйвера движка DMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03456
Уязвимость функции spufs_init_isolated_loader() модуля arch/powerpc/platforms/cell/spufs/inode.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03460
Уязвимость функции setup_msi_msg_address() модуля arch/powerpc/platforms/cell/axon_msi.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03463
Уязвимость функции cifs_readahead() модуля fs/cifs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03468
Уязвимость функции max77620_initialise_fps() модуля drivers/mfd/max77620.c драйвера контроллера многофункциональных устройств (MFD) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03470
Уязвимость функции clcdfb_of_init_display() модуля drivers/video/fbdev/amba-clcd.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03471
Уязвимость функции sp5100_tco_setupdevice_mmio() модуля drivers/watchdog/sp5100_tco.c поддержки сторожевого таймера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03472
Уязвимость функций mt6359_accdet_parse_dt() и mt6359_parse_dt() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03473
Уязвимость функций parse_probe_vars() и parse_probe_arg() модуля kernel/trace/trace_probe.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03474
Уязвимость функции aa_pivotroot() модуля security/apparmor/mount.c компонента обеспечения безопасности AppArmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03476
Уязвимость функции qcom_smd_parse_edge() модуля drivers/rpmsg/qcom_smd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03478
Уязвимость функции rpc_sysfs_xprt_state_change() модуля net/sunrpc/sysfs.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03479
Уязвимость функции nft_set_elem_expr_clone() модуля net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03481
Уязвимость функции ndisc_router_discovery() модуля net/ipv6/ndisc.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03482
Уязвимость функции handle_cap_grant() модуля fs/ceph/caps.c поддержки распределенной файловой системы Ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03698
Уязвимость функции be_cmd_read_port_transceiver_data() модуля drivers/net/ethernet/emulex/benet/be_cmds.c драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03699
Уязвимость функции ixgbe_sw_init() модуля drivers/net/ethernet/intel/ixgbe/ixgbe_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03700
Уязвимость функции igc_rd32() модуля drivers/net/ethernet/intel/igc/igc_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03701
Уязвимость функции irdma_cm_teardown_connections() модуля drivers/infiniband/hw/irdma/cm.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03702
Уязвимость функции atl_resume_common() модуля drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c драйвера поддержки сетевых адаптеров Ethernet с чипсетом aQuantia Atlantic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03703
Уязвимость функции bam_alloc_chan() модуля drivers/dma/qcom/bam_dma.c драйвера поддержки движка DMA ядра операционной системы Linux, позволяющая удаленному нарушителю вызвать отказ в обслуживании
BDU:2026-03704
Уязвимость функции __reg_bound_offset() модуля kernel/bpf/verifier.c поддержки интерпретатора BPF ядра операционной системы 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-03734
Уязвимость функции cdns3_allocate_trb_pool() модуля drivers/usb/cdns3/cdns3-gadget.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03736
Уязвимость функции ath9k_htc_probe_device() модуля drivers/net/wireless/ath/ath9k/htc_drv_init.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03750
Уязвимость функции cp2112_xfer() модуля drivers/hid/hid-cp2112.c драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03874
Уязвимость функции sk_psock_init() модуля net/core/skmsg.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03875
Уязвимость функции m_can_read_fifo() модуля drivers/net/can/m_can/m_can.c драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03877
Уязвимость функции serial8250_register_ports() модуля drivers/tty/serial/8250/8250_core.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03878
Уязвимость функции uvcg_video_pump() модуля drivers/usb/gadget/function/uvc_video.c драйвера поддержки гаджетов USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03891
Уязвимость функции tun_detach_all() модуля drivers/net/tun.c драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03897
Уязвимость функции ibmvfc_init_sub_crqs() модуля drivers/scsi/ibmvscsi/ibmvfc.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03902
Уязвимость функции efx_ef10_try_update_nic_stats_vf() модуля drivers/net/ethernet/sfc/ef10.c драйвера поддержки сетевых адаптеров Ethernet Solarflare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03907
Уязвимость функции panfrost_ioctl_madvise() модуля drivers/gpu/drm/panfrost/panfrost_drv.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03915
Уязвимость функции power_supply_temp2resist_simple() модуля drivers/power/supply/power_supply_core.c драйвера поддержки управления питанием ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03987
Уязвимость функции fscache_perform_lookup() модуля fs/fscache/cookie.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03995
Уязвимость функции close_ctree() модуля fs/btrfs/disk-io.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03996
Уязвимость функции __bpf_sk_lookup() модуля net/core/filter.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03997
Уязвимость функции filemap_get_read_batch() модуля mm/filemap.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03998
Уязвимость функции tick_nohz_full_setup() модуля kernel/time/tick-sched.c подсистемы таймера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03999
Уязвимость функции afs_getattr() модуля fs/afs/inode.c файловой системы Andrew (AFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04000
Уязвимость функции thinkpad_acpi_amd_s2idle_restore() модуля drivers/platform/x86/thinkpad_acpi.c драйвера поддержки устройств X86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04001
Уязвимость функции in6_dump_addrs() модуля net/ipv6/addrconf.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04002
Уязвимость функции tegra_eqos_probe() модуля drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c драйвера поддержки сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04003
Уязвимость функции ingenic_mac_probe() модуля drivers/net/ethernet/stmicro/stmmac/dwmac-ingenic.c драйвера поддержки сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04046
Уязвимость функции dwmac4_map_mtl_dma() модуля drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c драйвера поддержки сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04116
Уязвимость функции nft_meta_get_eval_ifname() модуля net/netfilter/nft_meta.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04489
Уязвимость функции ttwu_queue_cond() модуля kernel/sched/core.c поддержки системы учета ресурсов ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04501
Уязвимость функции pm2fb_check_var() модуля drivers/video/fbdev/pm2fb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04502
Уязвимость функции __get_segment_type_6() и f2fs_ioc_start_atomic_write() модуля fs/f2fs/segment.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04503
Уязвимость функции i740fb_decode_var() модуля drivers/video/fbdev/i740fb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04504
Уязвимость функции core_get_v4() модуля drivers/media/platform/qcom/venus/pm_helpers.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04505
Уязвимость функции octeon2_usb_clocks_start() модуля arch/mips/cavium-octeon/octeon-platform.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04506
Уязвимость функции axi_chan_block_xfer_complete() модуля drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c драйвера движка DMA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04507
Уязвимость функции ep_io() модуля drivers/usb/gadget/legacy/inode.c драйвера гаджетов USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04508
Уязвимость функции clk_branch_wait() модуля drivers/clk/qcom/clk-branch.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04509
Уязвимость функции usbhs_rza1_hardware_init() модуля drivers/usb/renesas_usbhs/rza.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04510
Уязвимость функций blk_iocost_init() (block/blk-iocost.c) и wbt_init() (block/blk-wbt.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04511
Уязвимость функций snapshot_write() и snapshot_ioctl() модуля kernel/power/user.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04512
Уязвимость функции ext2_fill_super() модуля fs/ext2/super.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04514
Уязвимость функции emulation_proc_handler() модуля arch/arm64/kernel/armv8_deprecated.c поддержки платформы ARM 64бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04515
Уязвимость функции c_start() модуля arch/mips/kernel/proc.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04559
Уязвимость функции __disable_kprobe() модуля kernel/kprobes.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04560
Уязвимость функции xfrm_lookup_with_ifid() модуля net/xfrm/xfrm_policy.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04561
Уязвимость функции mlx5_lag_add_netdev() модуля drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04562
Уязвимость функции put_page_bootmem() модуля mm/bootmem_info.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04564
Уязвимость функции dw_pcie_ep_init() модуля drivers/pci/controller/dwc/pcie-designware-ep.c драйвера уcтройств PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04565
Уязвимость функции sdw_drv_probe() модуля drivers/soundwire/bus_type.c драйвера SoundWire ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04566
Уязвимость функции intel_th_pci_probe() модуля drivers/hwtracing/intel_th/pci.c драйвера трассировки HW ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04567
Уязвимость функции esdhc_signal_voltage_switch() модуля drivers/mmc/host/sdhci-of-esdhc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04568
Уязвимость функции ast_vhub_init_desc() модуля drivers/usb/gadget/udc/aspeed-vhub/hub.c драйвера гаджетов USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04569
Уязвимость функции __qedr_alloc_mr() модуля drivers/infiniband/hw/qedr/verbs.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04571
Уязвимость функции setup_base_ctxt() модуля drivers/infiniband/hw/hfi1/file_ops.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04572
Уязвимость функций cdns3_gadget_ep_enable() и cdns3_gadget_ep_dequeue() модуля drivers/usb/cdns3/cdns3-gadget.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04573
Уязвимость функции cros_ec_codec_platform_probe() модуля sound/soc/codecs/cros_ec_codec.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04576
Уязвимость функции mt6797_mt6351_dev_probe() модуля sound/soc/mediatek/mt6797/mt6797-mt6351.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04577
Уязвимость функции mt8173_rt5650_rt5676_dev_probe() модуля sound/soc/mediatek/mt8173/mt8173-rt5650-rt5676.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04578
Уязвимость функции mt8173_rt5650_dev_probe() модуля sound/soc/mediatek/mt8173/mt8173-rt5650.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04582
Уязвимость функции imx_rproc_addr_init() модуля drivers/remoteproc/imx_rproc.c драйвера подсистемы удаленного процессора ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04584
Уязвимость функции gsm_send() и gsm_data_kick() модуля drivers/tty/n_gsm.c драйвера консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04585
Уязвимость функции p9_read_work() модуля net/9p/trans_fd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04869
Уязвимость функции omapdss_init_fbdev() модуля arch/arm/mach-omap2/display.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04870
Уязвимость функции pdata_quirks_init_clocks() модуля arch/arm/mach-omap2/pdata-quirks.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04874
Уязвимость функции s3fb_set_par() модуля drivers/video/fbdev/s3fb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04875
Уязвимость функции bgmac_dma_tx_add() модуля drivers/net/ethernet/broadcom/bgmac.c драйвера сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04877
Уязвимость функции iavf_init_get_resources() модуля drivers/net/ethernet/intel/iavf/iavf_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04879
Уязвимость функции dpcm_get_be() модуля sound/soc/soc-pcm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04881
Уязвимость функций xp_init_dma_info() и xp_dma_map() модуля net/xdp/xsk_buff_pool.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04886
Уязвимость функций srpt_refresh_port() и srpt_cm_req_recv() модуля drivers/infiniband/ulp/srpt/ib_srpt.c драйвера сервера и клиента RTRS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04895
Уязвимость функции ntfs_update_mftmirr() модуля fs/ntfs3/fsntfs.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04896
Уязвимость функции ntfs_read_mft() модуля fs/ntfs3/inode.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04899
Уязвимость функции cm3605_probe() модуля drivers/iio/light/cm3605.c драйвера фотодатчиков ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05721
Уязвимость функции receive_mergeable() в модуле drivers/net/virtio_net.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05730
Уязвимость функции __rvu_flr_handler() в модуле drivers/net/ethernet/marvell/octeontx2/af/rvu.c драйвера сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05731
Уязвимость функций mptcp_destroy_common() и mptcp_destroy() в модуле net/mptcp/protocol.c реализации протокола MPTCP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05732
Уязвимость функции hinic_get_stats64() в модуле drivers/net/ethernet/huawei/hinic/hinic_main.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05784
Уязвимость функции ima_get_kexec_buffer() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05785
Уязвимость функции drain_workqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05786
Уязвимость функции coresight_release_platform_data() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05787
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05788
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05849
Уязвимость функции elem_size() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05850
Уязвимость функции of_find_compatible_node() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05851
Уязвимость функции isl29028_remove() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05852
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05853
Уязвимость функции neon_poly1305_blocks ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06012
Уязвимость функции reset_tdp_shadow_zero_bits_mask() в модуле arch/x86/kvm/mmu/mmu.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06047
Уязвимость функции z_erofs_lzma_head() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06048
Уязвимость функции htc_tx_completion() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06049
Уязвимость функции kunit_filter_tests() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06067
Уязвимость функции mcde_dsi_bind() в модуле drivers/gpu/drm/mcde/mcde_dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-21
CVE-2019-25162
In the Linux kernel, the following vulnerability has been resolved: i2c: Fix a potential use after free Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. [wsa: added comment to the code, added Fixes tag]
- https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c748464fe87d
- https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829
- https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7
- https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9
- https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87
- https://git.kernel.org/stable/c/e4c72c06c367758a14f227c847f9d623f1994ecf
- https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a
- https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4
- https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c748464fe87d
- https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829
- https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7
- https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9
- https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87
- https://git.kernel.org/stable/c/e4c72c06c367758a14f227c847f9d623f1994ecf
- https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a
- https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4
Modified: 2024-11-21
CVE-2021-33655
When sending malicous data to kernel by ioctl cmd FBIOPUT_VSCREENINFO,kernel will write memory out of bounds.
- http://www.openwall.com/lists/oss-security/2022/07/19/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=086ff84617185393a0bbf25830c4f36412a7d3f4
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://www.debian.org/security/2022/dsa-5191
- http://www.openwall.com/lists/oss-security/2022/07/19/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=086ff84617185393a0bbf25830c4f36412a7d3f4
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://www.debian.org/security/2022/dsa-5191
Modified: 2024-11-21
CVE-2022-1679
A use-after-free flaw was found in the Linux kernel’s Atheros wireless adapter driver in the way a user forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/lkml/87ilqc7jv9.fsf%40kernel.org/t/
- https://security.netapp.com/advisory/ntap-20220629-0007/
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/lkml/87ilqc7jv9.fsf%40kernel.org/t/
- https://security.netapp.com/advisory/ntap-20220629-0007/
Modified: 2024-11-21
CVE-2022-1852
A NULL pointer dereference flaw was found in the Linux kernel’s KVM module, which can lead to a denial of service in the x86_emulate_insn in arch/x86/kvm/emulate.c. This flaw occurs while executing an illegal instruction in guest in the Intel CPU.
Modified: 2024-11-21
CVE-2022-1882
A use-after-free flaw was found in the Linux kernel’s pipes functionality in how a user performs manipulations with the pipe post_one_notification() after free_pipe_info() that is already called. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2089701
- https://lore.kernel.org/lkml/20220507115605.96775-1-tcs.kernel%40gmail.com/T/
- https://security.netapp.com/advisory/ntap-20220715-0002/
- https://bugzilla.redhat.com/show_bug.cgi?id=2089701
- https://lore.kernel.org/lkml/20220507115605.96775-1-tcs.kernel%40gmail.com/T/
- https://security.netapp.com/advisory/ntap-20220715-0002/
Modified: 2024-11-21
CVE-2022-2078
A vulnerability was found in the Linux kernel's nft_set_desc_concat_parse() function .This flaw allows an attacker to trigger a buffer overflow via nft_set_desc_concat_parse() , causing a denial of service and possibly to run code.
- https://bugzilla.redhat.com/show_bug.cgi?id=2096178
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/nf_tables_api.c?id=fecf31ee395b0295f2d7260aa29946b7605f7c85
- https://www.debian.org/security/2022/dsa-5161
- https://bugzilla.redhat.com/show_bug.cgi?id=2096178
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/nf_tables_api.c?id=fecf31ee395b0295f2d7260aa29946b7605f7c85
- https://www.debian.org/security/2022/dsa-5161
Modified: 2025-11-10
CVE-2022-21546
In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like "sg_write_same --ndob" we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer.
- https://git.kernel.org/stable/c/4226622647e3e5ac06d3ebc1605b917446157510
- https://git.kernel.org/stable/c/54e57be2573cf0b8bf650375fd8752987b6c3d3b
- https://git.kernel.org/stable/c/ccd3f449052449a917a3e577d8ba0368f43b8f29
- https://git.kernel.org/stable/c/d8e6a27e9238dd294d6f2f401655f300dca20899
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2024-11-21
CVE-2022-2318
There are use-after-free vulnerabilities caused by timer handler in net/rose/rose_timer.c of linux that allow attackers to crash linux kernel without any privileges.
- https://github.com/torvalds/linux/commit/9cc02ede696272c5271a401e4f27c262359bc2f6
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://security.netapp.com/advisory/ntap-20230120-0001/
- https://www.debian.org/security/2022/dsa-5191
- https://github.com/torvalds/linux/commit/9cc02ede696272c5271a401e4f27c262359bc2f6
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://security.netapp.com/advisory/ntap-20230120-0001/
- https://www.debian.org/security/2022/dsa-5191
Modified: 2024-11-21
CVE-2022-2503
Dm-verity is used for extending root-of-trust to root filesystems. LoadPin builds on this property to restrict module/firmware loads to just the trusted root filesystem. Device-mapper table reloads currently allow users with root privileges to switch out the target with an equivalent dm-linear target and bypass verification till reboot. This allows root to bypass LoadPin and can be used to load untrusted and unverified kernel modules and firmware, which implies arbitrary kernel execution and persistence for peripherals that do not verify firmware updates. We recommend upgrading past commit 4caae58406f8ceb741603eee460d79bacca9b1b5
Modified: 2024-11-21
CVE-2022-2585
It was discovered that when exec'ing from a non-leader thread, armed POSIX CPU timers would be left on a list but freed, leading to a use-after-free.
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585
- https://lore.kernel.org/lkml/20220809170751.164716-1-cascardo@canonical.com/T/#u
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://www.openwall.com/lists/oss-security/2022/08/09/7
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585
- https://lore.kernel.org/lkml/20220809170751.164716-1-cascardo@canonical.com/T/#u
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://www.openwall.com/lists/oss-security/2022/08/09/7
Modified: 2025-10-28
CVE-2022-2586
It was discovered that a nft object or expression could reference a nft set on a different nft table, leading to a use-after-free once that table was deleted.
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2586
- https://lore.kernel.org/netfilter-devel/20220809170148.164591-1-cascardo@canonical.com/T/#t
- https://ubuntu.com/security/notices/USN-5557-1
- https://ubuntu.com/security/notices/USN-5560-1
- https://ubuntu.com/security/notices/USN-5560-2
- https://ubuntu.com/security/notices/USN-5562-1
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://ubuntu.com/security/notices/USN-5582-1
- https://www.openwall.com/lists/oss-security/2022/08/09/5
- https://www.zerodayinitiative.com/advisories/ZDI-22-1118/
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2586
- https://lore.kernel.org/netfilter-devel/20220809170148.164591-1-cascardo@canonical.com/T/#t
- https://ubuntu.com/security/notices/USN-5557-1
- https://ubuntu.com/security/notices/USN-5560-1
- https://ubuntu.com/security/notices/USN-5560-2
- https://ubuntu.com/security/notices/USN-5562-1
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://ubuntu.com/security/notices/USN-5582-1
- https://www.openwall.com/lists/oss-security/2022/08/09/5
- https://www.vicarius.io/vsociety/posts/use-after-free-vulnerability-linked-chain-between-nft-tables-cve-2022-2586
- https://www.zerodayinitiative.com/advisories/ZDI-22-1118/
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-2586
Modified: 2024-11-21
CVE-2022-2588
It was discovered that the cls_route filter implementation in the Linux kernel would not remove an old filter from the hashtable before freeing it if its handle had the value 0.
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588
- https://github.com/Markakd/CVE-2022-2588
- https://lore.kernel.org/netdev/20220809170518.164662-1-cascardo@canonical.com/T/#u
- https://ubuntu.com/security/notices/USN-5557-1
- https://ubuntu.com/security/notices/USN-5560-1
- https://ubuntu.com/security/notices/USN-5560-2
- https://ubuntu.com/security/notices/USN-5562-1
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://ubuntu.com/security/notices/USN-5582-1
- https://ubuntu.com/security/notices/USN-5588-1
- https://www.openwall.com/lists/oss-security/2022/08/09/6
- https://www.zerodayinitiative.com/advisories/ZDI-22-1117/
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588
- https://github.com/Markakd/CVE-2022-2588
- https://lore.kernel.org/netdev/20220809170518.164662-1-cascardo@canonical.com/T/#u
- https://ubuntu.com/security/notices/USN-5557-1
- https://ubuntu.com/security/notices/USN-5560-1
- https://ubuntu.com/security/notices/USN-5560-2
- https://ubuntu.com/security/notices/USN-5562-1
- https://ubuntu.com/security/notices/USN-5564-1
- https://ubuntu.com/security/notices/USN-5565-1
- https://ubuntu.com/security/notices/USN-5566-1
- https://ubuntu.com/security/notices/USN-5567-1
- https://ubuntu.com/security/notices/USN-5582-1
- https://ubuntu.com/security/notices/USN-5588-1
- https://www.openwall.com/lists/oss-security/2022/08/09/6
- https://www.zerodayinitiative.com/advisories/ZDI-22-1117/
Modified: 2024-11-21
CVE-2022-2590
A race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only shared memory mappings. This flaw allows an unprivileged, local user to gain write access to read-only memory mappings, increasing their privileges on the system.
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: 2026-04-14
CVE-2022-2785
There exists an arbitrary memory read within the Linux Kernel BPF - Constants provided to fill pointers in structs passed in to bpf_sys_bpf are not verified and can point anywhere, including memory not owned by BPF. An attacker with CAP_BPF can arbitrarily read memory from anywhere on the system. We recommend upgrading past commit 86f44fcec22c
Modified: 2024-11-21
CVE-2022-2873
An out-of-bounds memory access flaw was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way a user triggers the I2C_SMBUS_BLOCK_DATA (with the ioctl I2C_SMBUS) with malicious input data. This flaw allows a local user to crash the system.
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/lkml/20220729093451.551672-1-zheyuma97%40gmail.com/T/
- https://security.netapp.com/advisory/ntap-20230120-0001/
- https://www.debian.org/security/2023/dsa-5324
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/lkml/20220729093451.551672-1-zheyuma97%40gmail.com/T/
- https://security.netapp.com/advisory/ntap-20230120-0001/
- https://www.debian.org/security/2023/dsa-5324
Modified: 2024-11-21
CVE-2022-2905
An out-of-bounds memory read flaw was found in the Linux kernel's BPF subsystem in how a user calls the bpf_tail_call function with a key larger than the max_entries of the map. This flaw allows a local user to gain unauthorized access to data.
- https://bugzilla.redhat.com/show_bug.cgi?id=2121800
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/bpf/984b37f9fdf7ac36831d2137415a4a915744c1b6.1661462653.git.daniel%40iogearbox.net/
- https://bugzilla.redhat.com/show_bug.cgi?id=2121800
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/bpf/984b37f9fdf7ac36831d2137415a4a915744c1b6.1661462653.git.daniel%40iogearbox.net/
Modified: 2024-11-21
CVE-2022-2961
A use-after-free flaw was found in the Linux kernel’s PLP Rose functionality in the way a user triggers a race condition by calling bind while simultaneously triggering the rose_bind() function. This flaw allows a local user to crash or potentially escalate their privileges on the system.
Modified: 2024-11-21
CVE-2022-2978
A flaw use after free in the Linux kernel NILFS file system was found in the way user triggers function security_inode_alloc to fail with following call to function nilfs_mdt_destroy. A local user could use this flaw to crash the system or potentially escalate their privileges on the system.
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91%40hust.edu.cn/T/#u
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91%40hust.edu.cn/T/#u
Modified: 2024-11-21
CVE-2022-3028
A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously. This flaw could allow a local attacker to potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read and copying it into a socket.
- https://github.com/torvalds/linux/commit/ba953a9d89a00c078b85f4b190bc1dde66fe16b5
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/F3MYP7WX4PNE6RCITVXA43CECBZT4CL6/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JKVA75UHKVOHNOEPCLUHTFGWCOOUBDM3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PEQYVCNYUWB4CJ2YRAYNF2GGFQ7SUYC4/
- https://lore.kernel.org/all/YtoWqEkKzvimzWS5%40gondor.apana.org.au/T/
- https://security.netapp.com/advisory/ntap-20230214-0004/
- https://github.com/torvalds/linux/commit/ba953a9d89a00c078b85f4b190bc1dde66fe16b5
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/F3MYP7WX4PNE6RCITVXA43CECBZT4CL6/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JKVA75UHKVOHNOEPCLUHTFGWCOOUBDM3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PEQYVCNYUWB4CJ2YRAYNF2GGFQ7SUYC4/
- https://lore.kernel.org/all/YtoWqEkKzvimzWS5%40gondor.apana.org.au/T/
- https://security.netapp.com/advisory/ntap-20230214-0004/
Modified: 2025-06-27
CVE-2022-3077
A buffer overflow vulnerability was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way it handled the I2C_SMBUS_BLOCK_PROC_CALL case (via the ioctl I2C_SMBUS) with malicious input data. This flaw could allow a local user to crash the system.
Modified: 2025-05-21
CVE-2022-3303
A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/all/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA%40mail.gmail.com/
- https://www.debian.org/security/2022/dsa-5257
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/all/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA%40mail.gmail.com/
- https://www.debian.org/security/2022/dsa-5257
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-11-21
CVE-2022-34918
An issue was discovered in the Linux kernel through 5.18.9. A type confusion bug in nft_set_elem_init (leading to a buffer overflow) could be used by a local attacker to escalate privileges, a different vulnerability than CVE-2022-32250. (The attacker can obtain root access, but must start with an unprivileged user namespace to obtain CAP_NET_ADMIN access.) This can be fixed in nft_setelem_parse_data in net/netfilter/nf_tables_api.c.
- http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html
- http://packetstormsecurity.com/files/168543/Netfilter-nft_set_elem_init-Heap-Overflow-Privilege-Escalation.html
- http://www.openwall.com/lists/oss-security/2022/07/05/1
- http://www.openwall.com/lists/oss-security/2022/08/06/5
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6
- https://lore.kernel.org/netfilter-devel/cd9428b6-7ffb-dd22-d949-d86f4869f452%40randorisec.fr/T/#u
- https://security.netapp.com/advisory/ntap-20220826-0004/
- https://www.debian.org/security/2022/dsa-5191
- https://www.openwall.com/lists/oss-security/2022/07/02/3
- https://www.randorisec.fr/crack-linux-firewall/
- http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html
- http://packetstormsecurity.com/files/168543/Netfilter-nft_set_elem_init-Heap-Overflow-Privilege-Escalation.html
- http://www.openwall.com/lists/oss-security/2022/07/05/1
- http://www.openwall.com/lists/oss-security/2022/08/06/5
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6
- https://lore.kernel.org/netfilter-devel/cd9428b6-7ffb-dd22-d949-d86f4869f452%40randorisec.fr/T/#u
- https://security.netapp.com/advisory/ntap-20220826-0004/
- https://www.debian.org/security/2022/dsa-5191
- https://www.openwall.com/lists/oss-security/2022/07/02/3
- https://www.randorisec.fr/crack-linux-firewall/
Modified: 2024-11-21
CVE-2022-3521
A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function kcm_tx_work of the file net/kcm/kcmsock.c of the component kcm. The manipulation leads to race condition. It is recommended to apply a patch to fix this issue. VDB-211018 is the identifier assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec7eede369fe5b0d085ac51fdbb95184f87bfc6c
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211018
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec7eede369fe5b0d085ac51fdbb95184f87bfc6c
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211018
Modified: 2024-11-21
CVE-2022-3544
A vulnerability, which was classified as problematic, was found in Linux Kernel. Affected is the function damon_sysfs_add_target of the file mm/damon/sysfs.c of the component Netfilter. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211044.
Modified: 2025-06-25
CVE-2022-3586
A flaw was found in the Linux kernel’s networking code. A use-after-free was found in the way the sch_sfb enqueue function used the socket buffer (SKB) cb field after the same SKB had been enqueued (and freed) into a child qdisc. This flaw allows a local, unprivileged user to crash the system, causing a denial of service.
- https://github.com/torvalds/linux/commit/9efd23297cca
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://www.zerodayinitiative.com/advisories/upcoming/
- https://github.com/torvalds/linux/commit/9efd23297cca
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://www.zerodayinitiative.com/advisories/upcoming/
Modified: 2024-11-21
CVE-2022-36123
The Linux kernel before 5.18.13 lacks a certain clear operation for the block starting symbol (.bss). This allows Xen PV guest OS users to cause a denial of service or gain privileges.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.13
- https://github.com/sickcodes/security/blob/master/advisories/SICK-2022-128.md
- https://github.com/torvalds/linux/commit/74a0032b8524ee2bd4443128c0bf9775928680b0
- https://github.com/torvalds/linux/commit/96e8fc5818686d4a1591bb6907e7fdb64ef29884
- https://security.netapp.com/advisory/ntap-20220901-0003/
- https://sick.codes/sick-2022-128
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.13
- https://github.com/sickcodes/security/blob/master/advisories/SICK-2022-128.md
- https://github.com/torvalds/linux/commit/74a0032b8524ee2bd4443128c0bf9775928680b0
- https://github.com/torvalds/linux/commit/96e8fc5818686d4a1591bb6907e7fdb64ef29884
- https://security.netapp.com/advisory/ntap-20220901-0003/
- https://sick.codes/sick-2022-128
Modified: 2024-11-21
CVE-2022-3625
A vulnerability was found in Linux Kernel. It has been classified as critical. This affects the function devlink_param_set/devlink_param_get of the file net/core/devlink.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211929 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=6b4db2e528f650c7fb712961aac36455468d5902
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://vuldb.com/?id.211929
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=6b4db2e528f650c7fb712961aac36455468d5902
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://vuldb.com/?id.211929
Modified: 2024-11-21
CVE-2022-3635
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function tst_timer of the file drivers/atm/idt77252.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. VDB-211934 is the identifier assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://vuldb.com/?id.211934
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://vuldb.com/?id.211934
Modified: 2024-11-21
CVE-2022-3649
A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is the function nilfs_new_inode of the file fs/nilfs2/inode.c of the component BPF. The manipulation leads to use after free. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211992.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20230214-0009/
- https://vuldb.com/?id.211992
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20230214-0009/
- https://vuldb.com/?id.211992
Modified: 2025-05-05
CVE-2022-36879
An issue was discovered in the Linux kernel through 5.18.14. xfrm_expand_policies in net/xfrm/xfrm_policy.c can cause a refcount to be dropped twice.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f85daf0e725358be78dfd208dea5fd665d8cb901
- https://github.com/torvalds/linux/commit/f85daf0e725358be78dfd208dea5fd665d8cb901
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f85daf0e725358be78dfd208dea5fd665d8cb901
- https://github.com/torvalds/linux/commit/f85daf0e725358be78dfd208dea5fd665d8cb901
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
Modified: 2025-05-05
CVE-2022-36946
nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte nfta_payload attribute, an skb_pull can encounter a negative skb->len.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://marc.info/?l=netfilter-devel&m=165883202007292&w=2
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://marc.info/?l=netfilter-devel&m=165883202007292&w=2
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
Modified: 2024-11-21
CVE-2022-3910
Use After Free vulnerability in Linux Kernel allows Privilege Escalation. An improper Update of Reference Count in io_uring leads to Use-After-Free and Local Privilege Escalation. When io_msg_ring was invoked with a fixed file, it called io_fput_file() which improperly decreased its reference count (leading to Use-After-Free and Local Privilege Escalation). Fixed files are permanently registered to the ring, and should not be put separately. We recommend upgrading past commit https://github.com/torvalds/linux/commit/fc7222c3a9f56271fba02aabbfbae999042f1679 https://github.com/torvalds/linux/commit/fc7222c3a9f56271fba02aabbfbae999042f1679
Modified: 2024-11-21
CVE-2022-39188
An issue was discovered in include/asm-generic/tlb.h in the Linux kernel before 5.19. Because of a race condition (unmap_mapping_range versus munmap), a device driver can free a page while it still has stale TLB entries. This only occurs in situations with VM_PFNMAP VMAs.
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2329
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b67fbebd4cf980aecbcc750e1462128bffe8ae15
- https://github.com/torvalds/linux/commit/b67fbebd4cf980aecbcc750e1462128bffe8ae15
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/stable/CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg%40mail.gmail.com/
- https://www.debian.org/security/2022/dsa-5257
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2329
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b67fbebd4cf980aecbcc750e1462128bffe8ae15
- https://github.com/torvalds/linux/commit/b67fbebd4cf980aecbcc750e1462128bffe8ae15
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/stable/CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg%40mail.gmail.com/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-05-05
CVE-2022-39189
An issue was discovered the x86 KVM subsystem in the Linux kernel before 5.18.17. Unprivileged guest users can compromise the guest kernel because TLB flush operations are mishandled in certain KVM_VCPU_PREEMPTED situations.
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2309
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736
- https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230214-0007/
- https://www.debian.org/security/2023/dsa-5480
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2309
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736
- https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230214-0007/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2024-11-21
CVE-2022-39190
An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel before 5.19.6. A denial of service can occur upon binding to an already bound chain.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6
- https://github.com/torvalds/linux/commit/e02f0d3970404bfea385b6edb86f2d936db0ea2b
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/all/20220824220330.64283-12-pablo%40netfilter.org/
- https://twitter.com/pr0Ln
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6
- https://github.com/torvalds/linux/commit/e02f0d3970404bfea385b6edb86f2d936db0ea2b
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/all/20220824220330.64283-12-pablo%40netfilter.org/
- https://twitter.com/pr0Ln
Modified: 2025-04-08
CVE-2022-3977
A use-after-free flaw was found in the Linux kernel MCTP (Management Component Transport Protocol) functionality. This issue occurs when a user simultaneously calls DROPTAG ioctl and socket close happens, which could allow a local user to crash the system or potentially escalate their privileges on the system.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a732b46736cd8a29092e4b0b1a9ba83e672bf89
- https://security.netapp.com/advisory/ntap-20230223-0005/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a732b46736cd8a29092e4b0b1a9ba83e672bf89
- https://security.netapp.com/advisory/ntap-20230223-0005/
Modified: 2024-11-21
CVE-2022-39842
An issue was discovered in the Linux kernel before 5.19. In pxa3xx_gcu_write in drivers/video/fbdev/pxa3xx-gcu.c, the count parameter has a type conflict of size_t versus int, causing an integer overflow and bypassing the size check. After that, because it is used as the third argument to copy_from_user(), a heap overflow may occur. NOTE: the original discoverer disputes that the overflow can actually happen.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://github.com/torvalds/linux/commit/a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/all/YylaC1wHHyLw22D3%40kadam/T/
- https://www.debian.org/security/2022/dsa-5257
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://github.com/torvalds/linux/commit/a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lore.kernel.org/all/YylaC1wHHyLw22D3%40kadam/T/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2024-11-21
CVE-2022-40307
An issue was discovered in the Linux kernel through 5.19.8. drivers/firmware/efi/capsule-loader.c has a race condition with a resultant use-after-free.
- https://github.com/torvalds/linux/commit/9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://www.debian.org/security/2022/dsa-5257
- https://github.com/torvalds/linux/commit/9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://www.debian.org/security/2022/dsa-5257
Modified: 2024-11-21
CVE-2022-40768
drivers/scsi/stex.c in the Linux kernel through 5.19.9 allows local users to obtain sensitive information from kernel memory because stex_queuecommand_lck lacks a memset for the PASSTHRU_CMD case.
- http://www.openwall.com/lists/oss-security/2022/09/19/1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6022f210461fef67e6e676fd8544ca02d1bcfa7a
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/scsi/stex.c
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://lore.kernel.org/all/20220908145154.2284098-1-gregkh%40linuxfoundation.org/
- https://www.openwall.com/lists/oss-security/2022/09/09/1
- http://www.openwall.com/lists/oss-security/2022/09/19/1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6022f210461fef67e6e676fd8544ca02d1bcfa7a
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/scsi/stex.c
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://lore.kernel.org/all/20220908145154.2284098-1-gregkh%40linuxfoundation.org/
- https://www.openwall.com/lists/oss-security/2022/09/09/1
Modified: 2025-02-26
CVE-2022-4095
A use-after-free flaw was found in Linux kernel before 5.19.2. This issue occurs in cmd_hdl_filter in drivers/staging/rtl8712/rtl8712_cmd.c, allowing an attacker to launch a local denial of service attack and gain escalation of privileges.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c53b3dcb9942b8ed7f81ee3921c4085d87070c73
- https://security.netapp.com/advisory/ntap-20230420-0005/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c53b3dcb9942b8ed7f81ee3921c4085d87070c73
- https://security.netapp.com/advisory/ntap-20230420-0005/
Modified: 2025-05-28
CVE-2022-41218
In drivers/media/dvb-core/dmxdev.c in the Linux kernel through 5.19.10, there is a use-after-free caused by refcount races, affecting dvb_demux_open and dvb_dmxdev_release.
- http://www.openwall.com/lists/oss-security/2022/09/23/4
- http://www.openwall.com/lists/oss-security/2022/09/24/1
- http://www.openwall.com/lists/oss-security/2022/09/24/2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd3d91ab1c6ab0628fe642dd570b56302c30a792
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/media/dvb-core/dmxdev.c
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20220908132754.30532-1-tiwai%40suse.de/
- https://www.debian.org/security/2023/dsa-5324
- http://www.openwall.com/lists/oss-security/2022/09/23/4
- http://www.openwall.com/lists/oss-security/2022/09/24/1
- http://www.openwall.com/lists/oss-security/2022/09/24/2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd3d91ab1c6ab0628fe642dd570b56302c30a792
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/media/dvb-core/dmxdev.c
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20220908132754.30532-1-tiwai%40suse.de/
- https://www.debian.org/security/2023/dsa-5324
Modified: 2025-05-15
CVE-2022-41674
An issue was discovered in the Linux kernel before 5.19.16. Attackers able to inject WLAN frames could cause a buffer overflow in the ieee80211_bss_info_update function in net/mac80211/scan.c.
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- https://bugzilla.suse.com/show_bug.cgi?id=1203770
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://www.debian.org/security/2022/dsa-5257
- https://www.openwall.com/lists/oss-security/2022/10/13/5
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- https://bugzilla.suse.com/show_bug.cgi?id=1203770
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://www.debian.org/security/2022/dsa-5257
- https://www.openwall.com/lists/oss-security/2022/10/13/5
Modified: 2025-05-20
CVE-2022-41848
drivers/char/pcmcia/synclink_cs.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling ioctl, aka a race condition between mgslpc_ioctl and mgslpc_detach.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/char/pcmcia/synclink_cs.c
- https://lore.kernel.org/lkml/20220919040251.GA302541%40ubuntu/T/#rc85e751f467b3e6f9ccef92cfa7fb8a6cc50c270
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/char/pcmcia/synclink_cs.c
- https://lore.kernel.org/lkml/20220919040251.GA302541%40ubuntu/T/#rc85e751f467b3e6f9ccef92cfa7fb8a6cc50c270
Modified: 2024-11-21
CVE-2022-41849
drivers/video/fbdev/smscufx.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a USB device while calling open(), aka a race condition between ufx_ops_open and ufx_usb_disconnect.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5610bcfe8693c02e2e4c8b31427f1bdbdecc839c
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lore.kernel.org/all/20220925133243.GA383897%40ubuntu/T/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5610bcfe8693c02e2e4c8b31427f1bdbdecc839c
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lore.kernel.org/all/20220925133243.GA383897%40ubuntu/T/
Modified: 2024-11-21
CVE-2022-41850
roccat_report_event in drivers/hid/hid-roccat.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free in certain situations where a report is received while copying a report->value is in progress.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cacdb14b1c8d3804a3a7d31773bc7569837b71a4
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lore.kernel.org/all/20220904193115.GA28134%40ubuntu/t/#u
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cacdb14b1c8d3804a3a7d31773bc7569837b71a4
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lore.kernel.org/all/20220904193115.GA28134%40ubuntu/t/#u
Modified: 2025-04-23
CVE-2022-42328
Guests can trigger deadlock in Linux netback driver T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The patch for XSA-392 introduced another issue which might result in a deadlock when trying to free the SKB of a packet dropped due to the XSA-392 handling (CVE-2022-42328). Additionally when dropping packages for other reasons the same deadlock could occur in case of netpoll being active for the interface the xen-netback driver is connected to (CVE-2022-42329).
- http://www.openwall.com/lists/oss-security/2022/12/08/2
- http://www.openwall.com/lists/oss-security/2022/12/08/3
- http://www.openwall.com/lists/oss-security/2022/12/09/2
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://xenbits.xenproject.org/xsa/advisory-424.txt
- http://www.openwall.com/lists/oss-security/2022/12/08/2
- http://www.openwall.com/lists/oss-security/2022/12/08/3
- http://www.openwall.com/lists/oss-security/2022/12/09/2
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://xenbits.xenproject.org/xsa/advisory-424.txt
Modified: 2025-04-23
CVE-2022-42329
Guests can trigger deadlock in Linux netback driver T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The patch for XSA-392 introduced another issue which might result in a deadlock when trying to free the SKB of a packet dropped due to the XSA-392 handling (CVE-2022-42328). Additionally when dropping packages for other reasons the same deadlock could occur in case of netpoll being active for the interface the xen-netback driver is connected to (CVE-2022-42329).
- http://www.openwall.com/lists/oss-security/2022/12/08/2
- http://www.openwall.com/lists/oss-security/2022/12/08/3
- http://www.openwall.com/lists/oss-security/2022/12/09/2
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://xenbits.xenproject.org/xsa/advisory-424.txt
- http://www.openwall.com/lists/oss-security/2022/12/08/2
- http://www.openwall.com/lists/oss-security/2022/12/08/3
- http://www.openwall.com/lists/oss-security/2022/12/09/2
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://xenbits.xenproject.org/xsa/advisory-424.txt
Modified: 2024-11-21
CVE-2022-42703
mm/rmap.c in the Linux kernel before 5.19.7 has a use-after-free related to leaf anon_vma double reuse.
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2351
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.7
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2555283eb40df89945557273121e9393ef9b542b
- https://github.com/torvalds/linux/commit/2555283eb40df89945557273121e9393ef9b542b
- https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2351
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.7
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2555283eb40df89945557273121e9393ef9b542b
- https://github.com/torvalds/linux/commit/2555283eb40df89945557273121e9393ef9b542b
- https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html
Modified: 2025-05-15
CVE-2022-42719
A use-after-free in the mac80211 stack when parsing a multi-BSSID element in the Linux kernel 5.2 through 5.19.x before 5.19.16 could be used by attackers (able to inject WLAN frames) to crash the kernel and potentially execute code.
- http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204051
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
- http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204051
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-05-15
CVE-2022-42720
Various refcounting bugs in the multi-BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.x before 5.19.16 could be used by local attackers (able to inject WLAN frames) to trigger use-after-free conditions to potentially execute code.
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204059
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204059
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-05-15
CVE-2022-42721
A list management bug in BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.x before 5.19.16 could be used by local attackers (able to inject WLAN frames) to corrupt a linked list and, in turn, potentially execute code.
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204060
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=bcca852027e5878aec911a347407ecc88d6fff7f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204060
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=bcca852027e5878aec911a347407ecc88d6fff7f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2024-11-21
CVE-2022-42722
In the Linux kernel 5.8 through 5.19.x before 5.19.16, local attackers able to inject WLAN frames into the mac80211 stack could cause a NULL pointer dereference denial-of-service attack against the beacon protection of P2P devices.
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204125
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=b2d03cabe2b2e150ff5a381731ea0355459be09f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204125
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=b2d03cabe2b2e150ff5a381731ea0355459be09f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-05-07
CVE-2022-43750
drivers/usb/mon/mon_bin.c in usbmon in the Linux kernel before 5.19.15 and 6.x before 6.0.1 allows a user-space client to corrupt the monitor's internal memory.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.15
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198
- https://github.com/torvalds/linux/commit/a659daf63d16aa883be42f3f34ff84235c302198
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.15
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198
- https://github.com/torvalds/linux/commit/a659daf63d16aa883be42f3f34ff84235c302198
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
Modified: 2025-05-01
CVE-2022-43945
The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC message with garbage data is still correctly formed according to the specification and is passed forward to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90497a16e434c2211c66e3de8e77b17868382b8
- https://security.netapp.com/advisory/ntap-20221215-0006/
- http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90497a16e434c2211c66e3de8e77b17868382b8
- https://security.netapp.com/advisory/ntap-20221215-0006/
Modified: 2025-04-09
CVE-2022-4662
A flaw incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system.
- https://lore.kernel.org/all/20220913140355.910732567%40linuxfoundation.org/
- https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA%40mail.gmail.com/
- https://lore.kernel.org/all/20220913140355.910732567%40linuxfoundation.org/
- https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA%40mail.gmail.com/
Modified: 2025-04-15
CVE-2022-47938
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2misc.c has an out-of-bounds read and OOPS for SMB2_TREE_CONNECT.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=824d4f64c20093275f72fc8101394d75ff6a249e
- https://github.com/torvalds/linux/commit/824d4f64c20093275f72fc8101394d75ff6a249e
- https://www.zerodayinitiative.com/advisories/ZDI-22-1689/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=824d4f64c20093275f72fc8101394d75ff6a249e
- https://github.com/torvalds/linux/commit/824d4f64c20093275f72fc8101394d75ff6a249e
- https://www.zerodayinitiative.com/advisories/ZDI-22-1689/
Modified: 2025-04-14
CVE-2022-47939
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c has a use-after-free and OOPS for SMB2_TREE_DISCONNECT.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c
- https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c
- https://www.secpod.com/blog/zero-day-server-message-block-smb-server-in-linux-kernel-5-15-has-a-critical-vulnerability-patch-ksmbd-immediately/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1690/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c
- https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c
- https://www.secpod.com/blog/zero-day-server-message-block-smb-server-in-linux-kernel-5-15-has-a-critical-vulnerability-patch-ksmbd-immediately/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1690/
Modified: 2025-04-14
CVE-2022-47940
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.18 before 5.18.18. fs/ksmbd/smb2pdu.c lacks length validation in the non-padding case in smb2_write.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.18
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=158a66b245739e15858de42c0ba60fcf3de9b8e6
- https://github.com/torvalds/linux/commit/158a66b245739e15858de42c0ba60fcf3de9b8e6
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.18
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=158a66b245739e15858de42c0ba60fcf3de9b8e6
- https://github.com/torvalds/linux/commit/158a66b245739e15858de42c0ba60fcf3de9b8e6
Modified: 2025-04-15
CVE-2022-47941
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c omits a kfree call in certain smb2_handle_negotiate error conditions, aka a memory leak.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa7253c2393f6dcd6a1468b0792f6da76edad917
- https://github.com/torvalds/linux/commit/aa7253c2393f6dcd6a1468b0792f6da76edad917
- https://www.zerodayinitiative.com/advisories/ZDI-22-1687/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa7253c2393f6dcd6a1468b0792f6da76edad917
- https://github.com/torvalds/linux/commit/aa7253c2393f6dcd6a1468b0792f6da76edad917
- https://www.zerodayinitiative.com/advisories/ZDI-22-1687/
Modified: 2025-04-15
CVE-2022-47942
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is a heap-based buffer overflow in set_ntacl_dacl, related to use of SMB2_QUERY_INFO_HE after a malformed SMB2_SET_INFO_HE command.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f0541186e9ad1b62accc9519cc2b7a7240272a7
- https://github.com/torvalds/linux/commit/8f0541186e9ad1b62accc9519cc2b7a7240272a7
- https://www.zerodayinitiative.com/advisories/ZDI-22-1688/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f0541186e9ad1b62accc9519cc2b7a7240272a7
- https://github.com/torvalds/linux/commit/8f0541186e9ad1b62accc9519cc2b7a7240272a7
- https://www.zerodayinitiative.com/advisories/ZDI-22-1688/
Modified: 2025-04-15
CVE-2022-47943
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is an out-of-bounds read and OOPS for SMB2_WRITE, when there is a large length in the zero DataOffset case.
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac60778b87e45576d7bfdbd6f53df902654e6f09
- https://github.com/torvalds/linux/commit/ac60778b87e45576d7bfdbd6f53df902654e6f09
- https://security.netapp.com/advisory/ntap-20230216-0006/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1691/
- http://www.openwall.com/lists/oss-security/2022/12/23/10
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac60778b87e45576d7bfdbd6f53df902654e6f09
- https://github.com/torvalds/linux/commit/ac60778b87e45576d7bfdbd6f53df902654e6f09
- https://security.netapp.com/advisory/ntap-20230216-0006/
- https://www.zerodayinitiative.com/advisories/ZDI-22-1691/
Modified: 2025-04-29
CVE-2022-48627
In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew.
- https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265
- https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc
- https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244
- https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c
- https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926
- https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29
- https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265
- https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc
- https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244
- https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c
- https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926
- https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-19
CVE-2022-48631
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0
When walking through an inode extents, the ext4_ext_binsearch_idx() function
assumes that the extent header has been previously validated. However, there
are no checks that verify that the number of entries (eh->eh_entries) is
non-zero when depth is > 0. And this will lead to problems because the
EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:
[ 135.245946] ------------[ cut here ]------------
[ 135.247579] kernel BUG at fs/ext4/extents.c:2258!
[ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP
[ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4
[ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
[ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0
[ 135.256475] Code:
[ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246
[ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023
[ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c
[ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c
[ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024
[ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000
[ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0
[ 135.277952] Call Trace:
[ 135.278635]
- https://git.kernel.org/stable/c/29a5b8a137ac8eb410cc823653a29ac0e7b7e1b0
- https://git.kernel.org/stable/c/2f5e9de15e4f55fbf56f22d4a2ce406246cc462d
- https://git.kernel.org/stable/c/958b0ee23f5ac106e7cc11472b71aa2ea9a033bc
- https://git.kernel.org/stable/c/bb7eb3ca4b3b0d2c7872cf1a41c30f5e5bd65df0
- https://git.kernel.org/stable/c/be4df018c0be5ebecf1ca510feacc23be415cefc
- https://git.kernel.org/stable/c/29a5b8a137ac8eb410cc823653a29ac0e7b7e1b0
- https://git.kernel.org/stable/c/2f5e9de15e4f55fbf56f22d4a2ce406246cc462d
- https://git.kernel.org/stable/c/958b0ee23f5ac106e7cc11472b71aa2ea9a033bc
- https://git.kernel.org/stable/c/bb7eb3ca4b3b0d2c7872cf1a41c30f5e5bd65df0
- https://git.kernel.org/stable/c/be4df018c0be5ebecf1ca510feacc23be415cefc
Modified: 2025-03-04
CVE-2022-48632
In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() memcpy() is called in a loop while 'operation->length' upper bound is not checked and 'data_idx' also increments.
- https://git.kernel.org/stable/c/3b5ab5fbe69ebbee5692c72b05071a43fc0655d8
- https://git.kernel.org/stable/c/48ee0a864d1af02eea98fc825cc230d61517a71e
- https://git.kernel.org/stable/c/dc2a0c587006f29b724069740c48654b9dcaebd2
- https://git.kernel.org/stable/c/de24aceb07d426b6f1c59f33889d6a964770547b
- https://git.kernel.org/stable/c/3b5ab5fbe69ebbee5692c72b05071a43fc0655d8
- https://git.kernel.org/stable/c/48ee0a864d1af02eea98fc825cc230d61517a71e
- https://git.kernel.org/stable/c/dc2a0c587006f29b724069740c48654b9dcaebd2
- https://git.kernel.org/stable/c/de24aceb07d426b6f1c59f33889d6a964770547b
Modified: 2025-09-19
CVE-2022-48633
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: Fix WARN_ON(lock->magic != lock) error
psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex
gets destroyed by drm_gem_object_release() move the
drm_gem_object_release() call in psb_gem_free_object() to after
the unpin to fix the below warning:
[ 79.693962] ------------[ cut here ]------------
[ 79.693992] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[ 79.694015] WARNING: CPU: 0 PID: 240 at kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0
[ 79.694052] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap ecdh_generic pcspkr wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse
[ 79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: G W E 6.0.0-rc3+ #490
[ 79.694457] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0
[ 79.694496] Code: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff <0f> 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11
[ 79.694513] RSP: 0018:ffffad1dc048bbe0 EFLAGS: 00010282
[ 79.694623] RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000000
[ 79.694636] RDX: 0000000000000001 RSI: ffffffffaa8b0ffc RDI: 00000000ffffffff
[ 79.694650] RBP: ffffad1dc048bc80 R08: 0000000000000000 R09: ffffad1dc048ba90
[ 79.694662] R10: 0000000000000003 R11: ffffffffaad62fe8 R12: ffff9ff302103138
[ 79.694675] R13: ffff9ff306ec8000 R14: ffff9ff307779078 R15: ffff9ff3014c0270
[ 79.694690] FS: 00007ff1cccf1740(0000) GS:ffff9ff3bc200000(0000) knlGS:0000000000000000
[ 79.694705] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 79.694719] CR2: 0000559ecbcb4420 CR3: 0000000013210000 CR4: 00000000000006f0
[ 79.694734] Call Trace:
[ 79.694749]
Modified: 2025-03-21
CVE-2022-48634
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: Fix BUG: sleeping function called from invalid context errors
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on
errors re-take the lock and clear gma_crtc->page_flip_event it
it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870
[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell
[ 512.123031] preempt_count: 1, expected: 0
[ 512.123048] RCU nest depth: 0, expected: 0
[ 512.123066] INFO: lockdep is turned off.
[ 512.123080] irq event stamp: 0
[ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 512.123134] hardirqs last disabled at (0): [
- https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281
- https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd
- https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd
- https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b
- https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281
- https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd
- https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd
- https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b
Modified: 2025-10-29
CVE-2022-48635
In the Linux kernel, the following vulnerability has been resolved:
fsdax: Fix infinite loop in dax_iomap_rw()
I got an infinite loop and a WARNING report when executing a tail command
in virtiofs.
WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0
Modules linked in:
CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7
Call Trace:
- https://git.kernel.org/stable/c/17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3
- https://git.kernel.org/stable/c/463f36137c40342fb03bba380c1bf703c40d89a6
- https://git.kernel.org/stable/c/60644dffac87b1bb47bdb393aa29d5f2ffcf41a0
- https://git.kernel.org/stable/c/929ef155e1da41c06f4d8ca86ae12b851a83a744
- https://git.kernel.org/stable/c/17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3
- https://git.kernel.org/stable/c/60644dffac87b1bb47bdb393aa29d5f2ffcf41a0
- https://git.kernel.org/stable/c/929ef155e1da41c06f4d8ca86ae12b851a83a744
Modified: 2025-03-21
CVE-2022-48636
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer with lcu->lock held.
- https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1
- https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4
- https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a2033036ac
- https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1
- https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6
- https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70
- https://git.kernel.org/stable/c/db7ba07108a48c0f95b74fabbfd5d63e924f992d
- https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b
- https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1
- https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4
- https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a2033036ac
- https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1
- https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6
- https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70
- https://git.kernel.org/stable/c/db7ba07108a48c0f95b74fabbfd5d63e924f992d
- https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b
Modified: 2025-03-21
CVE-2022-48637
In the Linux kernel, the following vulnerability has been resolved: bnxt: prevent skb UAF after handing over to PTP worker When reading the timestamp is required bnxt_tx_int() hands over the ownership of the completed skb to the PTP worker. The skb should not be used afterwards, as the worker may run before the rest of our code and free the skb, leading to a use-after-free. Since dev_kfree_skb_any() accepts NULL make the loss of ownership more obvious and set skb to NULL.
- https://git.kernel.org/stable/c/08483e4c0c83b221b8891434a04cec405dee94a6
- https://git.kernel.org/stable/c/32afa1f23e42cc635ccf4c39f24514d03d1e8338
- https://git.kernel.org/stable/c/c31f26c8f69f776759cbbdfb38e40ea91aa0dd65
- https://git.kernel.org/stable/c/08483e4c0c83b221b8891434a04cec405dee94a6
- https://git.kernel.org/stable/c/32afa1f23e42cc635ccf4c39f24514d03d1e8338
- https://git.kernel.org/stable/c/c31f26c8f69f776759cbbdfb38e40ea91aa0dd65
Modified: 2025-03-21
CVE-2022-48638
In the Linux kernel, the following vulnerability has been resolved: cgroup: cgroup_get_from_id() must check the looked-up kn is a directory cgroup has to be one kernfs dir, otherwise kernel panic is caused, especially cgroup id is provide from userspace.
- https://git.kernel.org/stable/c/1e9571887f97b17cf3ffe9aa4da89090ea60988b
- https://git.kernel.org/stable/c/8484a356cee8ce3d6a8e6266ff99be326e9273ad
- https://git.kernel.org/stable/c/df02452f3df069a59bc9e69c84435bf115cb6e37
- https://git.kernel.org/stable/c/1e9571887f97b17cf3ffe9aa4da89090ea60988b
- https://git.kernel.org/stable/c/8484a356cee8ce3d6a8e6266ff99be326e9273ad
- https://git.kernel.org/stable/c/df02452f3df069a59bc9e69c84435bf115cb6e37
Modified: 2025-01-13
CVE-2022-48639
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix possible refcount leak in tc_new_tfilter() tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops.
- https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88
- https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596
- https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a
- https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5
- https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7
- https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88
- https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596
- https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a
- https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5
- https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7
Modified: 2025-09-19
CVE-2022-48640
In the Linux kernel, the following vulnerability has been resolved: bonding: fix NULL deref in bond_rr_gen_slave_id Fix a NULL dereference of the struct bonding.rr_tx_counter member because if a bond is initially created with an initial mode != zero (Round Robin) the memory required for the counter is never created and when the mode is changed there is never any attempt to verify the memory is allocated upon switching modes. This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x0000000096000004 [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: level 0 translation fault [ 334.717586] Data abort info: [ 334.720454] ISV = 0, ISS = 0x00000004 [ 334.724288] CM = 0, WnR = 0 [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000 [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000 [ 334.740734] Internal error: Oops: 96000004 [#1] SMP [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4 [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742 [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400 [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0 [ 334.882532] Call trace: [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding] [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334.909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c/0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] __neigh_event_send+0x3b0/0x470 [ 334.931453] neigh_resolve_output+0x70/0x90 [ 334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] ip_send_skb+0x5c/0x100 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c ---truncated---
- https://git.kernel.org/stable/c/0e400d602f46360752e4b32ce842dba3808e15e6
- https://git.kernel.org/stable/c/2c8e8ab53acfc78da0b4a65f30cb5d306e7d78f7
- https://git.kernel.org/stable/c/ec3a6f4ffe556a28f6f5028bf7c4412557e7051b
- https://git.kernel.org/stable/c/0e400d602f46360752e4b32ce842dba3808e15e6
- https://git.kernel.org/stable/c/2c8e8ab53acfc78da0b4a65f30cb5d306e7d78f7
- https://git.kernel.org/stable/c/ec3a6f4ffe556a28f6f5028bf7c4412557e7051b
Modified: 2025-01-07
CVE-2022-48642
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain() It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error.
- https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852
- https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714
- https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac
- https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88
- https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852
- https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714
- https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac
- https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88
Modified: 2025-09-19
CVE-2022-48644
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on an invalid set of flags. As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIO_FLAGS_INVALID, and the calling of taprio_enable_offload(). This is because drivers do not expect the offload to be disabled when it was never enabled. The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc: $ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2c Fix this by keeping track of the operations we made, and undo the offload only if we actually did it. I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64_t picos_per_byte". Now the first cache line looks like below: $ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */
- https://git.kernel.org/stable/c/586def6ebed195f3594a4884f7c5334d0e1ad1bb
- https://git.kernel.org/stable/c/c7c9c7eb305ab8b4e93e4e4e1b78d8cfcbc26323
- https://git.kernel.org/stable/c/d12a1eb07003e597077329767c6aa86a7e972c76
- https://git.kernel.org/stable/c/db46e3a88a09c5cf7e505664d01da7238cd56c92
- https://git.kernel.org/stable/c/f58e43184226e5e9662088ccf1389e424a3a4cbd
- https://git.kernel.org/stable/c/586def6ebed195f3594a4884f7c5334d0e1ad1bb
- https://git.kernel.org/stable/c/c7c9c7eb305ab8b4e93e4e4e1b78d8cfcbc26323
- https://git.kernel.org/stable/c/d12a1eb07003e597077329767c6aa86a7e972c76
- https://git.kernel.org/stable/c/db46e3a88a09c5cf7e505664d01da7238cd56c92
- https://git.kernel.org/stable/c/f58e43184226e5e9662088ccf1389e424a3a4cbd
Modified: 2025-09-19
CVE-2022-48645
In the Linux kernel, the following vulnerability has been resolved: net: enetc: deny offload of tc-based TSN features on VF interfaces TSN features on the ENETC (taprio, cbs, gate, police) are configured through a mix of command BD ring messages and port registers: enetc_port_rd(), enetc_port_wr(). Port registers are a region of the ENETC memory map which are only accessible from the PCIe Physical Function. They are not accessible from the Virtual Functions. Moreover, attempting to access these registers crashes the kernel: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15 fsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0 $ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2 Unable to handle kernel paging request at virtual address ffff800009551a08 Internal error: Oops: 96000007 [#1] PREEMPT SMP pc : enetc_setup_tc_taprio+0x170/0x47c lr : enetc_setup_tc_taprio+0x16c/0x47c Call trace: enetc_setup_tc_taprio+0x170/0x47c enetc_setup_tc+0x38/0x2dc taprio_change+0x43c/0x970 taprio_init+0x188/0x1e0 qdisc_create+0x114/0x470 tc_modify_qdisc+0x1fc/0x6c0 rtnetlink_rcv_msg+0x12c/0x390 Split enetc_setup_tc() into separate functions for the PF and for the VF drivers. Also remove enetc_qos.o from being included into enetc-vf.ko, since it serves absolutely no purpose there.
- https://git.kernel.org/stable/c/23022b74b1a23bed044f6bc96cf92f6ca5f3e75f
- https://git.kernel.org/stable/c/510e703e4ed0e011db860bc21228aff48fc9eea7
- https://git.kernel.org/stable/c/5641c751fe2f92d3d9e8a8e03c1263ac8caa0b42
- https://git.kernel.org/stable/c/23022b74b1a23bed044f6bc96cf92f6ca5f3e75f
- https://git.kernel.org/stable/c/510e703e4ed0e011db860bc21228aff48fc9eea7
- https://git.kernel.org/stable/c/5641c751fe2f92d3d9e8a8e03c1263ac8caa0b42
Modified: 2025-03-20
CVE-2022-48646
In the Linux kernel, the following vulnerability has been resolved: sfc/siena: fix null pointer dereference in efx_hard_start_xmit Like in previous patch for sfc, prevent potential (but unlikely) NULL pointer dereference.
Modified: 2025-03-04
CVE-2022-48647
In the Linux kernel, the following vulnerability has been resolved:
sfc: fix TX channel offset when using legacy interrupts
In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but
that's not correct if efx_sepparate_tx_channels is false. In that case,
the offset is 0 because the tx queues are in the single existing channel
at index 0, together with the rx queue.
Without this fix, as soon as you try to send any traffic, it tries to
get the tx queues from an uninitialized channel getting these errors:
WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]
[...]
RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]
[...]
Call Trace:
- https://git.kernel.org/stable/c/360910b88d1466a90644a4e0533803b594344a2b
- https://git.kernel.org/stable/c/5f623a77cfc2d501d72bcb4f9ee71721e6c766ff
- https://git.kernel.org/stable/c/b4afd3878f961d3517f27b3213730fceef77945c
- https://git.kernel.org/stable/c/f232af4295653afa4ade3230462b3be15ad16419
- https://git.kernel.org/stable/c/360910b88d1466a90644a4e0533803b594344a2b
- https://git.kernel.org/stable/c/5f623a77cfc2d501d72bcb4f9ee71721e6c766ff
- https://git.kernel.org/stable/c/b4afd3878f961d3517f27b3213730fceef77945c
- https://git.kernel.org/stable/c/f232af4295653afa4ade3230462b3be15ad16419
Modified: 2025-01-14
CVE-2022-48648
In the Linux kernel, the following vulnerability has been resolved: sfc: fix null pointer dereference in efx_hard_start_xmit Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]
- https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3
- https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998
- https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7
- https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03
- https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3
- https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998
- https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7
- https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03
Modified: 2025-03-20
CVE-2022-48650
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts() Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") made the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean up the allocated memory for the management command.
- https://git.kernel.org/stable/c/601be20fc6a1b762044d2398befffd6bf236cebf
- https://git.kernel.org/stable/c/6a4236ed47f5b0a57eb6b8fb1c351b15b3d341d7
- https://git.kernel.org/stable/c/89df49e561b4a8948521fc3f8a013012eaa08f82
- https://git.kernel.org/stable/c/601be20fc6a1b762044d2398befffd6bf236cebf
- https://git.kernel.org/stable/c/6a4236ed47f5b0a57eb6b8fb1c351b15b3d341d7
- https://git.kernel.org/stable/c/89df49e561b4a8948521fc3f8a013012eaa08f82
Modified: 2025-03-20
CVE-2022-48651
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following: ================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use "skb->head + skb->mac_header", out-of-bound access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac header in multicast to solve this out-of-bound bug.
- https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca
- https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be
- https://git.kernel.org/stable/c/81225b2ea161af48e093f58e8dfee6d705b16af4
- https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7
- https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638
- https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef12c4241
- https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef
- https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4
- https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca
- https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be
- https://git.kernel.org/stable/c/81225b2ea161af48e093f58e8dfee6d705b16af4
- https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7
- https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638
- https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef12c4241
- https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef
- https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4
Modified: 2025-09-19
CVE-2022-48653
In the Linux kernel, the following vulnerability has been resolved:
ice: Don't double unplug aux on peer initiated reset
In the IDC callback that is accessed when the aux drivers request a reset,
the function to unplug the aux devices is called. This function is also
called in the ice_prepare_for_reset function. This double call is causing
a "scheduling while atomic" BUG.
[ 662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003
[ 662.676609] ice 0000:4c:00.0 rocep76s0: [Modify QP Cmd Error][op_code=8] status=-29 waiting=1 completion_err=1 maj=0xffff min=0x8003
[ 662.815006] ice 0000:4c:00.0 rocep76s0: ICE OICR event notification: oicr = 0x10000003
[ 662.815014] ice 0000:4c:00.0 rocep76s0: critical PE Error, GLPE_CRITERR=0x00011424
[ 662.815017] ice 0000:4c:00.0 rocep76s0: Requesting a reset
[ 662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002
[ 662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002
[ 662.815477] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs rfkill 8021q garp mrp stp llc vfat fat rpcrdma intel_rapl_msr intel_rapl_common sunrpc i10nm_edac rdma_ucm nfit ib_srpt libnvdimm ib_isert iscsi_target_mod x86_pkg_temp_thermal intel_powerclamp coretemp target_core_mod snd_hda_intel ib_iser snd_intel_dspcfg libiscsi snd_intel_sdw_acpi scsi_transport_iscsi kvm_intel iTCO_wdt rdma_cm snd_hda_codec kvm iw_cm ipmi_ssif iTCO_vendor_support snd_hda_core irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq snd_seq_device rapl snd_pcm snd_timer isst_if_mbox_pci pcspkr isst_if_mmio irdma intel_uncore idxd acpi_ipmi joydev isst_if_common snd mei_me idxd_bus ipmi_si soundcore i2c_i801 mei ipmi_devintf i2c_smbus i2c_ismt ipmi_msghandler acpi_power_meter acpi_pad rv(OE) ib_uverbs ib_cm ib_core xfs libcrc32c ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helpe
r ttm
[ 662.815546] nvme nvme_core ice drm crc32c_intel i40e t10_pi wmi pinctrl_emmitsburg dm_mirror dm_region_hash dm_log dm_mod fuse
[ 662.815557] Preemption disabled at:
[ 662.815558] [<0000000000000000>] 0x0
[ 662.815563] CPU: 37 PID: 0 Comm: swapper/37 Kdump: loaded Tainted: G S OE 5.17.1 #2
[ 662.815566] Hardware name: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 11/02/2021
[ 662.815568] Call Trace:
[ 662.815572]
- https://git.kernel.org/stable/c/149979e87eb7a365d3d0b259bed79d84ff585a93
- https://git.kernel.org/stable/c/23c619190318376769ad7b61504c2ea0703fb783
- https://git.kernel.org/stable/c/34447d64b8d28e4d6a73d73f07c879959d68fbfe
- https://git.kernel.org/stable/c/149979e87eb7a365d3d0b259bed79d84ff585a93
- https://git.kernel.org/stable/c/23c619190318376769ad7b61504c2ea0703fb783
- https://git.kernel.org/stable/c/34447d64b8d28e4d6a73d73f07c879959d68fbfe
Modified: 2024-11-21
CVE-2022-48654
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find() nf_osf_find() incorrectly returns true on mismatch, this leads to copying uninitialized memory area in nft_osf which can be used to leak stale kernel stack data to userspace.
- https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8
- https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47
- https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e
- https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764
- https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e
- https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8
- https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47
- https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e
- https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764
- https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e
Modified: 2025-01-10
CVE-2022-48655
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses.
- https://git.kernel.org/stable/c/1f08a1b26cfc53b7715abc46857c6023bb1b87de
- https://git.kernel.org/stable/c/7184491fc515f391afba23d0e9b690caaea72daf
- https://git.kernel.org/stable/c/8e65edf0d37698f7a6cb174608d3ec7976baf49e
- https://git.kernel.org/stable/c/e9076ffbcaed5da6c182b144ef9f6e24554af268
- https://git.kernel.org/stable/c/f2277d9e2a0d092c13bae7ee82d75432bb8b5108
- https://git.kernel.org/stable/c/1f08a1b26cfc53b7715abc46857c6023bb1b87de
- https://git.kernel.org/stable/c/7184491fc515f391afba23d0e9b690caaea72daf
- https://git.kernel.org/stable/c/8e65edf0d37698f7a6cb174608d3ec7976baf49e
- https://git.kernel.org/stable/c/e9076ffbcaed5da6c182b144ef9f6e24554af268
- https://git.kernel.org/stable/c/f2277d9e2a0d092c13bae7ee82d75432bb8b5108
- https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html
- https://security.netapp.com/advisory/ntap-20240912-0008/
Modified: 2024-11-21
CVE-2022-48656
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get() We should call of_node_put() for the reference returned by of_parse_phandle() in fail path or when it is not used anymore. Here we only need to move the of_node_put() before the check.
- https://git.kernel.org/stable/c/a17df55bf6d536712da6902a83db82b82e67d5a2
- https://git.kernel.org/stable/c/aa11dae059a439af82bae541b134f8f53ac177b5
- https://git.kernel.org/stable/c/dd5a6c5a08752b613e83ad2cb5133e72a64b876d
- https://git.kernel.org/stable/c/f9fdb0b86f087c2b7f6c6168dd0985a3c1eda87e
- https://git.kernel.org/stable/c/a17df55bf6d536712da6902a83db82b82e67d5a2
- https://git.kernel.org/stable/c/aa11dae059a439af82bae541b134f8f53ac177b5
- https://git.kernel.org/stable/c/dd5a6c5a08752b613e83ad2cb5133e72a64b876d
- https://git.kernel.org/stable/c/f9fdb0b86f087c2b7f6c6168dd0985a3c1eda87e
Modified: 2024-11-21
CVE-2022-48657
In the Linux kernel, the following vulnerability has been resolved: arm64: topology: fix possible overflow in amu_fie_setup() cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. Multiplying max frequency by 1000 can potentially result in overflow -- multiplying by 1000ULL instead should avoid that... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549
- https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e
- https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb
- https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca
- https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549
- https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e
- https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb
- https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca
Modified: 2024-11-21
CVE-2022-48658
In the Linux kernel, the following vulnerability has been resolved: mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context. Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") moved all flush_cpu_slab() invocations to the global workqueue to avoid a problem related with deactivate_slab()/__free_slab() being called from an IRQ context on PREEMPT_RT kernels. When the flush_all_cpu_locked() function is called from a task context it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up flushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: __flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core] Fix this bug by creating a workqueue for the flush operation with the WQ_MEM_RECLAIM bit set.
- https://git.kernel.org/stable/c/61703b248be993eb4997b00ae5d3318e6d8f3c5b
- https://git.kernel.org/stable/c/df6cb39335cf5a1b918e8dbd8ba7cd9f1d00e45a
- https://git.kernel.org/stable/c/e45cc288724f0cfd497bb5920bcfa60caa335729
- https://git.kernel.org/stable/c/61703b248be993eb4997b00ae5d3318e6d8f3c5b
- https://git.kernel.org/stable/c/df6cb39335cf5a1b918e8dbd8ba7cd9f1d00e45a
- https://git.kernel.org/stable/c/e45cc288724f0cfd497bb5920bcfa60caa335729
Modified: 2024-11-21
CVE-2022-48659
In the Linux kernel, the following vulnerability has been resolved: mm/slub: fix to return errno if kmalloc() fails In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 legacy_get_tree+0x30/0x74 fs/fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568
- https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9
- https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e9501940296
- https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c
- https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124
- https://git.kernel.org/stable/c/7e9c323c52b379d261a72dc7bd38120a761a93cd
- https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c
- https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457
- https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755
- https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9
- https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e9501940296
- https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c
- https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124
- https://git.kernel.org/stable/c/7e9c323c52b379d261a72dc7bd38120a761a93cd
- https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c
- https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457
- https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755
Modified: 2024-11-21
CVE-2022-48660
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully When running gpio test on nxp-ls1028 platform with below command gpiomon --num-events=3 --rising-edge gpiochip1 25 There will be a warning trace as below: Call trace: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... el0t_64_sync+0x1a0/0x1a4 The reason of this issue is that calling request_threaded_irq() function failed, and then lineevent_free() is invoked to release the resource. Since the lineevent_state::irq was already set, so the subsequent invocation of free_irq() would trigger the above warning call trace. To fix this issue, set the lineevent_state::irq after the IRQ register successfully.
- https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd
- https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1
- https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168
- https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43
- https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd
- https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1
- https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168
- https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43
Modified: 2024-11-21
CVE-2022-48661
In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: Fix potential resource leakage when register a chip If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path.
- https://git.kernel.org/stable/c/02743c4091ccfb246f5cdbbe3f44b152d5d12933
- https://git.kernel.org/stable/c/41f857033c44442a27f591fda8d986e7c9e42872
- https://git.kernel.org/stable/c/9b26723e058faaf11b532fb4aa16d6849d581790
- https://git.kernel.org/stable/c/02743c4091ccfb246f5cdbbe3f44b152d5d12933
- https://git.kernel.org/stable/c/41f857033c44442a27f591fda8d986e7c9e42872
- https://git.kernel.org/stable/c/9b26723e058faaf11b532fb4aa16d6849d581790
Modified: 2024-11-21
CVE-2022-48662
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Really move i915_gem_context.link under ref protection
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the list during context_close(), the link.next pointer may
be poisoned while we are holding the context reference and cause a GPF:
[ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff
[ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP
[ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180
[ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]
[ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff
[ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202
[ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000
[ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68
[ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc
[ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860
[ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc
[ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000
[ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0
[ 4070.575029] Call Trace:
[ 4070.575033]
- https://git.kernel.org/stable/c/713fa3e4591f65f804bdc88e8648e219fabc9ee1
- https://git.kernel.org/stable/c/d119888b09bd567e07c6b93a07f175df88857e02
- https://git.kernel.org/stable/c/f799e0568d6c153368b177e0bbbde7dcc4ce7f1d
- https://git.kernel.org/stable/c/713fa3e4591f65f804bdc88e8648e219fabc9ee1
- https://git.kernel.org/stable/c/d119888b09bd567e07c6b93a07f175df88857e02
- https://git.kernel.org/stable/c/f799e0568d6c153368b177e0bbbde7dcc4ce7f1d
Modified: 2025-09-26
CVE-2022-48664
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix hang during unmount when stopping a space reclaim worker
Often when running generic/562 from fstests we can hang during unmount,
resulting in a trace like this:
Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00
Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds.
Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1
Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000
Sep 07 11:55:32 debian9 kernel: Call Trace:
Sep 07 11:55:32 debian9 kernel:
- https://git.kernel.org/stable/c/6ac5b52e3f352f9cb270c89e6e1d4dadb564ddb8
- https://git.kernel.org/stable/c/a362bb864b8db4861977d00bd2c3222503ccc34b
- https://git.kernel.org/stable/c/c338bea1fec5504290dc0acf026c9e7dba25004b
- https://git.kernel.org/stable/c/d8a76a2e514fbbb315a6dfff2d342de2de833994
- https://git.kernel.org/stable/c/6ac5b52e3f352f9cb270c89e6e1d4dadb564ddb8
- https://git.kernel.org/stable/c/a362bb864b8db4861977d00bd2c3222503ccc34b
- https://git.kernel.org/stable/c/c338bea1fec5504290dc0acf026c9e7dba25004b
- https://git.kernel.org/stable/c/d8a76a2e514fbbb315a6dfff2d342de2de833994
Modified: 2025-03-20
CVE-2022-48666
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix a use-after-free
There are two .exit_cmd_priv implementations. Both implementations use
resources associated with the SCSI host. Make sure that these resources are
still available when .exit_cmd_priv is called by waiting inside
scsi_remove_host() until the tag set has been freed.
This commit fixes the following use-after-free:
==================================================================
BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]
Read of size 8 at addr ffff888100337000 by task multipathd/16727
Call Trace:
- https://git.kernel.org/stable/c/2e7eb4c1e8af8385de22775bd0be552f59b28c9a
- https://git.kernel.org/stable/c/5ce8fad941233e81f2afb5b52a3fcddd3ba8732f
- https://git.kernel.org/stable/c/8fe4ce5836e932f5766317cb651c1ff2a4cd0506
- https://git.kernel.org/stable/c/f818708eeeae793e12dc39f8984ed7732048a7d9
- https://git.kernel.org/stable/c/2e7eb4c1e8af8385de22775bd0be552f59b28c9a
- https://git.kernel.org/stable/c/5ce8fad941233e81f2afb5b52a3fcddd3ba8732f
- https://git.kernel.org/stable/c/8fe4ce5836e932f5766317cb651c1ff2a4cd0506
- https://git.kernel.org/stable/c/f818708eeeae793e12dc39f8984ed7732048a7d9
Modified: 2025-09-19
CVE-2022-48667
In the Linux kernel, the following vulnerability has been resolved: smb3: fix temporary data corruption in insert range insert range doesn't discard the affected cached region so can risk temporarily corrupting file data. Also includes some minor cleanup (avoiding rereading inode size repeatedly unnecessarily) to make it clearer.
Modified: 2025-09-19
CVE-2022-48668
In the Linux kernel, the following vulnerability has been resolved: smb3: fix temporary data corruption in collapse range collapse range doesn't discard the affected cached region so can risk temporarily corrupting the file data. This fixes xfstest generic/031 I also decided to merge a minor cleanup to this into the same patch (avoiding rereading inode size repeatedly unnecessarily) to make it clearer.
Modified: 2025-01-10
CVE-2022-48670
In the Linux kernel, the following vulnerability has been resolved: peci: cpu: Fix use-after-free in adev_release() When auxiliary_device_add() returns an error, auxiliary_device_uninit() is called, which causes refcount for device to be decremented and .release callback will be triggered. Because adev_release() re-calls auxiliary_device_uninit(), it will cause use-after-free: [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15 [ 1269.464007] refcount_t: underflow; use-after-free.
Modified: 2024-11-21
CVE-2022-48672
In the Linux kernel, the following vulnerability has been resolved: of: fdt: fix off-by-one error in unflatten_dt_nodes() Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/2133f451311671c7c42b5640d2b999326b39aa0e
- https://git.kernel.org/stable/c/2566706ac6393386a4e7c4ce23fe17f4c98d9aa0
- https://git.kernel.org/stable/c/2f945a792f67815abca26fa8a5e863ccf3fa1181
- https://git.kernel.org/stable/c/ba6b9f7cc1108bad6e2c53b1d6e0156379188db7
- https://git.kernel.org/stable/c/cbdda20ce363356698835185801a58a28f644853
- https://git.kernel.org/stable/c/e0e88c25f88b9805572263c9ed20f1d88742feaf
- https://git.kernel.org/stable/c/ee4369260e77821602102dcc7d792de39a56365c
- https://git.kernel.org/stable/c/2133f451311671c7c42b5640d2b999326b39aa0e
- https://git.kernel.org/stable/c/2566706ac6393386a4e7c4ce23fe17f4c98d9aa0
- https://git.kernel.org/stable/c/2f945a792f67815abca26fa8a5e863ccf3fa1181
- https://git.kernel.org/stable/c/ba6b9f7cc1108bad6e2c53b1d6e0156379188db7
- https://git.kernel.org/stable/c/cbdda20ce363356698835185801a58a28f644853
- https://git.kernel.org/stable/c/e0e88c25f88b9805572263c9ed20f1d88742feaf
- https://git.kernel.org/stable/c/ee4369260e77821602102dcc7d792de39a56365c
Modified: 2024-11-21
CVE-2022-48673
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible access to freed memory in link clear
After modifying the QP to the Error state, all RX WR would be completed
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
wait for it is done, but destroy the QP and free the link group directly.
So there is a risk that accessing the freed memory in tasklet context.
Here is a crash example:
BUG: unable to handle page fault for address: ffffffff8f220860
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
Oops: 0002 [#1] SMP PTI
CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23
Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32
RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-01-10
CVE-2022-48674
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix pcluster use-after-free on UP platforms
During stress testing with CONFIG_SMP disabled, KASAN reports as below:
==================================================================
BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30
Read of size 8 at addr ffff8881094223f8 by task stress/7789
CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
- https://git.kernel.org/stable/c/2f44013e39984c127c6efedf70e6b5f4e9dcf315
- https://git.kernel.org/stable/c/8ddd001cef5e82d19192e6861068463ecca5f556
- https://git.kernel.org/stable/c/94c34faaafe7b55adc2d8d881db195b646959b9e
- https://git.kernel.org/stable/c/2f44013e39984c127c6efedf70e6b5f4e9dcf315
- https://git.kernel.org/stable/c/8ddd001cef5e82d19192e6861068463ecca5f556
- https://git.kernel.org/stable/c/94c34faaafe7b55adc2d8d881db195b646959b9e
Modified: 2024-11-21
CVE-2022-48675
In the Linux kernel, the following vulnerability has been resolved:
IB/core: Fix a nested dead lock as part of ODP flow
Fix a nested dead lock as part of ODP flow by using mmput_async().
From the below call trace [1] can see that calling mmput() once we have
the umem_odp->umem_mutex locked as required by
ib_umem_odp_map_dma_and_lock() might trigger in the same task the
exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which
may dead lock when trying to lock the same mutex.
Moving to use mmput_async() will solve the problem as the above
exit_mmap() flow will be called in other task and will be executed once
the lock will be available.
[1]
[64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid:
2 flags:0x00004000
[64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]
[64843.077719] Call Trace:
[64843.077722]
- https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785
- https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3
- https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833
- https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f
- https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785
- https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3
- https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833
- https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f
Modified: 2024-11-21
CVE-2022-48686
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix UAF when detecting digest errors We should also bail from the io_work loop when we set rd_enabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted.
- https://git.kernel.org/stable/c/13c80a6c112467bab5e44d090767930555fc17a5
- https://git.kernel.org/stable/c/160f3549a907a50e51a8518678ba2dcf2541abea
- https://git.kernel.org/stable/c/19816a0214684f70b49b25075ff8c402fdd611d3
- https://git.kernel.org/stable/c/5914fa32ef1b7766fea933f9eed94ac5c00aa7ff
- https://git.kernel.org/stable/c/c3eb461aa56e6fa94fb80442ba2586bd223a8886
- https://git.kernel.org/stable/c/13c80a6c112467bab5e44d090767930555fc17a5
- https://git.kernel.org/stable/c/160f3549a907a50e51a8518678ba2dcf2541abea
- https://git.kernel.org/stable/c/19816a0214684f70b49b25075ff8c402fdd611d3
- https://git.kernel.org/stable/c/5914fa32ef1b7766fea933f9eed94ac5c00aa7ff
- https://git.kernel.org/stable/c/c3eb461aa56e6fa94fb80442ba2586bd223a8886
Modified: 2024-11-21
CVE-2022-48687
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix out-of-bounds read when setting HMAC data.
The SRv6 layer allows defining HMAC data that can later be used to sign IPv6
Segment Routing Headers. This configuration is realised via netlink through
four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and
SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual
length of the SECRET attribute, it is possible to provide invalid combinations
(e.g., secret = "", secretlen = 64). This case is not checked in the code and
with an appropriately crafted netlink message, an out-of-bounds read of up
to 64 bytes (max secret length) can occur past the skb end pointer and into
skb_shared_info:
Breakpoint 1, seg6_genl_sethmac (skb=
- https://git.kernel.org/stable/c/076f2479fc5a15c4a970ca3b5e57d42ba09a31fa
- https://git.kernel.org/stable/c/3df71e11a4773d775c3633c44319f7acdb89011c
- https://git.kernel.org/stable/c/55195563ec29f80f984237b743de0e2b6ba4d093
- https://git.kernel.org/stable/c/56ad3f475482bca55b0ae544031333018eb145b3
- https://git.kernel.org/stable/c/84a53580c5d2138c7361c7c3eea5b31827e63b35
- https://git.kernel.org/stable/c/dc9dbd65c803af1607484fed5da50d41dc8dd864
- https://git.kernel.org/stable/c/f684c16971ed5e77dfa25a9ad25b5297e1f58eab
- https://git.kernel.org/stable/c/076f2479fc5a15c4a970ca3b5e57d42ba09a31fa
- https://git.kernel.org/stable/c/3df71e11a4773d775c3633c44319f7acdb89011c
- https://git.kernel.org/stable/c/55195563ec29f80f984237b743de0e2b6ba4d093
- https://git.kernel.org/stable/c/56ad3f475482bca55b0ae544031333018eb145b3
- https://git.kernel.org/stable/c/84a53580c5d2138c7361c7c3eea5b31827e63b35
- https://git.kernel.org/stable/c/dc9dbd65c803af1607484fed5da50d41dc8dd864
- https://git.kernel.org/stable/c/f684c16971ed5e77dfa25a9ad25b5297e1f58eab
Modified: 2024-11-21
CVE-2022-48688
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix kernel crash during module removal
The driver incorrectly frees client instance and subsequent
i40e module removal leads to kernel crash.
Reproducer:
1. Do ethtool offline test followed immediately by another one
host# ethtool -t eth0 offline; ethtool -t eth0 offline
2. Remove recursively irdma module that also removes i40e module
host# modprobe -r irdma
Result:
[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting
[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished
[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting
[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished
[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110
[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2
[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01
[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1
[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030
[ 8687.768755] #PF: supervisor read access in kernel mode
[ 8687.773895] #PF: error_code(0x0000) - not-present page
[ 8687.779034] PGD 0 P4D 0
[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2
[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019
[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]
[ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b
[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202
[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000
[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000
[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000
[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0
[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008
[ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000
[ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0
[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 8687.905572] PKRU: 55555554
[ 8687.908286] Call Trace:
[ 8687.910737]
- https://git.kernel.org/stable/c/2ed94383f3a2693dbf5bc47c514b42524bd8f9ae
- https://git.kernel.org/stable/c/342d77769a6cceb3df7720a1e18baa4339eee3fc
- https://git.kernel.org/stable/c/38af35bec59a8431a1eb29da994a0a45cba275d9
- https://git.kernel.org/stable/c/5332a094514852d5e58c278cf4193adb937337fc
- https://git.kernel.org/stable/c/c49f320e2492738d478bc427dcd54ccfe0cba746
- https://git.kernel.org/stable/c/fb8396aeda5872369a8ed6d2301e2c86e303c520
- https://git.kernel.org/stable/c/2ed94383f3a2693dbf5bc47c514b42524bd8f9ae
- https://git.kernel.org/stable/c/342d77769a6cceb3df7720a1e18baa4339eee3fc
- https://git.kernel.org/stable/c/38af35bec59a8431a1eb29da994a0a45cba275d9
- https://git.kernel.org/stable/c/5332a094514852d5e58c278cf4193adb937337fc
- https://git.kernel.org/stable/c/c49f320e2492738d478bc427dcd54ccfe0cba746
- https://git.kernel.org/stable/c/fb8396aeda5872369a8ed6d2301e2c86e303c520
Modified: 2024-11-21
CVE-2022-48689
In the Linux kernel, the following vulnerability has been resolved: tcp: TX zerocopy should not sense pfmemalloc status We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths. Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives. There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles. Note to stable teams : You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq. Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index. Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive. Backporting to older kernel versions seems not necessary. [1] BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:105 [inline] lru_add_fn+0x440/0x520 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 folio_batch_add_and_move mm/swap.c:263 [inline] folio_add_lru+0xf1/0x140 mm/swap.c:490 filemap_add_folio+0xf8/0x150 mm/filemap.c:948 __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 ext4_file_write_iter+0x2e3/0x1210 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x468/0x760 fs/read_write.c:578 ksys_write+0xe8/0x1a0 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write fs/read_write.c:640 [inline] __x64_sys_write+0x3e/0x50 fs/read_write.c:640 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1740 [inline] __skb_fill_page_desc include/linux/skbuff.h:2422 [inline] skb_fill_page_desc include/linux/skbuff.h:2443 [inline] tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1249 __do_sys_sendfile64 fs/read_write.c:1317 [inline] __se_sys_sendfile64 fs/read_write.c:1303 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xffffea0004a1d288 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
- https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775
- https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83
- https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915
- https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775
- https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83
- https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915
Modified: 2025-09-19
CVE-2022-48690
In the Linux kernel, the following vulnerability has been resolved: ice: Fix DMA mappings leak Fix leak, when user changes ring parameters. During reallocation of RX buffers, new DMA mappings are created for those buffers. New buffers with different RX ring count should substitute older ones, but those buffers were freed in ice_vsi_cfg_rxq and reallocated again with ice_alloc_rx_buf. kfree on rx_buf caused leak of already mapped DMA. Reallocate ZC with xdp_buf struct, when BPF program loads. Reallocate back to rx_buf, when BPF program unloads. If BPF program is loaded/unloaded and XSK pools are created, reallocate RX queues accordingly in XDP_SETUP_XSK_POOL handler. Steps for reproduction: while : do for ((i=0; i<=8160; i=i+32)) do ethtool -G enp130s0f0 rx $i tx $i sleep 0.5 ethtool -g enp130s0f0 done done
Modified: 2024-11-21
CVE-2022-48691
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: clean up hook list when offload flags check fails
splice back the hook list so nft_chain_release_hook() has a chance to
release the hooks.
BUG: memory leak
unreferenced object 0xffff88810180b100 (size 96):
comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s)
hex dump (first 32 bytes):
28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#.....
90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................
backtrace:
[
- https://git.kernel.org/stable/c/1ce55ec5cb7c573c983dffbe290b8d17caf1f157
- https://git.kernel.org/stable/c/77972a36ecc4db7fc7c68f0e80714263c5f03f65
- https://git.kernel.org/stable/c/910891a2a44cdc49efcc4fe7459c1085ba00d0f4
- https://git.kernel.org/stable/c/94ed8eeb8d9aeb00e4f4e19b83a2e28b6442fbc5
- https://git.kernel.org/stable/c/1ce55ec5cb7c573c983dffbe290b8d17caf1f157
- https://git.kernel.org/stable/c/77972a36ecc4db7fc7c68f0e80714263c5f03f65
- https://git.kernel.org/stable/c/910891a2a44cdc49efcc4fe7459c1085ba00d0f4
- https://git.kernel.org/stable/c/94ed8eeb8d9aeb00e4f4e19b83a2e28b6442fbc5
Modified: 2024-11-21
CVE-2022-48692
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Set scmnd->result only when scmnd is not NULL
This change fixes the following kernel NULL pointer dereference
which is reproduced by blktests srp/007 occasionally.
BUG: kernel NULL pointer dereference, address: 0000000000000170
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014
Workqueue: 0x0 (kblockd)
RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]
Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9
RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282
RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000
RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff
RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001
R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000
R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/12f35199a2c0551187edbf8eb01379f0598659fa
- https://git.kernel.org/stable/c/a8edd49c94b4b08019ed7d6dd794fca8078a4deb
- https://git.kernel.org/stable/c/f022576aa03c2385ea7f2b27ee5b331e43abf624
- https://git.kernel.org/stable/c/f2c70f56f762e5dc3b0d7dc438fbb137cb116413
- https://git.kernel.org/stable/c/12f35199a2c0551187edbf8eb01379f0598659fa
- https://git.kernel.org/stable/c/a8edd49c94b4b08019ed7d6dd794fca8078a4deb
- https://git.kernel.org/stable/c/f022576aa03c2385ea7f2b27ee5b331e43abf624
- https://git.kernel.org/stable/c/f2c70f56f762e5dc3b0d7dc438fbb137cb116413
Modified: 2024-11-21
CVE-2022-48693
In the Linux kernel, the following vulnerability has been resolved: soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs In brcmstb_pm_probe(), there are two kinds of leak bugs: (1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path
- https://git.kernel.org/stable/c/0284b4e6dec6088a41607aa3f42bf51edff01883
- https://git.kernel.org/stable/c/1085f5080647f0c9f357c270a537869191f7f2a1
- https://git.kernel.org/stable/c/43245c77d9efd8c9eb91bf225d07954dcf32204d
- https://git.kernel.org/stable/c/57b2897ec3ffe4cbe018446be6d04432919dca6b
- https://git.kernel.org/stable/c/653500b400d5576940b7429690f7197199ddcc82
- https://git.kernel.org/stable/c/6dc0251638a4a1a998506dbd4627f8317e907558
- https://git.kernel.org/stable/c/0284b4e6dec6088a41607aa3f42bf51edff01883
- https://git.kernel.org/stable/c/1085f5080647f0c9f357c270a537869191f7f2a1
- https://git.kernel.org/stable/c/43245c77d9efd8c9eb91bf225d07954dcf32204d
- https://git.kernel.org/stable/c/57b2897ec3ffe4cbe018446be6d04432919dca6b
- https://git.kernel.org/stable/c/653500b400d5576940b7429690f7197199ddcc82
- https://git.kernel.org/stable/c/6dc0251638a4a1a998506dbd4627f8317e907558
Modified: 2024-12-26
CVE-2022-48695
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix use-after-free warning Fix the following use-after-free warning which is observed during controller reset: refcount_t: underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
- https://git.kernel.org/stable/c/41acb064c4e013808bc7d5fc1b506fa449425b0b
- https://git.kernel.org/stable/c/5682c94644fde72f72bded6580c38189ffc856b5
- https://git.kernel.org/stable/c/6229fa494a5949be209bc73afbc5d0a749c2e3c7
- https://git.kernel.org/stable/c/82efb917eeb27454dc4c6fe26432fc8f6c75bc16
- https://git.kernel.org/stable/c/991df3dd5144f2e6b1c38b8d20ed3d4d21e20b34
- https://git.kernel.org/stable/c/b8fc9e91b931215110ba824d1a2983c5f60b6f82
- https://git.kernel.org/stable/c/d4959d09b76eb7a4146f5133962b88d3bddb63d6
- https://git.kernel.org/stable/c/ea10a652ad2ae2cf3eced6f632a5c98f26727057
- https://git.kernel.org/stable/c/41acb064c4e013808bc7d5fc1b506fa449425b0b
- https://git.kernel.org/stable/c/5682c94644fde72f72bded6580c38189ffc856b5
- https://git.kernel.org/stable/c/6229fa494a5949be209bc73afbc5d0a749c2e3c7
- https://git.kernel.org/stable/c/82efb917eeb27454dc4c6fe26432fc8f6c75bc16
- https://git.kernel.org/stable/c/991df3dd5144f2e6b1c38b8d20ed3d4d21e20b34
- https://git.kernel.org/stable/c/b8fc9e91b931215110ba824d1a2983c5f60b6f82
- https://git.kernel.org/stable/c/d4959d09b76eb7a4146f5133962b88d3bddb63d6
- https://git.kernel.org/stable/c/ea10a652ad2ae2cf3eced6f632a5c98f26727057
Modified: 2025-04-08
CVE-2022-48696
In the Linux kernel, the following vulnerability has been resolved: regmap: spi: Reserve space for register address/padding Currently the max_raw_read and max_raw_write limits in regmap_spi struct do not take into account the additional size of the transmitted register address and padding. This may result in exceeding the maximum permitted SPI message size, which could cause undefined behaviour, e.g. data corruption. Fix regmap_get_spi_bus() to properly adjust the above mentioned limits by reserving space for the register address/padding as set in the regmap configuration.
Modified: 2025-04-08
CVE-2022-48697
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a use-after-free Fix the following use-after-free complaint triggered by blktests nvme/004: BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30
- https://git.kernel.org/stable/c/17f121ca3ec6be0fb32d77c7f65362934a38cc8e
- https://git.kernel.org/stable/c/4484ce97a78171668c402e0c45db7f760aea8060
- https://git.kernel.org/stable/c/6a02a61e81c231cc5c680c5dbf8665275147ac52
- https://git.kernel.org/stable/c/8d66989b5f7bb28bba2f8e1e2ffc8bfef4a10717
- https://git.kernel.org/stable/c/be01f1c988757b95f11f090a9f491365670a522b
- https://git.kernel.org/stable/c/ebf46da50beb78066674354ad650606a467e33fa
- https://git.kernel.org/stable/c/17f121ca3ec6be0fb32d77c7f65362934a38cc8e
- https://git.kernel.org/stable/c/4484ce97a78171668c402e0c45db7f760aea8060
- https://git.kernel.org/stable/c/6a02a61e81c231cc5c680c5dbf8665275147ac52
- https://git.kernel.org/stable/c/8d66989b5f7bb28bba2f8e1e2ffc8bfef4a10717
- https://git.kernel.org/stable/c/be01f1c988757b95f11f090a9f491365670a522b
- https://git.kernel.org/stable/c/ebf46da50beb78066674354ad650606a467e33fa
Modified: 2025-04-08
CVE-2022-48698
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix memory leak when using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput().
- https://git.kernel.org/stable/c/3a6279d243cb035eaaff1450980b40cf19748f05
- https://git.kernel.org/stable/c/58acd2ebae034db3bacf38708f508fbd12ae2e54
- https://git.kernel.org/stable/c/cbfac7fa491651c57926c99edeb7495c6c1aeac2
- https://git.kernel.org/stable/c/3a6279d243cb035eaaff1450980b40cf19748f05
- https://git.kernel.org/stable/c/58acd2ebae034db3bacf38708f508fbd12ae2e54
- https://git.kernel.org/stable/c/cbfac7fa491651c57926c99edeb7495c6c1aeac2
Modified: 2025-09-19
CVE-2022-48699
In the Linux kernel, the following vulnerability has been resolved: sched/debug: fix dentry leak in update_sched_domain_debugfs Kuyo reports that the pattern of using debugfs_remove(debugfs_lookup()) leaks a dentry and with a hotplug stress test, the machine eventually runs out of memory. Fix this up by using the newly created debugfs_lookup_and_remove() call instead which properly handles the dentry reference counting logic.
- https://git.kernel.org/stable/c/0c32a93963e03c03e561d5a066eedad211880ba3
- https://git.kernel.org/stable/c/26e9a1ded8923510e5529fbb28390b22228700c2
- https://git.kernel.org/stable/c/c2e406596571659451f4b95e37ddfd5a8ef1d0dc
- https://git.kernel.org/stable/c/0c32a93963e03c03e561d5a066eedad211880ba3
- https://git.kernel.org/stable/c/26e9a1ded8923510e5529fbb28390b22228700c2
- https://git.kernel.org/stable/c/c2e406596571659451f4b95e37ddfd5a8ef1d0dc
Modified: 2025-03-05
CVE-2022-48701
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface() There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and the number of it's interfaces less than 4, an out-of-bounds read bug occurs when parsing the interface descriptor for this device. Fix this by checking the number of interfaces.
- https://git.kernel.org/stable/c/0492798bf8dfcc09c9337a1ba065da1d1ca68712
- https://git.kernel.org/stable/c/2a308e415d247a23d4d64c964c02e782eede2936
- https://git.kernel.org/stable/c/6123bec8480d23369e2ee0b2208611619f269faf
- https://git.kernel.org/stable/c/8293e61bbf908b18ff9935238d4fc2ad359e3fe0
- https://git.kernel.org/stable/c/91904870370fd986c29719846ed76d559de43251
- https://git.kernel.org/stable/c/98e8e67395cc6d0cdf3a771f86ea42d0ee6e59dd
- https://git.kernel.org/stable/c/b970518014f2f0f6c493fb86c1e092b936899061
- https://git.kernel.org/stable/c/e53f47f6c1a56d2af728909f1cb894da6b43d9bf
- https://git.kernel.org/stable/c/0492798bf8dfcc09c9337a1ba065da1d1ca68712
- https://git.kernel.org/stable/c/2a308e415d247a23d4d64c964c02e782eede2936
- https://git.kernel.org/stable/c/6123bec8480d23369e2ee0b2208611619f269faf
- https://git.kernel.org/stable/c/8293e61bbf908b18ff9935238d4fc2ad359e3fe0
- https://git.kernel.org/stable/c/91904870370fd986c29719846ed76d559de43251
- https://git.kernel.org/stable/c/98e8e67395cc6d0cdf3a771f86ea42d0ee6e59dd
- https://git.kernel.org/stable/c/b970518014f2f0f6c493fb86c1e092b936899061
- https://git.kernel.org/stable/c/e53f47f6c1a56d2af728909f1cb894da6b43d9bf
Modified: 2025-03-05
CVE-2022-48702
In the Linux kernel, the following vulnerability has been resolved:
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
The voice allocator sometimes begins allocating from near the end of the
array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough
index so that first_voice + requested_voice_count > NUM_G (64).
The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced
by calling aplay multiple times with 16 channels:
aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
index 65 is out of range for type 'snd_emu10k1_voice [64]'
CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7
Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010
Call Trace:
- https://git.kernel.org/stable/c/39a90720f3abe96625d1224e7a7463410875de4c
- https://git.kernel.org/stable/c/4204a01ffce97cae1d59edc5848f02be5b2b9178
- https://git.kernel.org/stable/c/45321a7d02b7cf9b3f97e3987fc1e4d649b82da2
- https://git.kernel.org/stable/c/45814a53514e10a8014906c882e0d0d38df39cc1
- https://git.kernel.org/stable/c/637c5310acb48fffcc5657568db3f3e9bc719bfa
- https://git.kernel.org/stable/c/6b0e260ac3cf289e38446552461caa65e6dab275
- https://git.kernel.org/stable/c/88aac6684cf8bc885cca15463cb4407e91f28ff7
- https://git.kernel.org/stable/c/d29f59051d3a07b81281b2df2b8c9dfe4716067f
- https://git.kernel.org/stable/c/39a90720f3abe96625d1224e7a7463410875de4c
- https://git.kernel.org/stable/c/4204a01ffce97cae1d59edc5848f02be5b2b9178
- https://git.kernel.org/stable/c/45321a7d02b7cf9b3f97e3987fc1e4d649b82da2
- https://git.kernel.org/stable/c/45814a53514e10a8014906c882e0d0d38df39cc1
- https://git.kernel.org/stable/c/637c5310acb48fffcc5657568db3f3e9bc719bfa
- https://git.kernel.org/stable/c/6b0e260ac3cf289e38446552461caa65e6dab275
- https://git.kernel.org/stable/c/88aac6684cf8bc885cca15463cb4407e91f28ff7
- https://git.kernel.org/stable/c/d29f59051d3a07b81281b2df2b8c9dfe4716067f
Modified: 2025-07-17
CVE-2022-48703
In the Linux kernel, the following vulnerability has been resolved: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR In some case, the GDDV returns a package with a buffer which has zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10). Then the data_vault_read() got NULL point dereference problem when accessing the 0x10 value in data_vault. [ 71.024560] BUG: kernel NULL pointer dereference, address: 0000000000000010 This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or NULL value in data_vault.
- https://git.kernel.org/stable/c/39d5137085a6c37ace4680ee4d24020a4a03e7dc
- https://git.kernel.org/stable/c/7931e28098a4c1a2a6802510b0cbe57546d2049d
- https://git.kernel.org/stable/c/dae42083b045a4ddf71c57cf350cb2412b5915c2
- https://git.kernel.org/stable/c/7931e28098a4c1a2a6802510b0cbe57546d2049d
- https://git.kernel.org/stable/c/dae42083b045a4ddf71c57cf350cb2412b5915c2
Modified: 2025-09-19
CVE-2022-48704
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: add a force flush to delay work when radeon
Although radeon card fence and wait for gpu to finish processing current batch rings,
there is still a corner case that radeon lockup work queue may not be fully flushed,
and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
put device in D3hot state.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
> Configuration and Message requests are the only TLPs accepted by a Function in
> the D3hot state. All other received Requests must be handled as Unsupported Requests,
> and all received Completions may optionally be handled as Unexpected Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address 00008800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [
- https://git.kernel.org/stable/c/16cb367daa446923d82e332537f446a4cc784b40
- https://git.kernel.org/stable/c/4e25e8f27fdbdc6fd55cc572a9939bf24500b9e8
- https://git.kernel.org/stable/c/5a7a5b2edac4b05abd744eeaebda46d9dacd952d
- https://git.kernel.org/stable/c/826b46fd5974113515abe9e4fc8178009a8ce18c
- https://git.kernel.org/stable/c/b878da58df2c40b08914d3960e2224040fd1fbfe
- https://git.kernel.org/stable/c/c0a45f41fde4a0f2c900f719817493ee5c4a5aa3
- https://git.kernel.org/stable/c/c72d97146fc5a4dff381b1737f6167e89860430d
- https://git.kernel.org/stable/c/f461950fdc374a3ada5a63c669d997de4600dffe
- https://git.kernel.org/stable/c/16cb367daa446923d82e332537f446a4cc784b40
- https://git.kernel.org/stable/c/4e25e8f27fdbdc6fd55cc572a9939bf24500b9e8
- https://git.kernel.org/stable/c/5a7a5b2edac4b05abd744eeaebda46d9dacd952d
- https://git.kernel.org/stable/c/826b46fd5974113515abe9e4fc8178009a8ce18c
- https://git.kernel.org/stable/c/b878da58df2c40b08914d3960e2224040fd1fbfe
- https://git.kernel.org/stable/c/c0a45f41fde4a0f2c900f719817493ee5c4a5aa3
- https://git.kernel.org/stable/c/c72d97146fc5a4dff381b1737f6167e89860430d
- https://git.kernel.org/stable/c/f461950fdc374a3ada5a63c669d997de4600dffe
Modified: 2025-09-19
CVE-2022-48705
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921e: fix crash in chip reset fail
In case of drv own fail in reset, we may need to run mac_reset several
times. The sequence would trigger system crash as the log below.
Because we do not re-enable/schedule "tx_napi" before disable it again,
the process would keep waiting for state change in napi_diable(). To
avoid the problem and keep status synchronize for each run, goto final
resource handling if drv own failed.
[ 5857.353423] mt7921e 0000:3b:00.0: driver own failed
[ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own
[ 5859.633430] mt7921e 0000:3b:00.0: driver own failed
[ 5859.633444] ------------[ cut here ]------------
[ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d
[ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]
[ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150
[ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202
......
[ 5859.633766] Call Trace:
[ 5859.633768]
Modified: 2025-10-01
CVE-2022-49563
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for RSA Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.
Modified: 2025-10-01
CVE-2022-49564
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for DH Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.
Modified: 2025-10-22
CVE-2022-49565
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/lbr: Fix unchecked MSR access error on HSW
The fuzzer triggers the below trace.
[ 7763.384369] unchecked MSR access error: WRMSR to 0x689
(tried to write 0x1fffffff8101349e) at rIP: 0xffffffff810704a4
(native_write_msr+0x4/0x20)
[ 7763.397420] Call Trace:
[ 7763.399881]
Modified: 2025-10-01
CVE-2022-49566
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix memory leak in RSA When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is used, some components of the private key persist even after the TFM is released. Replace the explicit calls to free the buffers in qat_rsa_exit_tfm() with a call to qat_rsa_clear_ctx() which frees all buffers referenced in the TFM context.
Modified: 2025-12-23
CVE-2022-49567
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix uninit-value in mpol_rebind_policy() mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask when pol->mode is MPOL_LOCAL. Check pol->mode before access pol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c). BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline] BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae KMSAN: uninit-value in mpol_rebind_task (2) https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dc This patch seems to fix below bug too. KMSAN: uninit-value in mpol_rebind_mm (2) https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926b The uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy(). When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c `mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags` is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags; will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind() pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized, which will be accessed in mpol_rebind_policy().
Modified: 2025-10-01
CVE-2022-49568
In the Linux kernel, the following vulnerability has been resolved: KVM: Don't null dereference ops->destroy A KVM device cleanup happens in either of two callbacks: 1) destroy() which is called when the VM is being destroyed; 2) release() which is called when a device fd is closed. Most KVM devices use 1) but Book3s's interrupt controller KVM devices (XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during the machine execution. The error handling in kvm_ioctl_create_device() assumes destroy() is always defined which leads to NULL dereference as discovered by Syzkaller. This adds a checks for destroy!=NULL and adds a missing release(). This is not changing kvm_destroy_devices() as devices with defined release() should have been removed from the KVM devices list by then.
- https://git.kernel.org/stable/c/170465715a60cbb7876e6b961b21bd3225469da8
- https://git.kernel.org/stable/c/3616776bc51cd3262bb1be60cc01c72e0a1959cf
- https://git.kernel.org/stable/c/d4a5a79b780891c5cbdfdc6124d46fdf8d13dba1
- https://git.kernel.org/stable/c/e8bc2427018826e02add7b0ed0fc625a60390ae5
- https://git.kernel.org/stable/c/e91665fbbf3ccb268b268a7d71a6513538d813ac
Modified: 2025-10-01
CVE-2022-49569
In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA transfers In case a IRQ based transfer times out the bcm2835_spi_handle_err() function is called. Since commit 1513ceee70f2 ("spi: bcm2835: Drop dma_pending flag") the TX and RX DMA transfers are unconditionally canceled, leading to NULL pointer derefs if ctlr->dma_tx or ctlr->dma_rx are not set. Fix the NULL pointer deref by checking that ctlr->dma_tx and ctlr->dma_rx are valid pointers before accessing them.
- https://git.kernel.org/stable/c/49ffa473218012e765682343de2052eb4c1f06a7
- https://git.kernel.org/stable/c/4ceaa684459d414992acbefb4e4c31f2dfc50641
- https://git.kernel.org/stable/c/58466e05390043d2805685c70f55f3f59711bdf2
- https://git.kernel.org/stable/c/684896e675edd8b669fd3e9f547c5038222d85bc
- https://git.kernel.org/stable/c/76668d2a2f367d25ff448e6d7087406af7d7bb2b
Modified: 2025-10-01
CVE-2022-49570
In the Linux kernel, the following vulnerability has been resolved: gpio: gpio-xilinx: Fix integer overflow Current implementation is not able to configure more than 32 pins due to incorrect data type. So type casting with unsigned long to avoid it.
Modified: 2025-10-01
CVE-2022-49571
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_max_reordering. While reading sysctl_tcp_max_reordering, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/064852663308c801861bd54789d81421fa4c2928
- https://git.kernel.org/stable/c/46deb91ac8a790286ad6d24cf92e7ab0ab2582bb
- https://git.kernel.org/stable/c/50a1d3d097503a90cf84ebe120afcde37e9c33b3
- https://git.kernel.org/stable/c/5e38cee24f19d19280c68f1ac8bf6790d607f60a
- https://git.kernel.org/stable/c/a11e5b3e7a59fde1a90b0eaeaa82320495cf8cae
- https://git.kernel.org/stable/c/ce3731c61589ed73364a5b55ce34131762ef9b60
Modified: 2025-10-01
CVE-2022-49572
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_slow_start_after_idle. While reading sysctl_tcp_slow_start_after_idle, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/0e3f82a03ec8c3808e87283e12946227415706c9
- https://git.kernel.org/stable/c/369d99c2b89f54473adcf9acdf40ea562b5a6e0e
- https://git.kernel.org/stable/c/3b26e11b07a09b31247688bec61e2925d4a571b6
- https://git.kernel.org/stable/c/41aeba4506f6b70ec7500c6fe202731a4ba29fe5
- https://git.kernel.org/stable/c/4845b5713ab18a1bb6e31d1fbb4d600240b8b691
- https://git.kernel.org/stable/c/68b6f9506747d507c7bfa374d178929b4157e8c6
Modified: 2025-10-01
CVE-2022-49573
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_early_retrans. While reading sysctl_tcp_early_retrans, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/11e8b013d16e5db63f8f76acceb5b86964098aaa
- https://git.kernel.org/stable/c/488d3ad98ef7cddce7054193dbae6b4349c6807d
- https://git.kernel.org/stable/c/5037ca9e4b169cc9aed0174d658c3d81fdaf8ea5
- https://git.kernel.org/stable/c/52e65865deb6a36718a463030500f16530eaab74
- https://git.kernel.org/stable/c/83767fe800a311370330d4ec83aa76093b744a80
- https://git.kernel.org/stable/c/d5975f6376ce90c2c483ae36bf88c9cface4c13b
Modified: 2025-10-01
CVE-2022-49574
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_recovery. While reading sysctl_tcp_recovery, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/52ee7f5c4811ce6be1becd14d38ba1f8a8a0df81
- https://git.kernel.org/stable/c/92c35113c63306091df9211375eebd0abd8c2160
- https://git.kernel.org/stable/c/a31e2d0cb5cfa2aae3144cac04f25031d5d20fb4
- https://git.kernel.org/stable/c/c7a492db1f7c37c758a66915908677bd8bc5d368
- https://git.kernel.org/stable/c/d8781f7cd04091744f474a2bada74772084b9dc9
- https://git.kernel.org/stable/c/e7d2ef837e14a971a05f60ea08c47f3fed1a36e4
Modified: 2025-10-01
CVE-2022-49575
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_thin_linear_timeouts. While reading sysctl_tcp_thin_linear_timeouts, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/404c53ccdebd11f96954f4070cffac8e0b4d5cb6
- https://git.kernel.org/stable/c/492f3713b282c0e67e951cd804edd22eccc25412
- https://git.kernel.org/stable/c/7c6f2a86ca590d5187a073d987e9599985fb1c7c
- https://git.kernel.org/stable/c/a0f96c4f179cb3560078cefccef105e8f1701210
- https://git.kernel.org/stable/c/cc133e4f4bc225079198192623945bb872c08143
- https://git.kernel.org/stable/c/f4b0295be9a3c4260de4585fac4062e602a88ac7
Modified: 2025-10-01
CVE-2022-49576
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix data-races around sysctl_fib_multipath_hash_fields. While reading sysctl_fib_multipath_hash_fields, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49577
In the Linux kernel, the following vulnerability has been resolved: udp: Fix a data-race around sysctl_udp_l3mdev_accept. While reading sysctl_udp_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/3d72bb4188c708bb16758c60822fc4dda7a95174
- https://git.kernel.org/stable/c/3f2ac2d6511bb0652abf4d7388d65bb9ff1c641c
- https://git.kernel.org/stable/c/cb0d28934ca10f99c47e2c6f451405d6c954fe48
- https://git.kernel.org/stable/c/f39b03bd727a8fea62e82f10fe2e0d753b9930ff
- https://git.kernel.org/stable/c/fcaef69c79ec222e55643e666b80b221e70fa6a8
Modified: 2025-10-01
CVE-2022-49578
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_prot_sock. sysctl_ip_prot_sock is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing.
Modified: 2025-10-01
CVE-2022-49579
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix data-races around sysctl_fib_multipath_hash_policy. While reading sysctl_fib_multipath_hash_policy, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49580
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix a data-race around sysctl_fib_multipath_use_neigh. While reading sysctl_fib_multipath_use_neigh, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/14e996577ed2799a1ed6ffeb71c76d63acb28444
- https://git.kernel.org/stable/c/6727f39e99e0f545d815edebb6c94228485427ec
- https://git.kernel.org/stable/c/87507bcb4f5de16bb419e9509d874f4db6c0ad0f
- https://git.kernel.org/stable/c/b8d345db03b4deffb4f04219a51d3b1e94171b76
- https://git.kernel.org/stable/c/e045d672ba06e1d35bacb56374d350de0ac99066
Modified: 2025-10-22
CVE-2022-49581
In the Linux kernel, the following vulnerability has been resolved: be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case. Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once.
- https://git.kernel.org/stable/c/18043da94c023f3ef09c15017bdb04e8f695ef10
- https://git.kernel.org/stable/c/665cbe91de2f7c97c51ca8fce39aae26477c1948
- https://git.kernel.org/stable/c/8ff4f9df73e5c551a72ee6034886c17e8de6596d
- https://git.kernel.org/stable/c/a5a8fc0679a8fd58d47aa2ebcfc5742631f753f9
- https://git.kernel.org/stable/c/a8569f76df7ec5b4b51155c57523a0b356db5741
- https://git.kernel.org/stable/c/aba8ff847f4f927ad7a1a1ee4a9f29989a1a728f
- https://git.kernel.org/stable/c/d7241f679a59cfe27f92cb5c6272cb429fb1f7ec
- https://git.kernel.org/stable/c/fe4473fc7940f14c4a12db873b9729134c212654
Modified: 2025-10-01
CVE-2022-49582
In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix NULL pointer dereference in dsa_port_reset_vlan_filtering The "ds" iterator variable used in dsa_port_reset_vlan_filtering() -> dsa_switch_for_each_port() overwrites the "dp" received as argument, which is later used to call dsa_port_vlan_filtering() proper. As a result, switches which do enter that code path (the ones with vlan_filtering_is_global=true) will dereference an invalid dp in dsa_port_reset_vlan_filtering() after leaving a VLAN-aware bridge. Use a dedicated "other_dp" iterator variable to avoid this from happening.
Modified: 2025-10-01
CVE-2022-49583
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix handling of dummy receive descriptors Fix memory leak caused by not handling dummy receive descriptor properly. iavf_get_rx_buffer now sets the rx_buffer return value for dummy receive descriptors. Without this patch, when the hardware writes a dummy descriptor, iavf would not free the page allocated for the previous receive buffer. This is an unlikely event but can still happen. [Jesse: massaged commit message]
- https://git.kernel.org/stable/c/2918419c06088f6709ceb543feb01752779ade4c
- https://git.kernel.org/stable/c/6edb818732fc05fda495f5b3a749bd1cee01398b
- https://git.kernel.org/stable/c/a9f49e0060301a9bfebeca76739158d0cf91cdf6
- https://git.kernel.org/stable/c/c6af94324911ef0846af1a5ce5e049ca736db34b
- https://git.kernel.org/stable/c/d88d59faf4e6f9cc4767664206afdb999b10ec77
Modified: 2025-10-22
CVE-2022-49584
In the Linux kernel, the following vulnerability has been resolved:
ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero
It is possible to disable VFs while the PF driver is processing requests
from the VF driver. This can result in a panic.
BUG: unable to handle kernel paging request at 000000000000106c
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- -
Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020
RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe]
Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff
01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 <41> 80 7c 24 4c
00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a
RSP: 0018:ffffb337869f8df8 EFLAGS: 00010002
RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b
RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006
RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780
R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020
R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80
FS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/031af9e617a6f51075d97e56fc9e712c7dde2508
- https://git.kernel.org/stable/c/16f929a5e76fd047fd8697e1e568bdd7d771955c
- https://git.kernel.org/stable/c/1e53834ce541d4fe271cdcca7703e50be0a44f8a
- https://git.kernel.org/stable/c/9d925d2dc82cec2bcbd8625457645d8a548ab22e
- https://git.kernel.org/stable/c/b82de63f8f817b5735480293dda8e92ba8170c52
Modified: 2025-10-01
CVE-2022-49585
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_fastopen_blackhole_timeout. While reading sysctl_tcp_fastopen_blackhole_timeout, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49586
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_fastopen. While reading sysctl_tcp_fastopen, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/03da610696a32578fc4f986479341ce9d430df08
- https://git.kernel.org/stable/c/22938534c611136f35e2ca545bb668073ca5ef49
- https://git.kernel.org/stable/c/25d53d858a6c0b89a6e69e376c2a57c4f4c2c8cc
- https://git.kernel.org/stable/c/448ab998947996a0a451f8229f19087964cf2670
- https://git.kernel.org/stable/c/539d9ab79eba3974b479cad61a8688c41fe62e12
- https://git.kernel.org/stable/c/5a54213318c43f4009ae158347aa6016e3b9b55a
Modified: 2025-10-01
CVE-2022-49587
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_notsent_lowat. While reading sysctl_tcp_notsent_lowat, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/0f75343584ee474303e17efe0610bdd170af1d13
- https://git.kernel.org/stable/c/55be873695ed8912eb77ff46d1d1cadf028bd0f3
- https://git.kernel.org/stable/c/62e56cfeb2ae4b53ae9ca24c80f54093250ce64a
- https://git.kernel.org/stable/c/80d4d0c461674eea87f0977e12a2ecd334b9b79c
- https://git.kernel.org/stable/c/91e21df688f8a75255ca9c459da39ac96300113a
- https://git.kernel.org/stable/c/c1b85c5a34294f7444c13bf828e0e84b0a0eed85
- https://git.kernel.org/stable/c/e9362a993886613ef0284c2a4911c6017c97d803
- https://git.kernel.org/stable/c/fd6f1284e380c377932186042ff0b5c987fb2b92
Modified: 2025-10-01
CVE-2022-49588
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_migrate_req. While reading sysctl_tcp_migrate_req, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49589
In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_qrv. While reading sysctl_igmp_qrv, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);
- https://git.kernel.org/stable/c/8ebcc62c738f68688ee7c6fec2efe5bc6d3d7e60
- https://git.kernel.org/stable/c/9eeb3a7702998bdccbfcc37997b5dd9215b9a7f7
- https://git.kernel.org/stable/c/b399ffafffba39f47b731b26a5da1dc0ffc4b3ad
- https://git.kernel.org/stable/c/c2954671010cd1127d1ffa328c6e6f8e99930982
- https://git.kernel.org/stable/c/c721324afc589f8ea54bae04756b150aeaae5fa4
- https://git.kernel.org/stable/c/e20dd1b0e0ea15bee1e528536a0840dba972ca0e
Modified: 2025-10-01
CVE-2022-49590
In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_llm_reports. While reading sysctl_igmp_llm_reports, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))
- https://git.kernel.org/stable/c/1656ecaddf90e2a070ec2d2404cdae3edf80faca
- https://git.kernel.org/stable/c/260446eb8e5541402b271343a4516f2b33dec1e4
- https://git.kernel.org/stable/c/46307adceb67bdf2ec38408dd9cebc378a6b5c46
- https://git.kernel.org/stable/c/473aad9ad57ff760005377e6f45a2ad4210e08ce
- https://git.kernel.org/stable/c/a84b4afaca2573ed3aed1f8854aefe3ca5a82e72
- https://git.kernel.org/stable/c/d77969e7d4ccc26bf1f414a39ef35050a83ba6d5
- https://git.kernel.org/stable/c/ed876e99ccf417b8bd7fd8408ba5e8b008e46cc8
- https://git.kernel.org/stable/c/f6da2267e71106474fbc0943dc24928b9cb79119
Modified: 2025-10-01
CVE-2022-49591
In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: ksz_common: Fix refcount leak bug In ksz_switch_register(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount.
Modified: 2025-10-22
CVE-2022-49592
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix dma queue left shift overflow issue
When queue number is > 4, left shift overflows due to 32 bits
integer variable. Mask calculation is wrong for MTL_RXQ_DMA_MAP1.
If CONFIG_UBSAN is enabled, kernel dumps below warning:
[ 10.363842] ==================================================================
[ 10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/
linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:224:12
[ 10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int'
[ 10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg
[ 10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021
[ 10.363958] Call Trace:
[ 10.363960]
- https://git.kernel.org/stable/c/508d86ead36cbd8dfb60773a33276790d668c473
- https://git.kernel.org/stable/c/573768dede0e2b7de38ecbc11cb3ee47643902dc
- https://git.kernel.org/stable/c/613b065ca32e90209024ec4a6bb5ca887ee70980
- https://git.kernel.org/stable/c/7c687a893f5cae5ca40d189635602e93af9bab73
- https://git.kernel.org/stable/c/a3ac79f38d354b10925824899cdbd2caadce55ba
- https://git.kernel.org/stable/c/ad2febdfbd01e1d092a08bfdba92ede79ea05ff3
- https://git.kernel.org/stable/c/e846bde09677fa3b203057846620b7ed96540f5f
Modified: 2025-10-01
CVE-2022-49593
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_probe_interval. While reading sysctl_tcp_probe_interval, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/2a85388f1d94a9f8b5a529118a2c5eaa0520d85c
- https://git.kernel.org/stable/c/73a11588751a2c13f25d9da8117efc9a79b1843f
- https://git.kernel.org/stable/c/80dabd089086e6553b7acfcff2ec223bdada87a1
- https://git.kernel.org/stable/c/b14cc8afbbcbc6dce4797913c0b85266b897f541
- https://git.kernel.org/stable/c/b3798d3519eda9c409bb0815b0102f27ec42468d
- https://git.kernel.org/stable/c/c61aede097d350d890fa1edc9521b0072e14a0b8
- https://git.kernel.org/stable/c/e6b6f027e2854a51f345a5e3e808d7a88001d4f8
Modified: 2025-10-01
CVE-2022-49594
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_mtu_probe_floor. While reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/033963b220633ed1602d458e7e4ac06afa9fefb2
- https://git.kernel.org/stable/c/8e92d4423615a5257d0d871fc067aa561f597deb
- https://git.kernel.org/stable/c/cc36c37f5fe066c4708e623ead96dc8f57224bf5
- https://git.kernel.org/stable/c/d5bece4df6090395f891110ef52a6f82d16685db
- https://git.kernel.org/stable/c/e2ecbf3f0aa88277d43908c53b99399d55729ff9
Modified: 2025-10-01
CVE-2022-49595
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_probe_threshold. While reading sysctl_tcp_probe_threshold, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/44768749980d53bc01980d9c060f736808d11af0
- https://git.kernel.org/stable/c/92c0aa4175474483d6cf373314343d4e624e882a
- https://git.kernel.org/stable/c/96900fa61777402eb5056269d8000aace33a8b6c
- https://git.kernel.org/stable/c/9b5dc7ad6da1373d3c60d4b869d688f996e5d219
- https://git.kernel.org/stable/c/b04817c94fbd285a967d9b830b274fe9998c9c0b
- https://git.kernel.org/stable/c/d452ce36f2d4c402fa3f5275c9677f80166e7fc6
- https://git.kernel.org/stable/c/f524c3e7f6cdad66b3b6a912cef47b656f8b0de3
- https://git.kernel.org/stable/c/fa5fb2cf9393db898772db8cb897ed5fd265eb78
Modified: 2025-10-01
CVE-2022-49596
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_min_snd_mss. While reading sysctl_tcp_min_snd_mss, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/0d8a39feb58910a7f7746b1770ee5578cc551fe6
- https://git.kernel.org/stable/c/0fc9357282df055e30990b29f4b7afa53ab42cdb
- https://git.kernel.org/stable/c/78eb166cdefcc3221c8c7c1e2d514e91a2eb5014
- https://git.kernel.org/stable/c/97992e8feff33b3ae154a113ec398546bbacda80
- https://git.kernel.org/stable/c/fdb96b69f5909ffcdd6f1e0902219fc6d7689ff7
Modified: 2025-10-01
CVE-2022-49597
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_base_mss. While reading sysctl_tcp_base_mss, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/30b73edc1d2459ba2c71cb58fbf84a1a6e640fbf
- https://git.kernel.org/stable/c/4d7dea651b7fe0322be95054f64e3711afccc543
- https://git.kernel.org/stable/c/514d2254c7b8aa2d257f5ffc79f0d96be2d6bfda
- https://git.kernel.org/stable/c/88d78bc097cd8ebc6541e93316c9d9bf651b13e8
- https://git.kernel.org/stable/c/9ca18116bc16ec31b9a3ce28ea1350badfa36128
Modified: 2025-10-01
CVE-2022-49598
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_mtu_probing. While reading sysctl_tcp_mtu_probing, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/77a04845f0d28a3561494a5f3121488470a968a4
- https://git.kernel.org/stable/c/7e8fc428a7f680f1c4994a40e52d7f95a9a93038
- https://git.kernel.org/stable/c/aabe9438fdfe004e021d5a206227ec105dbe2416
- https://git.kernel.org/stable/c/b0920ca09d9ce19980c8391b9002455baa9c1417
- https://git.kernel.org/stable/c/f47d00e077e7d61baf69e46dde3210c886360207
- https://git.kernel.org/stable/c/f966773e13cdd3f12baa90071b7b660f6c633ccb
Modified: 2025-10-01
CVE-2022-49599
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_l3mdev_accept. While reading sysctl_tcp_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49600
In the Linux kernel, the following vulnerability has been resolved: ip: Fix a data-race around sysctl_ip_autobind_reuse. While reading sysctl_ip_autobind_reuse, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
Modified: 2025-10-01
CVE-2022-49601
In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Fix a data-race around sysctl_tcp_fwmark_accept. While reading sysctl_tcp_fwmark_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/13207f9485b5de68decf296ceb0046f5eabb2485
- https://git.kernel.org/stable/c/1a0008f9df59451d0a17806c1ee1a19857032fa8
- https://git.kernel.org/stable/c/45fc82706a97242539d6b841ddd7a077ec20757b
- https://git.kernel.org/stable/c/526d8cf8824f613c72dba2155542295e70135f62
- https://git.kernel.org/stable/c/a7386602a2fe2f6192477e8ede291a815da09d81
- https://git.kernel.org/stable/c/abf70de2ec026ae8d7da4e79bec61888a880e00b
- https://git.kernel.org/stable/c/bf3134feffe61b7a0e21f60a04743f8da0958b53
- https://git.kernel.org/stable/c/d4f65615db7fca3df9f7e79eadf937e6ddb03c54
Modified: 2025-10-01
CVE-2022-49602
In the Linux kernel, the following vulnerability has been resolved: ip: Fix a data-race around sysctl_fwmark_reflect. While reading sysctl_fwmark_reflect, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/0ee76fe01ff3c0b4efaa500aecc90d7c8d3a8860
- https://git.kernel.org/stable/c/25a635a67c830766110410fea88ec4e6ee29684b
- https://git.kernel.org/stable/c/5e7a1be3e68deef250ad43cc91f7bb8d7d758b48
- https://git.kernel.org/stable/c/85d0b4dbd74b95cc492b1f4e34497d3f894f5d9a
- https://git.kernel.org/stable/c/9096edcf4854289f92252e086cf6e498c7f8c21d
- https://git.kernel.org/stable/c/a475ecc9ad919aa3ebdd4e4a6ee612b793bf74b3
- https://git.kernel.org/stable/c/dccf8a67f30e18980d13f07006e5a536bbd1e136
- https://git.kernel.org/stable/c/fc92e3b4bebfdd986ef1d2c5019f236837b0b982
Modified: 2025-10-01
CVE-2022-49603
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_fwd_update_priority. While reading sysctl_ip_fwd_update_priority, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49604
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_fwd_use_pmtu. While reading sysctl_ip_fwd_use_pmtu, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/60c158dc7b1f0558f6cadd5b50d0386da0000d50
- https://git.kernel.org/stable/c/7828309df0f89419a9349761a37c7d1b0da45697
- https://git.kernel.org/stable/c/93fbc06da1d819f3981a7bd7928c3641ea67b364
- https://git.kernel.org/stable/c/b96ed5ccb09ae71103023ed13acefb194f609794
- https://git.kernel.org/stable/c/e364b5f6ffbfc457a997ad09a7baa16c19581edc
- https://git.kernel.org/stable/c/eb15262128b793e4b1d1c4514d3e6d19c3959764
Modified: 2025-10-23
CVE-2022-49605
In the Linux kernel, the following vulnerability has been resolved: igc: Reinstate IGC_REMOVED logic and implement it properly The initially merged version of the igc driver code (via commit 146740f9abc4, "igc: Add support for PF") contained the following IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors: u32 igc_rd32(struct igc_hw *hw, u32 reg) { u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr); u32 value = 0; if (IGC_REMOVED(hw_addr)) return ~value; value = readl(&hw_addr[reg]); /* reads should not return all F's */ if (!(~value) && (!reg || !(~readl(hw_addr)))) hw->hw_addr = NULL; return value; } And: #define wr32(reg, val) \ do { \ u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \ if (!IGC_REMOVED(hw_addr)) \ writel((val), &hw_addr[(reg)]); \ } while (0) E.g. igb has similar checks in its MMIO accessors, and has a similar macro E1000_REMOVED, which is implemented as follows: #define E1000_REMOVED(h) unlikely(!(h)) These checks serve to detect and take note of an 0xffffffff MMIO read return from the device, which can be caused by a PCIe link flap or some other kind of PCI bus error, and to avoid performing MMIO reads and writes from that point onwards. However, the IGC_REMOVED macro was not originally implemented: #ifndef IGC_REMOVED #define IGC_REMOVED(a) (0) #endif /* IGC_REMOVED */ This led to the IGC_REMOVED logic to be removed entirely in a subsequent commit (commit 3c215fb18e70, "igc: remove IGC_REMOVED function"), with the rationale that such checks matter only for virtualization and that igc does not support virtualization -- but a PCIe device can become detached even without virtualization being in use, and without proper checks, a PCIe bus error affecting an igc adapter will lead to various NULL pointer dereferences, as the first access after the error will set hw->hw_addr to NULL, and subsequent accesses will blindly dereference this now-NULL pointer. This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), and implements IGC_REMOVED the way it is done for igb, by checking for the unlikely() case of hw_addr being NULL. This change prevents the oopses seen when a PCIe link flap occurs on an igc adapter.
- https://git.kernel.org/stable/c/16cb6717f4f42487ef10583eb8bc98e7d1e33d65
- https://git.kernel.org/stable/c/70965b6e5c03aa70cc754af1226b9f9cde0c4bf3
- https://git.kernel.org/stable/c/77836dbe35382aaf8108489060c5c89530c77494
- https://git.kernel.org/stable/c/7c1ddcee5311f3315096217881d2dbe47cc683f9
- https://git.kernel.org/stable/c/e75b73081f1ec169518773626c2ff3950476660b
Modified: 2025-10-23
CVE-2022-49606
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix sleep from invalid context BUG Taking the qos_mutex to process RoCEv2 QP's on netdev events causes a kernel splat. Fix this by removing the handling for RoCEv2 in irdma_cm_teardown_connections that uses the mutex. This handling is only needed for iWARP to avoid having connections established while the link is down or having connections remain functional after the IP address is removed. BUG: sleeping function called from invalid context at kernel/locking/mutex. Call Trace: kernel: dump_stack+0x66/0x90 kernel: ___might_sleep.cold.92+0x8d/0x9a kernel: mutex_lock+0x1c/0x40 kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma] kernel: ? check_preempt_curr+0x7a/0x90 kernel: ? select_idle_sibling+0x22/0x3c0 kernel: ? select_task_rq_fair+0x94c/0xc90 kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma] kernel: ? __wake_up_common+0x7a/0x190 kernel: irdma_if_notify+0x3cc/0x450 [irdma] kernel: ? sched_clock_cpu+0xc/0xb0 kernel: irdma_inet6addr_event+0xc6/0x150 [irdma]
Modified: 2025-10-01
CVE-2022-49607
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix data race between perf_event_set_output() and perf_mmap_close() Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list) After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } } The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. As such there is no serialization to avoid this race. Change perf_event_set_output() to take both e1->mmap_mutex and e2->mmap_mutex to alleviate that problem. Additionally, have the loop in perf_mmap() detach the rb directly, this avoids having to wait for the concurrent perf_mmap_close() to get around to doing it to make progress.
- https://git.kernel.org/stable/c/17f5417194136517ee9bbd6511249e5310e5617c
- https://git.kernel.org/stable/c/3bbd868099287ff9027db59029b502fcfa2202a0
- https://git.kernel.org/stable/c/43128b3eee337824158f34da6648163d2f2fb937
- https://git.kernel.org/stable/c/68e3c69803dada336893640110cb87221bb01dcf
- https://git.kernel.org/stable/c/98c3c8fd0d4c560e0f8335b79c407bbf7fc9462c
- https://git.kernel.org/stable/c/a9391ff7a7c5f113d6f2bf6621d49110950de49c
- https://git.kernel.org/stable/c/da3c256e2d0ebc87c7db0c605c9692b6f1722074
- https://git.kernel.org/stable/c/f836f9ac95df15f1e0af4beb0ec20021e8c91998
Modified: 2025-10-01
CVE-2022-49608
In the Linux kernel, the following vulnerability has been resolved: pinctrl: ralink: Check for null return of devm_kcalloc Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.".
- https://git.kernel.org/stable/c/13596e6c9e541e90e5fc2c52b23f08b951370da9
- https://git.kernel.org/stable/c/44016a85419ca0d4f1e4d0127b330f8e4e2a57d0
- https://git.kernel.org/stable/c/5595d30c4dc27d939635c3188c68203b6ece1711
- https://git.kernel.org/stable/c/5694b162f275fb9a9f89422701b2b963be11e496
- https://git.kernel.org/stable/c/6194c021496addc11763d1ffa89ce5751889fe3c
- https://git.kernel.org/stable/c/c3b821e8e406d5650e587b7ac624ac24e9b780a8
Modified: 2025-10-01
CVE-2022-49609
In the Linux kernel, the following vulnerability has been resolved: power/reset: arm-versatile: Fix refcount leak in versatile_reboot_probe 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/493ceca3271316e74639c89ff8ac35883de64256
- https://git.kernel.org/stable/c/49fa778ee044b00471dd9ccae5f6a121fffea1ac
- https://git.kernel.org/stable/c/6689754b121bd487f99680280102b3a5cd7374af
- https://git.kernel.org/stable/c/71ab83ac65e2d671552374123bf920c1d698335a
- https://git.kernel.org/stable/c/78bdf732cf5d74d1c6ecda06830a91f80a4aef6f
- https://git.kernel.org/stable/c/80192eff64eee9b3bc0594a47381937b94b9d65a
- https://git.kernel.org/stable/c/a9ed3ad3a8d1dfbc829d86edb3236873a315db11
- https://git.kernel.org/stable/c/b4d224eec96a18fa8959512cd9e5b6a50bd16a41
Modified: 2025-10-23
CVE-2022-49610
In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Prevent RSB underflow before vmenter On VMX, there are some balanced returns between the time the guest's SPEC_CTRL value is written, and the vmenter. Balanced returns (matched by a preceding call) are usually ok, but it's at least theoretically possible an NMI with a deep call stack could empty the RSB before one of the returns. For maximum paranoia, don't allow *any* returns (balanced or otherwise) between the SPEC_CTRL write and the vmenter. [ bp: Fix 32-bit build. ]
Modified: 2025-10-23
CVE-2022-49611
In the Linux kernel, the following vulnerability has been resolved: x86/speculation: Fill RSB on vmexit for IBRS Prevent RSB underflow/poisoning attacks with RSB. While at it, add a bunch of comments to attempt to document the current state of tribal knowledge about RSB attacks and what exactly is being mitigated.
- https://git.kernel.org/stable/c/17a9fc4a7b91f8599223631bb6ae6416bc0de1c0
- https://git.kernel.org/stable/c/3d323b99ff5c8c57005184056d65f6af5b0479d8
- https://git.kernel.org/stable/c/4d7f72b6e1bc630bec7e4cd51814bc2b092bf153
- https://git.kernel.org/stable/c/8c38306e2e9257af4af2819aa287a4711ff36329
- https://git.kernel.org/stable/c/8d5cff499a6d740c91ff37963907e0e983c37f0f
- https://git.kernel.org/stable/c/9756bba28470722dacb79ffce554336dd1f6a6cd
- https://git.kernel.org/stable/c/f744b88dfc201bf8092833ec70b23c720188b527
Modified: 2025-10-23
CVE-2022-49612
In the Linux kernel, the following vulnerability has been resolved: power: supply: core: Fix boundary conditions in interpolation The functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple handle boundary conditions incorrectly. The change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283 ("power: supply: core: Use library interpolation"). There are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap have the wrong order compared to temp2resist. As a consequence, ocv2cap sets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read. Second, the logic of temp2resist is also not correct. Consider the case table[] = {{20, 100}, {10, 80}, {0, 60}}. For temp=5, we expect a resistance of 70% by interpolation. However, temp2resist sets high=low=2 and returns 60.
Modified: 2025-10-23
CVE-2022-49613
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix PM usage_count for console handover When console is enabled, univ8250_console_setup() calls serial8250_console_setup() before .dev is set to uart_port. Therefore, it will not call pm_runtime_get_sync(). Later, when the actual driver is going to take over univ8250_console_exit() is called. As .dev is already set, serial8250_console_exit() makes pm_runtime_put_sync() call with usage count being zero triggering PM usage count warning (extra debug for univ8250_console_setup(), univ8250_console_exit(), and serial8250_register_ports()): [ 0.068987] univ8250_console_setup ttyS0 nodev [ 0.499670] printk: console [ttyS0] enabled [ 0.717955] printk: console [ttyS0] printing thread started [ 1.960163] serial8250_register_ports assigned dev for ttyS0 [ 1.976830] printk: console [ttyS0] disabled [ 1.976888] printk: console [ttyS0] printing thread stopped [ 1.977073] univ8250_console_exit ttyS0 usage:0 [ 1.977075] serial8250 serial8250: Runtime PM usage count underflow! [ 1.977429] dw-apb-uart.6: ttyS0 at MMIO 0x4010006000 (irq = 33, base_baud = 115200) is a 16550A [ 1.977812] univ8250_console_setup ttyS0 usage:2 [ 1.978167] printk: console [ttyS0] printing thread started [ 1.978203] printk: console [ttyS0] enabled To fix the issue, call pm_runtime_get_sync() in serial8250_register_ports() as soon as .dev is set for an uart_port if it has console enabled. This problem became apparent only recently because 82586a721595 ("PM: runtime: Avoid device usage count underflows") added the warning printout. I confirmed this problem also occurs with v5.18 (w/o the warning printout, obviously).
Modified: 2025-10-01
CVE-2022-49615
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error The initial settings will be written before the codec probe function. But, the rt711->component doesn't be assigned yet. If IO error happened during initial settings operations, it will cause the kernel panic. This patch changed component->dev to slave->dev to fix this issue.
Modified: 2025-10-23
CVE-2022-49616
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt7*-sdw: harden jack_detect_handler Realtek headset codec drivers typically check if the card is instantiated before proceeding with the jack detection. The rt700, rt711 and rt711-sdca are however missing a check on the card pointer, which can lead to NULL dereferences encountered in driver bind/unbind tests.
Modified: 2025-10-23
CVE-2022-49617
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: sof_sdw: handle errors on card registration If the card registration fails, typically because of deferred probes, the device properties added for headset codecs are not removed, which leads to kernel oopses in driver bind/unbind tests. We already clean-up the device properties when the card is removed, this code can be moved as a helper and called upon card registration errors.
Modified: 2025-10-01
CVE-2022-49618
In the Linux kernel, the following vulnerability has been resolved: pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux() pdesc could be null but still dereference pdesc->name and it will lead to a null pointer access. So we move a null check before dereference.
Modified: 2025-10-01
CVE-2022-49619
In the Linux kernel, the following vulnerability has been resolved: net: sfp: fix memory leak in sfp_probe() sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When devm_add_action() fails, sfp is not freed, which leads to a memory leak. We should use devm_add_action_or_reset() instead of devm_add_action().
- https://git.kernel.org/stable/c/0a18d802d65cf662644fd1d369c86d84a5630652
- https://git.kernel.org/stable/c/1545bc727625ea6e8decd717e5d1e8cc704ccf8f
- https://git.kernel.org/stable/c/204543581a2f26bb3b997a304c0bd06926ba7f15
- https://git.kernel.org/stable/c/67dc32542a1fb7790d0853cf4a5cf859ac6a2002
- https://git.kernel.org/stable/c/9ec5a97f327a89031fce6cfc3e95543c53936638
- https://git.kernel.org/stable/c/ede990cfc42775bd0141e21f37ee365dcaeeb50f
- https://git.kernel.org/stable/c/f22ddc8a5278d7fb6369a0aeb0d8775a0aefaaee
Modified: 2025-10-01
CVE-2022-49620
In the Linux kernel, the following vulnerability has been resolved: net: tipc: fix possible refcount leak in tipc_sk_create() Free sk in case tipc_sk_insert() fails.
- https://git.kernel.org/stable/c/00aff3590fc0a73bddd3b743863c14e76fd35c0c
- https://git.kernel.org/stable/c/3b2957fc09fe1ac7f07f40dd50dd5f93e3f3a7a2
- https://git.kernel.org/stable/c/4919d82f7041157a421ca9bf39a78551d5ad8a1b
- https://git.kernel.org/stable/c/638fa20b618b2bbcf86da71231624cc82121a036
- https://git.kernel.org/stable/c/7bc9e7f70bc57d8f02ffea2a42094281effb15ef
- https://git.kernel.org/stable/c/833ecd0eae76eadf81d6d747bb5bc992d1151867
- https://git.kernel.org/stable/c/ef488669b2652bde5b6ee5a409a5b048a2a50db4
- https://git.kernel.org/stable/c/efa78f2ae363428525fb4981bb63c555ee79f3c7
Modified: 2025-10-01
CVE-2022-49621
In the Linux kernel, the following vulnerability has been resolved: cpufreq: pmac32-cpufreq: Fix refcount leak bug In pmac_cpufreq_init_MacRISC3(), we need to add corresponding of_node_put() for the three node pointers whose refcount have been incremented by of_find_node_by_name().
- https://git.kernel.org/stable/c/37c16fc2cb13a13f3c0193bfc6f2edef7d7df7d7
- https://git.kernel.org/stable/c/3ea9dbf7c2f436952bca331c6f5d72f75aca224e
- https://git.kernel.org/stable/c/4513018d0bd739097570d26a7760551cba3deb56
- https://git.kernel.org/stable/c/4585890ab2dbf455d80e254d3d859d4c1e357920
- https://git.kernel.org/stable/c/4f242486bf46d314b2e3838cc64b56f008a3c4d7
- https://git.kernel.org/stable/c/57289b6601fe78c09921599b042a0b430fb420ec
- https://git.kernel.org/stable/c/8dda30f81c751b01cd71f2cfaeef26ad4393b1d1
- https://git.kernel.org/stable/c/ccd7567d4b6cf187fdfa55f003a9e461ee629e36
Modified: 2025-03-24
CVE-2022-49622
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid skb access on nf_stolen When verdict is NF_STOLEN, the skb might have been freed. When tracing is enabled, this can result in a use-after-free: 1. access to skb->nf_trace 2. access to skb->mark 3. computation of trace id 4. dump of packet payload To avoid 1, keep a cached copy of skb->nf_trace in the trace state struct. Refresh this copy whenever verdict is != STOLEN. Avoid 2 by skipping skb->mark access if verdict is STOLEN. 3 is avoided by precomputing the trace id. Only dump the packet when verdict is not "STOLEN".
Modified: 2025-10-01
CVE-2022-49623
In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency.
Modified: 2025-10-23
CVE-2022-49624
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: remove aq_nic_deinit() when resume
aq_nic_deinit() has been called while suspending, so we don't have to call
it again on resume.
Actually, call it again leads to another hang issue when resuming from
S3.
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992345] Call Trace:
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992346]
Modified: 2025-10-23
CVE-2022-49625
In the Linux kernel, the following vulnerability has been resolved: sfc: fix kernel panic when creating VF When creating VFs a kernel panic can happen when calling to efx_ef10_try_update_nic_stats_vf. When releasing a DMA coherent buffer, sometimes, I don't know in what specific circumstances, it has to unmap memory with vunmap. It is disallowed to do that in IRQ context or with BH disabled. Otherwise, we hit this line in vunmap, causing the crash: BUG_ON(in_interrupt()); This patch reenables BH to release the buffer. Log messages when the bug is hit: kernel BUG at mm/vmalloc.c:2727! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:vunmap+0x2e/0x30 ...skip... Call Trace: __iommu_dma_free+0x96/0x100 efx_nic_free_buffer+0x2b/0x40 [sfc] efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc] efx_ef10_update_stats_vf+0x18/0x40 [sfc] efx_start_all+0x15e/0x1d0 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xe7/0x1a0 __dev_change_flags+0x1d7/0x240 dev_change_flags+0x21/0x60 ...skip...
- https://git.kernel.org/stable/c/16662524ec5da801fb78a1afcaf6e782f1cf103a
- https://git.kernel.org/stable/c/68e5f32f0de9594629ff9e599294d9801c6187de
- https://git.kernel.org/stable/c/82bcb730f856086f033e6c04082eb4503d4c2fa4
- https://git.kernel.org/stable/c/ada74c5539eba06cf8b47d068f92e0b3963a9a6e
- https://git.kernel.org/stable/c/b82e4ad58a7fb72456503958a93060f87896e629
- https://git.kernel.org/stable/c/b9072305270579a9d6afc9b926166231e5b1a7c8
- https://git.kernel.org/stable/c/d9840212a9c00507347c703f4fdeda16400407e0
- https://git.kernel.org/stable/c/da346adcf5573fd8663cabfdfe8371009629a906
Modified: 2025-03-24
CVE-2022-49626
In the Linux kernel, the following vulnerability has been resolved: sfc: fix use after free when disabling sriov Use after free is detected by kfence when disabling sriov. What was read after being freed was vf->pci_dev: it was freed from pci_disable_sriov and later read in efx_ef10_sriov_free_vf_vports, called from efx_ef10_sriov_free_vf_vswitching. Set the pointer to NULL at release time to not trying to read it later. Reproducer and dmesg log (note that kfence doesn't detect it every time): $ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs $ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
- https://git.kernel.org/stable/c/3199e34912d84cdfb8a93a984c5ae5c73fb13e84
- https://git.kernel.org/stable/c/58d93e9d160c0de6d867c7eb4c2206671a351eb1
- https://git.kernel.org/stable/c/9c854ae512b89229aeee93849e9bd4c115b37909
- https://git.kernel.org/stable/c/bcad880865bfb421885364b1f0c7351280fe2b97
- https://git.kernel.org/stable/c/c2240500817b3b4b996cdf2a461a3a5679f49b94
- https://git.kernel.org/stable/c/c9e75bb22a26e391f189f5a5133dd63dcb57fdaa
- https://git.kernel.org/stable/c/e435c4aeeaa073091f7f3b7735af2ef5c97d63f2
- https://git.kernel.org/stable/c/ebe41da5d47ac0fff877e57bd14c54dccf168827
Modified: 2025-10-01
CVE-2022-49627
In the Linux kernel, the following vulnerability has been resolved: ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
Modified: 2025-10-23
CVE-2022-49628
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix leaks in probe These two error paths should clean up before returning.
Modified: 2025-10-01
CVE-2022-49629
In the Linux kernel, the following vulnerability has been resolved: nexthop: Fix data-races around nexthop_compat_mode. While reading nexthop_compat_mode, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49630
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_ecn_fallback. While reading sysctl_tcp_ecn_fallback, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
Modified: 2025-10-01
CVE-2022-49631
In the Linux kernel, the following vulnerability has been resolved: raw: Fix a data-race around sysctl_raw_l3mdev_accept. While reading sysctl_raw_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/038a87b3e460d2ee579c8b1bd3890d816d6687b1
- https://git.kernel.org/stable/c/1dace014928e6e385363032d359a04dee9158af0
- https://git.kernel.org/stable/c/46e9c46203fd4676720ddca0fef7eff26826648e
- https://git.kernel.org/stable/c/ab5adca2e17d6595f3fc0e25ccb6bcbe2e01ca4f
- https://git.kernel.org/stable/c/cc9540ba5b3652c473af7e54892a48cdced87983
Modified: 2025-10-01
CVE-2022-49632
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix a data-race around sysctl_icmp_errors_use_inbound_ifaddr. While reading sysctl_icmp_errors_use_inbound_ifaddr, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
Modified: 2025-10-01
CVE-2022-49633
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix data-races around sysctl_icmp_echo_enable_probe. While reading sysctl_icmp_echo_enable_probe, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49634
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data-races in proc_dou8vec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_dou8vec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_dou8vec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.
Modified: 2025-10-23
CVE-2022-49635
In the Linux kernel, the following vulnerability has been resolved: drm/i915/selftests: fix subtraction overflow bug On some machines hole_end can be small enough to cause subtraction overflow. On the other side (addr + 2 * min_alignment) can overflow in case of mock tests. This patch should handle both cases. (cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)
Modified: 2025-04-10
CVE-2022-49636
In the Linux kernel, the following vulnerability has been resolved:
vlan: fix memory leak in vlan_newlink()
Blamed commit added back a bug I fixed in commit 9bbd917e0bec
("vlan: fix memory leak in vlan_dev_set_egress_priority")
If a memory allocation fails in vlan_changelink() after other allocations
succeeded, we need to call vlan_dev_free_egress_priority()
to free all allocated memory because after a failed ->newlink()
we do not call any methods like ndo_uninit() or dev->priv_destructor().
In following example, if the allocation for last element 2000:2001 fails,
we need to free eight prior allocations:
ip link add link dummy0 dummy0.100 type vlan id 100 \
egress-qos-map 1:2 2:3 3:4 4:5 5:6 6:7 7:8 8:9 2000:2001
syzbot report was:
BUG: memory leak
unreferenced object 0xffff888117bd1060 (size 32):
comm "syz-executor408", pid 3759, jiffies 4294956555 (age 34.090s)
hex dump (first 32 bytes):
09 00 00 00 00 a0 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/4c43069bb1097dd6cc1cf0f7c43a36d1f7b3910b
- https://git.kernel.org/stable/c/549de58dba4bf1b2adc72e9948b9c76fa88be9d2
- https://git.kernel.org/stable/c/72a0b329114b1caa8e69dfa7cdad1dd3c69b8602
- https://git.kernel.org/stable/c/df27729a4fe0002dfd80c96fe1c142829c672728
- https://git.kernel.org/stable/c/f5dc10b910bdac523e5947336445a77066c51bf9
Modified: 2025-10-01
CVE-2022-49637
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix a data-race around sysctl_fib_sync_mem. While reading sysctl_fib_sync_mem, it can be changed concurrently. So, we need to add READ_ONCE() to avoid a data-race.
- https://git.kernel.org/stable/c/190cd4ff128373271e065afb20f1d2247b3f10c3
- https://git.kernel.org/stable/c/418b191d5f223a8cb6cab09eae1f72c04ba6adf2
- https://git.kernel.org/stable/c/73318c4b7dbd0e781aaababff17376b2894745c0
- https://git.kernel.org/stable/c/7c1acd98fb221dc0d847451b9ab86319f8b9916c
- https://git.kernel.org/stable/c/9be8aac91960ea32fd0e874758c9afee665c57d2
Modified: 2025-10-01
CVE-2022-49638
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix data-races around sysctl. While reading icmp sysctl variables, they can be changed concurrently. So, we need to add READ_ONCE() to avoid data-races.
- https://git.kernel.org/stable/c/0cba7ca667ceb06934746ddd9833a25847bde81d
- https://git.kernel.org/stable/c/1740e5922fbb705637ae9fa5203db132fc45f9f6
- https://git.kernel.org/stable/c/48d7ee321ea5182c6a70782aa186422a70e67e22
- https://git.kernel.org/stable/c/53ecd09ef2fb35fa69667ae8e414ef6b00fd3bf6
- https://git.kernel.org/stable/c/798c2cf57c63ab39c8aac24d6a3d50f4fa5eeb06
- https://git.kernel.org/stable/c/e088ceb73c24ab4774da391d54a6426f4bfaefce
- https://git.kernel.org/stable/c/e2828e8c605853f71267825c9415437c0a93e4f2
- https://git.kernel.org/stable/c/edeec63b13c252193d626c2a48d7a2f0e7016dc2
Modified: 2025-10-01
CVE-2022-49639
In the Linux kernel, the following vulnerability has been resolved: cipso: Fix data-races around sysctl. While reading cipso sysctl variables, they can be changed concurrently. So, we need to add READ_ONCE() to avoid data-races.
- https://git.kernel.org/stable/c/07b0caf8aeb9b82e6ecc6c292a3e47c7fcdb1148
- https://git.kernel.org/stable/c/0e41a0f73ccb9be112a80bde3804a771633caaef
- https://git.kernel.org/stable/c/2764f82bbc158d106693ae3ced3675cf4b963b35
- https://git.kernel.org/stable/c/59e26906b89cc35bb54476498772b45cbc32323f
- https://git.kernel.org/stable/c/c321e99d2725d11f7e6a4ebd9ce752259f0bae81
- https://git.kernel.org/stable/c/ca26ca5e2f3eeb3e6fe699cd6effa3b4b2aa8698
- https://git.kernel.org/stable/c/dd44f04b9214adb68ef5684ae87a81ba03632250
- https://git.kernel.org/stable/c/fe2a35fa2c4f9c8ce5ef970eb927031387f9446a
Modified: 2025-10-01
CVE-2022-49640
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.
Modified: 2025-10-01
CVE-2022-49641
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.
Modified: 2025-10-23
CVE-2022-49642
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: dwc-qos: Disable split header for Tegra194 There is a long-standing issue with the Synopsys DWC Ethernet driver for Tegra194 where random system crashes have been observed [0]. The problem occurs when the split header feature is enabled in the stmmac driver. In the bad case, a larger than expected buffer length is received and causes the calculation of the total buffer length to overflow. This results in a very large buffer length that causes the kernel to crash. Why this larger buffer length is received is not clear, however, the feedback from the NVIDIA design team is that the split header feature is not supported for Tegra194. Therefore, disable split header support for Tegra194 to prevent these random crashes from occurring. [0] https://lore.kernel.org/linux-tegra/b0b17697-f23e-8fa5-3757-604a86f3a095@nvidia.com/
- https://git.kernel.org/stable/c/029c1c2059e9c4b38f97a06204cdecd10cfbeb8a
- https://git.kernel.org/stable/c/2968830c9b47ce093237483c6207c61065712386
- https://git.kernel.org/stable/c/9cc8edc571b871d974b3289868553f9ce544aba6
- https://git.kernel.org/stable/c/cfa4caf3e881ad6dd366c903c34f1c7f21b857ab
- https://git.kernel.org/stable/c/d5c315a787652c35045044877a249f7d5c8a4104
Modified: 2025-10-01
CVE-2022-49643
In the Linux kernel, the following vulnerability has been resolved: ima: Fix a potential integer overflow in ima_appraise_measurement When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be negative, which may cause the integer overflow problem.
- https://git.kernel.org/stable/c/388f3df7c3c8b7f2a32b9ae0a9b2f9f6ad3b1b77
- https://git.kernel.org/stable/c/640cea4c2839a821adfbb703b590a5928abe9286
- https://git.kernel.org/stable/c/831e190175f10652be93b08436cc7bf2e62e4bb6
- https://git.kernel.org/stable/c/c8d5d81940938b5f6c0f495ca9538e7740416f30
- https://git.kernel.org/stable/c/d2ee2cfc4aa85ff6a2a3b198a3a524ec54e3d999
Modified: 2025-10-01
CVE-2022-49644
In the Linux kernel, the following vulnerability has been resolved: drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector() If drm_connector_init fails, intel_connector_free will be called to take care of proper free. So it is necessary to drop the refcount of port before intel_connector_free. (cherry picked from commit cea9ed611e85d36a05db52b6457bf584b7d969e2)
- https://git.kernel.org/stable/c/505114dda5bbfd07f4ce9a2df5b7d8ef5f2a1218
- https://git.kernel.org/stable/c/592f3bad00b7e2a95a6fb7a4f9e742c061c9c3c1
- https://git.kernel.org/stable/c/72f231b9a88abcfac9f5ddaa1a0aacb3f9f87ba5
- https://git.kernel.org/stable/c/85144df9ff4652816448369de76897c57cbb1b93
- https://git.kernel.org/stable/c/a91522b4279bebb098106a19b91f82b9c3213be9
Modified: 2025-10-23
CVE-2022-49645
In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix shrinker list corruption by madvise IOCTL Calling madvise IOCTL twice on BO causes memory shrinker list corruption and crashes kernel because BO is already on the list and it's added to the list again, while BO should be removed from the list before it's re-added. Fix it.
- https://git.kernel.org/stable/c/0581613df7f9a4c5fac096ce1d5fb15b7b994240
- https://git.kernel.org/stable/c/1807d8867402a58b831a7fc16832747ff559a0d1
- https://git.kernel.org/stable/c/393594aad55179eb761af41533d8d1d6eb4543b0
- https://git.kernel.org/stable/c/9fc33eaaa979d112d10fea729edcd2a2e21aa912
- https://git.kernel.org/stable/c/f036392edd9c49090781d8cca26ad6557a63bae4
Modified: 2025-10-23
CVE-2022-49646
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix queue selection for mesh/OCB interfaces When using iTXQ, the code assumes that there is only one vif queue for broadcast packets, using the BE queue. Allowing non-BE queue marking violates that assumption and txq->ac == skb_queue_mapping is no longer guaranteed. This can cause issues with queue handling in the driver and also causes issues with the recent ATF change, resulting in an AQL underflow warning.
- https://git.kernel.org/stable/c/41ecab279a70dced9005f4d55fa0fcde8938603f
- https://git.kernel.org/stable/c/444be5a02b77f3b7a8ac9c1a0b074fbb3bd89cd0
- https://git.kernel.org/stable/c/50e2ab39291947b6c6c7025cf01707c270fcde59
- https://git.kernel.org/stable/c/5a9df31017999197b6e60535940f2f2fe1bd3b0d
- https://git.kernel.org/stable/c/e013ea2a51a94b903b396a8dff531a07d470335d
Modified: 2025-03-24
CVE-2022-49647
In the Linux kernel, the following vulnerability has been resolved: cgroup: Use separate src/dst nodes when preloading css_sets for migration Each cset (css_set) is pinned by its tasks. When we're moving tasks around across csets for a migration, we need to hold the source and destination csets to ensure that they don't go away while we're moving tasks about. This is done by linking cset->mg_preload_node on either the mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the same cset->mg_preload_node for both the src and dst lists was deemed okay as a cset can't be both the source and destination at the same time. Unfortunately, this overloading becomes problematic when multiple tasks are involved in a migration and some of them are identity noop migrations while others are actually moving across cgroups. For example, this can happen with the following sequence on cgroup1: #1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs the process including the group leader back into a. In this final migration, non-leader threads would be doing identity migration while the group leader is doing an actual one. After #3, let's say the whole process was in cset A, and that after #4, the leader moves to cset B. Then, during #6, the following happens: 1. cgroup_migrate_add_src() is called on B for the leader. 2. cgroup_migrate_add_src() is called on A for the other threads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mg_preload_node is already busy. 5. and then it notices A wants to migrate to A as it's an identity migration, it culls it by list_del_init()'ing its ->mg_preload_node and putting references accordingly. 6. The rest of migration takes place with B on the src list but nothing on the dst list. This means that A isn't held while migration is in progress. If all tasks leave A before the migration finishes and the incoming task pins it, the cset will be destroyed leading to use-after-free. This is caused by overloading cset->mg_preload_node for both src and dst preload lists. We wanted to exclude the cset from the src list but ended up inadvertently excluding it from the dst list too. This patch fixes the issue by separating out cset->mg_preload_node into ->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst preloadings don't interfere with each other.
- https://git.kernel.org/stable/c/05f7658210d1d331e8dd4cb6e7bbbe3df5f5ac27
- https://git.kernel.org/stable/c/07fd5b6cdf3cc30bfde8fe0f644771688be04447
- https://git.kernel.org/stable/c/0e41774b564befa6d271e8d5086bf870d617a4e6
- https://git.kernel.org/stable/c/54aee4e5ce8c21555286a6333e46c1713880cf93
- https://git.kernel.org/stable/c/7657e3958535d101a24ab4400f9b8062b9107cc4
- https://git.kernel.org/stable/c/ad44e05f3e016bdcb1ad25af35ade5b5f41ccd68
- https://git.kernel.org/stable/c/cec2bbdcc14fbaa6b95ee15a7c423b05d97038be
Modified: 2025-10-01
CVE-2022-49648
In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th var_defs.name" is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/22eeff55679d9e7c0f768c79bfbd83e2f8142d89
- https://git.kernel.org/stable/c/4d453eb5e1eec89971aa5b3262857ee26cfdffd3
- https://git.kernel.org/stable/c/78a1400c42ee11197eb1f0f85ba51df9a4fdfff0
- https://git.kernel.org/stable/c/7edc3945bdce9c39198a10d6129377a5c53559c2
- https://git.kernel.org/stable/c/eb622d5580b9e2ff694f62da6410618bd73853cb
- https://git.kernel.org/stable/c/ecc6dec12c33aa92c086cd702af9f544ddaf3c75
Modified: 2025-10-01
CVE-2022-49649
In the Linux kernel, the following vulnerability has been resolved: xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue xenvif_rx_next_skb() is expecting the rx queue not being empty, but in case the loop in xenvif_rx_action() is doing multiple iterations, the availability of another skb in the rx queue is not being checked. This can lead to crashes: [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.537534] PGD 0 P4D 0 [40072.537644] Oops: 0000 [#1] SMP NOPTI [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5 [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021 [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000 [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246 [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7 [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8 [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008 [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708 [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0 [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000 [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660 [40072.539211] Call Trace: [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback] [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback] Fix that by stopping the loop in case the rx queue becomes empty.
- https://git.kernel.org/stable/c/5a071aefd6414af5a20321ab58a0557b81993687
- https://git.kernel.org/stable/c/7425479d20f9e96f7c3ec8e8a93fe0d7478724cb
- https://git.kernel.org/stable/c/94e8100678889ab428e68acadf042de723f094b9
- https://git.kernel.org/stable/c/b99174ac57fe5d8867448c03b23828e63f24cb1c
- https://git.kernel.org/stable/c/b9c32a6886af79d6e0ad87a7b01800ed079cdd02
- https://git.kernel.org/stable/c/c0fcceb5f3f1ec197c014fe218c2f28108cacd27
- https://git.kernel.org/stable/c/d5320c6a27aa975aff740f9cb481dcbde48f4348
- https://git.kernel.org/stable/c/f0b5c819b062df8bf5f2acf4697e3871cb3722da
Modified: 2025-10-23
CVE-2022-49650
In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: fix runtime PM underflow Commit dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") caused unbalanced pm_runtime_get/put() calls when the bam is controlled remotely. This commit reverts it and just enables pm_runtime in all cases, the clk_* functions already just nop when the clock is NULL. Also clean up a bit by removing unnecessary bamclk null checks.
Modified: 2025-03-24
CVE-2022-49651
In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct().
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-49653
In the Linux kernel, the following vulnerability has been resolved: i2c: piix4: Fix a memory leak in the EFCH MMIO support The recently added support for EFCH MMIO regions introduced a memory leak in that code path. The leak is caused by the fact that release_resource() merely removes the resource from the tree but does not free its memory. We need to call release_mem_region() instead, which does free the memory. As a nice side effect, this brings back some symmetry between the legacy and MMIO paths.
Modified: 2025-10-23
CVE-2022-49654
In the Linux kernel, the following vulnerability has been resolved: net: dsa: qca8k: reset cpu port on MTU change It was discovered that the Documentation lacks of a fundamental detail on how to correctly change the MAX_FRAME_SIZE of the switch. In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, the switch panics and cease to send any packet. This cause the mgmt ethernet system to not receive any packet (the slow fallback still works) and makes the device not reachable. To recover from this a switch reset is required. To correctly handle this, turn off the cpu ports before changing the MAX_FRAME_SIZE and turn on again after the value is applied.
Modified: 2025-10-23
CVE-2022-49655
In the Linux kernel, the following vulnerability has been resolved: fscache: Fix invalidation/lookup race If an NFS file is opened for writing and closed, fscache_invalidate() will be asked to invalidate the file - however, if the cookie is in the LOOKING_UP state (or the CREATING state), then request to invalidate doesn't get recorded for fscache_cookie_state_machine() to do something with. Fix this by making __fscache_invalidate() set a flag if it sees the cookie is in the LOOKING_UP state to indicate that we need to go to invalidation. Note that this requires a count on the n_accesses counter for the state machine, which that will release when it's done. fscache_cookie_state_machine() then shifts to the INVALIDATING state if it sees the flag. Without this, an nfs file can get corrupted if it gets modified locally and then read locally as the cache contents may not get updated.
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-49658
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals Kuee reported a corner case where the tnum becomes constant after the call to __reg_bound_offset(), but the register's bounds are not, that is, its min bounds are still not equal to the register's max bounds. This in turn allows to leak pointers through turning a pointer register as is into an unknown scalar via adjust_ptr_min_max_vals(). Before: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*] 10: (95) exit What can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, that is, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off has not been done at that point via __update_reg_bounds(), which would have improved the umax to be equal to umin. Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync() helper and use it consistently everywhere. After the fix, bounds have been corrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the register is regarded as a 'proper' constant scalar of 0. After: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0 ---truncated---
Modified: 2025-10-22
CVE-2022-49659
In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bits In commit 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") the RX path for peripheral devices was switched to RX-offload. Received CAN frames are pushed to RX-offload together with a timestamp. RX-offload is designed to handle overflows of the timestamp correctly, if 32 bit timestamps are provided. The timestamps of m_can core are only 16 bits wide. So this patch shifts them to full 32 bit before passing them to RX-offload.
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-10-23
CVE-2022-49662
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix lockdep splat in in6_dump_addrs()
As reported by syzbot, we should not use rcu_dereference()
when rcu_read_lock() is not held.
WARNING: suspicious RCU usage
5.19.0-rc2-syzkaller #0 Not tainted
net/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz-executor326/3617:
#0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223
stack backtrace:
CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
Modified: 2025-10-24
CVE-2022-49663
In the Linux kernel, the following vulnerability has been resolved:
tunnels: do not assume mac header is set in skb_tunnel_check_pmtu()
Recently added debug in commit f9aefd6b2aa3 ("net: warn if mac header
was not set") caught a bug in skb_tunnel_check_pmtu(), as shown
in this syzbot report [1].
In ndo_start_xmit() paths, there is really no need to use skb->mac_header,
because skb->data is supposed to point at it.
[1] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_mac_header_len include/linux/skbuff.h:2784 [inline]
WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413
Modules linked in:
CPU: 1 PID: 8604 Comm: syz-executor.3 Not tainted 5.19.0-rc2-syzkaller-00443-g8720bd951b8e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:skb_mac_header_len include/linux/skbuff.h:2784 [inline]
RIP: 0010:skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413
Code: 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 84 b9 fe ff ff 4c 89 ff e8 7c 0f d7 f9 e9 ac fe ff ff e8 c2 13 8a f9 <0f> 0b e9 28 fc ff ff e8 b6 13 8a f9 48 8b 54 24 70 48 b8 00 00 00
RSP: 0018:ffffc90002e4f520 EFLAGS: 00010212
RAX: 0000000000000324 RBX: ffff88804d5fd500 RCX: ffffc90005b52000
RDX: 0000000000040000 RSI: ffffffff87f05e3e RDI: 0000000000000003
RBP: ffffc90002e4f650 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: 000000000000ffff
R13: 0000000000000000 R14: 000000000000ffcd R15: 000000000000001f
FS: 00007f3babba9700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000080 CR3: 0000000075319000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-10-01
CVE-2022-49664
In the Linux kernel, the following vulnerability has been resolved:
tipc: move bc link creation back to tipc_node_create
Shuang Li reported a NULL pointer dereference crash:
[] BUG: kernel NULL pointer dereference, address: 0000000000000068
[] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
[] Call Trace:
[]
Modified: 2025-10-23
CVE-2022-49665
In the Linux kernel, the following vulnerability has been resolved: platform/x86: thinkpad_acpi: Fix a memory leak of EFCH MMIO resource Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak.
Modified: 2025-10-23
CVE-2022-49666
In the Linux kernel, the following vulnerability has been resolved: powerpc/memhotplug: Add add_pages override for PPC With commit ffa0b64e3be5 ("powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit") the kernel now validate the addr against high_memory value. This results in the below BUG_ON with dax pfns. [ 635.798741][T26531] kernel BUG at mm/page_alloc.c:5521! 1:mon> e cpu 0x1: Vector: 700 (Program Check) at [c000000007287630] pc: c00000000055ed48: free_pages.part.0+0x48/0x110 lr: c00000000053ca70: tlb_finish_mmu+0x80/0xd0 sp: c0000000072878d0 msr: 800000000282b033 current = 0xc00000000afabe00 paca = 0xc00000037ffff300 irqmask: 0x03 irq_happened: 0x05 pid = 26531, comm = 50-landscape-sy kernel BUG at :5521! Linux version 5.19.0-rc3-14659-g4ec05be7c2e1 (kvaneesh@ltc-boston8) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #625 SMP Thu Jun 23 00:35:43 CDT 2022 1:mon> t [link register ] c00000000053ca70 tlb_finish_mmu+0x80/0xd0 [c0000000072878d0] c00000000053ca54 tlb_finish_mmu+0x64/0xd0 (unreliable) [c000000007287900] c000000000539424 exit_mmap+0xe4/0x2a0 [c0000000072879e0] c00000000019fc1c mmput+0xcc/0x210 [c000000007287a20] c000000000629230 begin_new_exec+0x5e0/0xf40 [c000000007287ae0] c00000000070b3cc load_elf_binary+0x3ac/0x1e00 [c000000007287c10] c000000000627af0 bprm_execve+0x3b0/0xaf0 [c000000007287cd0] c000000000628414 do_execveat_common.isra.0+0x1e4/0x310 [c000000007287d80] c00000000062858c sys_execve+0x4c/0x60 [c000000007287db0] c00000000002c1b0 system_call_exception+0x160/0x2c0 [c000000007287e10] c00000000000c53c system_call_common+0xec/0x250 The fix is to make sure we update high_memory on memory hotplug. This is similar to what x86 does in commit 3072e413e305 ("mm/memory_hotplug: introduce add_pages")
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-01
CVE-2022-49668
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. This function only calls of_node_put() in normal path, missing it in error paths. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/01121e39ef537289926ae6f5374dce92c796d863
- https://git.kernel.org/stable/c/194781229d4cbc804b8ded13156eb8addce87d6c
- https://git.kernel.org/stable/c/bdecd912e99acfd61507f1720d3f4eed1b3418d8
- https://git.kernel.org/stable/c/e65027fdebbacd40595e96ef7b5d2418f71bddf2
- https://git.kernel.org/stable/c/f44b799603a9b5d2e375b0b2d54dd0b791eddfc2
Modified: 2025-03-24
CVE-2022-49669
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race on unaccepted mptcp sockets When the listener socket owning the relevant request is closed, it frees the unaccepted subflows and that causes later deletion of the paired MPTCP sockets. The mptcp socket's worker can run in the time interval between such delete operations. When that happens, any access to msk->first will cause an UaF access, as the subflow cleanup did not cleared such field in the mptcp socket. Address the issue explicitly traversing the listener socket accept queue at close time and performing the needed cleanup on the pending msk. Note that the locking is a bit tricky, as we need to acquire the msk socket lock, while still owning the subflow socket one.
Modified: 2025-10-01
CVE-2022-49670
In the Linux kernel, the following vulnerability has been resolved:
linux/dim: Fix divide by 0 in RDMA DIM
Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio ==
0.
CallTrace:
Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020
task: ffff880194b78000 task.stack: ffffc90006714000
RIP: 0010:backport_rdma_dim+0x10e/0x240 [mlx_compat]
RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202
RAX: 0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09
R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff880c10e80000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/0b6e0eb5c45e79e9095de2498cc0ca5ec563fc5e
- https://git.kernel.org/stable/c/0fe3dbbefb74a8575f61d7801b08dbc50523d60d
- https://git.kernel.org/stable/c/5af106f8e072aebd88b95e164a08fa320651a99a
- https://git.kernel.org/stable/c/7c1963391af51ee322378d1b2849c60e9037f069
- https://git.kernel.org/stable/c/fae2a9fb1eaf348ad8732f90d42ebbb971bd7e95
Modified: 2025-10-01
CVE-2022-49671
In the Linux kernel, the following vulnerability has been resolved: RDMA/cm: Fix memory leak in ib_cm_insert_listen cm_alloc_id_priv() allocates resource for the cm_id_priv. When cm_init_listen() fails it doesn't free it, leading to memory leak. Add the missing error unwind.
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-24
CVE-2022-49675
In the Linux kernel, the following vulnerability has been resolved: tick/nohz: unexport __init-annotated tick_nohz_full_setup() 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 had been broken for a decade. Commit 28438794aba4 ("modpost: fix section mismatch check for exported init/exit sections") fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost: vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c.
Modified: 2025-10-01
CVE-2022-49676
In the Linux kernel, the following vulnerability has been resolved: memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timings of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in some error paths. To unify the structure, Add put_node label and goto it on errors.
Modified: 2025-10-01
CVE-2022-49677
In the Linux kernel, the following vulnerability has been resolved: ARM: cns3xxx: Fix refcount leak in cns3xxx_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1ba904b6b16e08de5aed7c1349838d9cd0d178c5
- https://git.kernel.org/stable/c/45bebbc8cea7d586a6216dc62814bdb380b9b29b
- https://git.kernel.org/stable/c/68d4303bf59662b64bd555e2aa0518282d20aa4f
- https://git.kernel.org/stable/c/b8b84e01ca94e2e1f5492353e9c24dab520b2e5b
- https://git.kernel.org/stable/c/c980392af1473d6d5662f70d8089c8e6d85144a4
- https://git.kernel.org/stable/c/d1359e4129ad43e43972a28838b87291c51de23d
- https://git.kernel.org/stable/c/da3ee7cd2f15922ad88a7ca6deee2eafdc7cd214
- https://git.kernel.org/stable/c/dc5170aae24e04068fd5ea125d06c0ab51f48a27
Modified: 2025-10-01
CVE-2022-49678
In the Linux kernel, the following vulnerability has been resolved: soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. In brcmstb_init_sram, it pass dn to of_address_to_resource(), of_address_to_resource() will call of_find_device_by_node() to take reference, so we should release the reference returned by of_find_matching_node().
- https://git.kernel.org/stable/c/10ba9d499a9fd82ed40897e734ba19870a879407
- https://git.kernel.org/stable/c/30bbfeb480ae8b5ee43199d72417b232590440c2
- https://git.kernel.org/stable/c/37d838de369b07b596c19ff3662bf0293fdb09ee
- https://git.kernel.org/stable/c/4f5877bdf7b593e988f1924f4c3df6523f80b39c
- https://git.kernel.org/stable/c/734a4d15142bb4c8ecad2d8ec70d7564e78ae34d
- https://git.kernel.org/stable/c/dcafd5463d8f20c4f90ddc138a5738adb99f74c8
Modified: 2025-10-01
CVE-2022-49679
In the Linux kernel, the following vulnerability has been resolved: ARM: Fix refcount leak in axxia_boot_secondary of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/29ca9c4efacccdc15104a8d4bf10b5183fc92840
- https://git.kernel.org/stable/c/3c19fe3f04f4f4e7a2b722c2fd3c98356fc1d72b
- https://git.kernel.org/stable/c/44a5b3a073e5aaa5720929dba95b2725eb32bb65
- https://git.kernel.org/stable/c/4d9c60e868f7cf8e09956e7d5bb44d807d712699
- https://git.kernel.org/stable/c/71e12e5b02674459a24f16e965255d63b31fe049
- https://git.kernel.org/stable/c/7c7ff68daa93d8c4cdea482da4f2429c0398fcde
- https://git.kernel.org/stable/c/a9b76c232a1ce4cbf27862097f7eb634dcc779eb
- https://git.kernel.org/stable/c/b385cb59aac8d61c29bc72ebf3d19a536914af96
Modified: 2025-10-01
CVE-2022-49680
In the Linux kernel, the following vulnerability has been resolved: ARM: exynos: Fix refcount leak in exynos_map_pmu of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer.
- https://git.kernel.org/stable/c/31d09571bb071c20f6bdc0bb7ac1ef8dd2987c04
- https://git.kernel.org/stable/c/545ae5cbae839ce39bfe09828e413f1c916082de
- https://git.kernel.org/stable/c/68f28d52e6cbab8dcfa249cac4356d1d0573e868
- https://git.kernel.org/stable/c/7571bcecf01b69f0d3ec60ca41ce5d4c75411a4a
- https://git.kernel.org/stable/c/c4c79525042a4a7df96b73477feaf232fe44ae81
- https://git.kernel.org/stable/c/d23f76018e17618559da9eea179d137362023f95
- https://git.kernel.org/stable/c/f9b77a52937582a5b99a5a07e4ef1e2f48f87347
- https://git.kernel.org/stable/c/fc354856e9fad9cd36e2ad28f9da70716025055a
Modified: 2025-10-01
CVE-2022-49681
In the Linux kernel, the following vulnerability has been resolved: xtensa: xtfpga: Fix refcount leak bug in setup In machine_setup(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0162451723178602c37f0555d235dfa17e486112
- https://git.kernel.org/stable/c/0715d0e60052662c3f225342062f174dd721d1c7
- https://git.kernel.org/stable/c/173940b3ae40114d4179c251a98ee039dc9cd5b3
- https://git.kernel.org/stable/c/35d7e961be68732eb3acaeba81fb81ca16eafd05
- https://git.kernel.org/stable/c/6c0839cf1b9e1b3c88da6af76794583cbfae8da3
- https://git.kernel.org/stable/c/9b30c5c8884eda3f541229899671cebbad15979b
- https://git.kernel.org/stable/c/a52972ee706b438302eb0350e61f378eb191e3d1
- https://git.kernel.org/stable/c/b12d5c52f073a0420622aaf2f21b615cce8b36cc
Modified: 2025-10-01
CVE-2022-49682
In the Linux kernel, the following vulnerability has been resolved: xtensa: Fix refcount leak bug in time.c In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0dcc1dd8a5dd9240639f1051dfaa2dffc9fbbde5
- https://git.kernel.org/stable/c/0e403a383c14b63c86bd9df085b7e573e9caee64
- https://git.kernel.org/stable/c/3e5eb904d9ba657308fc75a5de434b0e58dcb8d7
- https://git.kernel.org/stable/c/7de4502af68f4f3932f450157f5483eb7b33cb74
- https://git.kernel.org/stable/c/a0117dc956429f2ede17b323046e1968d1849150
- https://git.kernel.org/stable/c/af0ff2da01521144bc11194f4c26485d7c9cee73
- https://git.kernel.org/stable/c/e5234a9d64a976abd134a14710dcd5188158a7c5
- https://git.kernel.org/stable/c/f1eaf4ba5372ad111f687a80c67e270708e14c23
Modified: 2025-10-01
CVE-2022-49683
In the Linux kernel, the following vulnerability has been resolved: iio: adc: adi-axi-adc: Fix refcount leak in adi_axi_adc_attach_client of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-10-01
CVE-2022-49684
In the Linux kernel, the following vulnerability has been resolved: iio: adc: aspeed: Fix refcount leak in aspeed_adc_set_trim_data of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
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: 2025-10-24
CVE-2022-49686
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix list double add in uvcg_video_pump A panic can occur if the endpoint becomes disabled and the uvcg_video_pump adds the request back to the req_free list after it has already been queued to the endpoint. The endpoint complete will add the request back to the req_free list. Invalidate the local request handle once it's been queued. <6>[ 246.796704][T13726] configfs-gadget gadget: uvc: uvc_function_set_alt(1, 0) <3>[ 246.797078][ T26] list_add double add: new=ffffff878bee5c40, prev=ffffff878bee5c40, next=ffffff878b0f0a90. <6>[ 246.797213][ T26] ------------[ cut here ]------------ <2>[ 246.797224][ T26] kernel BUG at lib/list_debug.c:31! <6>[ 246.807073][ T26] Call trace: <6>[ 246.807180][ T26] uvcg_video_pump+0x364/0x38c <6>[ 246.807366][ T26] process_one_work+0x2a4/0x544 <6>[ 246.807394][ T26] worker_thread+0x350/0x784 <6>[ 246.807442][ T26] kthread+0x2ac/0x320
Modified: 2026-01-22
CVE-2022-49687
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix xdp_rxq_info bug after suspend/resume
The following sequence currently causes a driver bug warning
when using virtio_net:
# ip link set eth0 up
# echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
- https://git.kernel.org/stable/c/340fbdc8011f2dc678f622c5ce1cbb5ab8305de7
- https://git.kernel.org/stable/c/57ee40f1b198b59d43c216fbc4672f9300d3c8b0
- https://git.kernel.org/stable/c/8af52fe9fd3bf5e7478da99193c0632276e1dfce
- https://git.kernel.org/stable/c/8c7a32b7c15555beddc5810c3334d9cefff061bf
- https://git.kernel.org/stable/c/8d7fe9ad6fddc2af8bde4b921b4f8fab231ed38c
- https://git.kernel.org/stable/c/9222672fa6370f0ec3d899662cb8680e9282fc4c
Modified: 2025-10-24
CVE-2022-49688
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix dynamic root getattr
The recent patch to make afs_getattr consult the server didn't account
for the pseudo-inodes employed by the dynamic root-type afs superblock
not having a volume or a server to access, and thus an oops occurs if
such a directory is stat'd.
Fix this by checking to see if the vnode->volume pointer actually points
anywhere before following it in afs_getattr().
This can be tested by stat'ing a directory in /afs. It may be
sufficient just to do "ls /afs" and the oops looks something like:
BUG: kernel NULL pointer dereference, address: 0000000000000020
...
RIP: 0010:afs_getattr+0x8b/0x14b
...
Call Trace:
- https://git.kernel.org/stable/c/2b2bba96526f25f2eba74ecadb031de2e05a83ce
- https://git.kernel.org/stable/c/65c24caf1b9f5b08397c6e805ec24ebc390c6e4d
- https://git.kernel.org/stable/c/7844ceada44eca740d31beb3d97b8511b1ca0a9b
- https://git.kernel.org/stable/c/7b564e3254b7db5fbfbf11a824627a6c31b932b4
- https://git.kernel.org/stable/c/cb78d1b5efffe4cf97e16766329dd7358aed3deb
- https://git.kernel.org/stable/c/e3a232e5767051483ffad4cef7d0a89d292a192b
Modified: 2025-10-24
CVE-2022-49691
In the Linux kernel, the following vulnerability has been resolved:
erspan: do not assume transport header is always set
Rewrite tests in ip6erspan_tunnel_xmit() and
erspan_fb_xmit() to not assume transport header is set.
syzbot reported:
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Modules linked in:
CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00
RSP: 0018:ffffc90005daf910 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003
RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40
R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000
FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0
Call Trace:
- https://git.kernel.org/stable/c/02da602bc2f353dccd9e489a604490034ded941e
- https://git.kernel.org/stable/c/2c8aeffc7c586d53e1d380f010bdca4f710f2480
- https://git.kernel.org/stable/c/301bd140ed0b24f0da660874c7e8a47dad8c8222
- https://git.kernel.org/stable/c/a3b2470399f679587c45abe56e551caf10becca2
- https://git.kernel.org/stable/c/cec9867ee55478ef5dcb2adf030fe0c442a4c4ee
- https://git.kernel.org/stable/c/fb401f37f6eadf24956d93687e5758c163c0d12b
Modified: 2025-10-01
CVE-2022-49692
In the Linux kernel, the following vulnerability has been resolved: net: phy: at803x: fix NULL pointer dereference on AR9331 PHY Latest kernel will explode on the PHY interrupt config, since it depends now on allocated priv. So, run probe to allocate priv to fix it. ar9331_switch ethernet.1:10 lan0 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:00] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13) CPU 0 Unable to handle kernel paging request at virtual address 0000000a, epc == 8050e8a8, ra == 80504b34 ... Call Trace: [<8050e8a8>] at803x_config_intr+0x5c/0xd0 [<80504b34>] phy_request_interrupt+0xa8/0xd0 [<8050289c>] phylink_bringup_phy+0x2d8/0x3ac [<80502b68>] phylink_fwnode_phy_connect+0x118/0x130 [<8074d8ec>] dsa_slave_create+0x270/0x420 [<80743b04>] dsa_port_setup+0x12c/0x148 [<8074580c>] dsa_register_switch+0xaf0/0xcc0 [<80511344>] ar9331_sw_probe+0x370/0x388 [<8050cb78>] mdio_probe+0x44/0x70 [<804df300>] really_probe+0x200/0x424 [<804df7b4>] __driver_probe_device+0x290/0x298 [<804df810>] driver_probe_device+0x54/0xe4 [<804dfd50>] __device_attach_driver+0xe4/0x130 [<804dcb00>] bus_for_each_drv+0xb4/0xd8 [<804dfac4>] __device_attach+0x104/0x1a4 [<804ddd24>] bus_probe_device+0x48/0xc4 [<804deb44>] deferred_probe_work_func+0xf0/0x10c [<800a0ffc>] process_one_work+0x314/0x4d4 [<800a17fc>] worker_thread+0x2a4/0x354 [<800a9a54>] kthread+0x134/0x13c [<8006306c>] ret_from_kernel_thread+0x14/0x1c Same Issue would affect some other PHYs (QCA8081, QCA9561), so fix it too.
Modified: 2025-10-01
CVE-2022-49693
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf of_graph_get_remote_node() returns remote device node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Patchwork: https://patchwork.freedesktop.org/patch/488473/
- https://git.kernel.org/stable/c/3c39a17197733bc37786ed68c83267c2f491840b
- https://git.kernel.org/stable/c/b9cc4598607cb7f7eae5c75fc1e3209cd52ff5e0
- https://git.kernel.org/stable/c/d1592d3e362cc59b29f15019707b16c695d70ca3
- https://git.kernel.org/stable/c/d16a4339825e64f9ddcdff5277982d640bae933b
- https://git.kernel.org/stable/c/d607da76fd2b1cf1d377af9d9b7c6f8fecbb0e1d
Modified: 2025-03-24
CVE-2022-49694
In the Linux kernel, the following vulnerability has been resolved: block: disable the elevator int del_gendisk The elevator is only used for file system requests, which are stopped in del_gendisk. Move disabling the elevator and freeing the scheduler tags to the end of del_gendisk instead of doing that work in disk_release and blk_cleanup_queue to avoid a use after free on q->tag_set from disk_release as the tag_set might not be alive at that point. Move the blk_qos_exit call as well, as it just depends on the elevator exit and would be the only reason to keep the not exactly cheap queue freeze in disk_release.
Modified: 2025-03-24
CVE-2022-49695
In the Linux kernel, the following vulnerability has been resolved:
igb: fix a use-after-free issue in igb_clean_tx_ring
Fix the following use-after-free bug in igb_clean_tx_ring routine when
the NIC is running in XDP mode. The issue can be triggered redirecting
traffic into the igb NIC and then closing the device while the traffic
is flowing.
[ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9
[ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017
[ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0
[ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282
[ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000
[ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0
[ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058
[ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090
[ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000
[ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000
[ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0
[ 73.426565] Call Trace:
[ 73.429087]
Modified: 2025-03-25
CVE-2022-49696
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix use-after-free Read in tipc_named_reinit
syzbot found the following issue on:
==================================================================
BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0
net/tipc/name_distr.c:413
Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764
CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted
5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0
Hardware name: Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Workqueue: events tipc_net_finalize_work
Call Trace:
Modified: 2025-10-24
CVE-2022-49697
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix request_sock leak in sk lookup helpers A customer reported a request_socket leak in a Calico cloud environment. We found that a BPF program was doing a socket lookup with takes a refcnt on the socket and that it was finding the request_socket but returning the parent LISTEN socket via sk_to_full_sk() without decrementing the child request socket 1st, resulting in request_sock slab object leak. This patch retains the existing behaviour of returning full socks to the caller but it also decrements the child request_socket if one is present before doing so to prevent the leak. Thanks to Curtis Taylor for all the help in diagnosing and testing this. And thanks to Antoine Tenart for the reproducer and patch input. v2 of this patch contains, refactor as per Daniel Borkmann's suggestions to validate RCU flags on the listen socket so that it balances with bpf_sk_release() and update comments as per Martin KaFai Lau's suggestion. One small change to Daniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extra instruction.
- https://git.kernel.org/stable/c/3046a827316c0e55fc563b4fb78c93b9ca5c7c37
- https://git.kernel.org/stable/c/516760f1d2979903eaad5b437256913c5cd98416
- https://git.kernel.org/stable/c/5a62b5ba4c0ce8315b6382cd4ace81b48cd121cd
- https://git.kernel.org/stable/c/8ffe2e50e9678c8373027492035f094b130437f1
- https://git.kernel.org/stable/c/b03607437ea81b850599f705096b05b85e7a4a71
Modified: 2025-10-24
CVE-2022-49698
In the Linux kernel, the following vulnerability has been resolved: netfilter: use get_random_u32 instead of prandom bh might occur while updating per-cpu rnd_state from user context, ie. local_out path. BUG: using smp_processor_id() in preemptible [00000000] code: nginx/2725 caller is nft_ng_random_eval+0x24/0x54 [nft_numgen] Call Trace: check_preemption_disabled+0xde/0xe0 nft_ng_random_eval+0x24/0x54 [nft_numgen] Use the random driver instead, this also avoids need for local prandom state. Moreover, prandom now uses the random driver since d4150779e60f ("random32: use real rng for non-deterministic randomness"). Based on earlier patch from Pablo Neira.
Modified: 2025-10-24
CVE-2022-49699
In the Linux kernel, the following vulnerability has been resolved: filemap: Handle sibling entries in filemap_get_read_batch() If a read races with an invalidation followed by another read, it is possible for a folio to be replaced with a higher-order folio. If that happens, we'll see a sibling entry for the new folio in the next iteration of the loop. This manifests as a NULL pointer dereference while holding the RCU read lock. Handle this by simply returning. The next call will find the new folio and handle it correctly. The other ways of handling this rare race are more complex and it's just not worth it.
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-24
CVE-2022-49701
In the Linux kernel, the following vulnerability has been resolved:
scsi: ibmvfc: Allocate/free queue resource only during probe/remove
Currently, the sub-queues and event pool resources are allocated/freed for
every CRQ connection event such as reset and LPM. This exposes the driver
to a couple issues. First the inefficiency of freeing and reallocating
memory that can simply be resued after being sanitized. Further, a system
under memory pressue runs the risk of allocation failures that could result
in a crippled driver. Finally, there is a race window where command
submission/compeletion can try to pull/return elements from/to an event
pool that is being deleted or already has been deleted due to the lack of
host state around freeing/allocating resources. The following is an example
of list corruption following a live partition migration (LPM):
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: vfat fat isofs cdrom ext4 mbcache jbd2 nft_counter nft_compat nf_tables nfnetlink rpadlpar_io rpaphp xsk_diag nfsv3 nfs_acl nfs lockd grace fscache netfs rfkill bonding tls sunrpc pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth vmx_crypto dm_multipath dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
CPU: 0 PID: 2108 Comm: ibmvfc_0 Kdump: loaded Not tainted 5.14.0-70.9.1.el9_0.ppc64le #1
NIP: c0000000007c4bb0 LR: c0000000007c4bac CTR: 00000000005b9a10
REGS: c00000025c10b760 TRAP: 0700 Not tainted (5.14.0-70.9.1.el9_0.ppc64le)
MSR: 800000000282b033
Modified: 2025-10-24
CVE-2022-49702
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix hang during unmount when block group reclaim task is running
When we start an unmount, at close_ctree(), if we have the reclaim task
running and in the middle of a data block group relocation, we can trigger
a deadlock when stopping an async reclaim task, producing a trace like the
following:
[629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000
[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
[629724.501267] Call Trace:
[629724.501759]
Modified: 2025-10-01
CVE-2022-49703
In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Store vhost pointer during subcrq allocation Currently the back pointer from a queue to the vhost adapter isn't set until after subcrq interrupt registration. The value is available when a queue is first allocated and can/should be also set for primary and async queues as well as subcrqs. This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS interrupt controller where a pending subcrq interrupt from the previous kernel can be replayed immediately upon IRQ registration resulting in dereference of a garbage backpointer in ibmvfc_interrupt_scsi(). Kernel attempted to read user page (58) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000058 Faulting instruction address: 0xc008000003216a08 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc] LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 Call Trace: [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable) [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188 [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310 [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80 [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0 [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130 [c000000014622f60] [0000000020000000] 0x20000000 [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0 [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0 [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170 [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0 [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0 [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230 [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc] [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc] [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc] [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc] [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc]
Modified: 2025-10-01
CVE-2022-49704
In the Linux kernel, the following vulnerability has been resolved: 9p: fix fid refcount leak in v9fs_vfs_get_link we check for protocol version later than required, after a fid has been obtained. Just move the version check earlier.
Modified: 2025-10-01
CVE-2022-49705
In the Linux kernel, the following vulnerability has been resolved: 9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl We need to release directory fid if we fail halfway through open This fixes fid leaking with xfstests generic 531
Modified: 2025-10-24
CVE-2022-49732
In the Linux kernel, the following vulnerability has been resolved: sock: redo the psock vs ULP protection check Commit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()") has moved the inet_csk_has_ulp(sk) check from sk_psock_init() to the new tcp_bpf_update_proto() function. I'm guessing that this was done to allow creating psocks for non-inet sockets. Unfortunately the destruction path for psock includes the ULP unwind, so we need to fail the sk_psock_init() itself. Otherwise if ULP is already present we'll notice that later, and call tcp_update_ulp() with the sk_proto of the ULP itself, which will most likely result in the ULP looping its callbacks.
Modified: 2025-10-01
CVE-2022-49733
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix race at SNDCTL_DSP_SYNC There is a small race window at snd_pcm_oss_sync() that is called from OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls snd_pcm_oss_make_ready() at first, then takes the params_lock mutex for the rest. When the stream is set up again by another thread between them, it leads to inconsistency, and may result in unexpected results such as NULL dereference of OSS buffer as a fuzzer spotted recently. The fix is simply to cover snd_pcm_oss_make_ready() call into the same params_lock mutex with snd_pcm_oss_make_ready_locked() variant.
- https://git.kernel.org/stable/c/4051324a6dafd7053c74c475e80b3ba10ae672b0
- https://git.kernel.org/stable/c/723ac5ab2891b6c10dd6cc78ef5456af593490eb
- https://git.kernel.org/stable/c/8015ef9e8a0ee5cecfd0cb6805834d007ab26f86
- https://git.kernel.org/stable/c/8423f0b6d513b259fdab9c9bf4aaa6188d054c2d
- https://git.kernel.org/stable/c/fce793a056c604b41a298317cf704dae255f1b36
Modified: 2025-11-14
CVE-2022-49934
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix UAF in ieee80211_scan_rx() ieee80211_scan_rx() tries to access scan_req->flags after a null check, but a UAF is observed when the scan is completed and __ieee80211_scan_completed() executes, which then calls cfg80211_scan_done() leading to the freeing of scan_req. Since scan_req is rcu_dereference()'d, prevent the racing in __ieee80211_scan_completed() by ensuring that from mac80211's POV it is no longer accessed from an RCU read critical section before we call cfg80211_scan_done().
- https://git.kernel.org/stable/c/4abc8c07a065ecf771827bde3c63fbbe4aa0c08b
- https://git.kernel.org/stable/c/5d20c6f932f2758078d0454729129c894fe353e7
- https://git.kernel.org/stable/c/60deb9f10eec5c6a20252ed36238b55d8b614a2c
- https://git.kernel.org/stable/c/6eb181a64fdabf10be9e54de728876667da20255
- https://git.kernel.org/stable/c/78a07732fbb0934d14827d8f09b9aa6a49ee1aa9
- https://git.kernel.org/stable/c/9ad48cbf8b07f10c1e4a7a262b32a9179ae9dd2d
- https://git.kernel.org/stable/c/c0445feb80a4d0854898118fa01073701f8d356b
- https://git.kernel.org/stable/c/e0ff39448cea654843744c72c6780293c5082cb1
Modified: 2025-11-14
CVE-2022-49935
In the Linux kernel, the following vulnerability has been resolved: dma-buf/dma-resv: check if the new fence is really later Previously when we added a fence to a dma_resv object we always assumed the the newer than all the existing fences. With Jason's work to add an UAPI to explicit export/import that's not necessary the case any more. So without this check we would allow userspace to force the kernel into an use after free error. Since the change is very small and defensive it's probably a good idea to backport this to stable kernels as well just in case others are using the dma_resv object in the same way.
Modified: 2025-11-14
CVE-2022-49936
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Prevent nested device-reset calls
Automatic kernel fuzzing revealed a recursive locking violation in
usb-storage:
============================================
WARNING: possible recursive locking detected
5.18.0 #3 Not tainted
--------------------------------------------
kworker/1:3/1205 is trying to acquire lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
but task is already holding lock:
ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
...
stack backtrace:
CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
- https://git.kernel.org/stable/c/1b29498669914c7f9afb619722421418a753d372
- https://git.kernel.org/stable/c/9c6d778800b921bde3bff3cff5003d1650f942d1
- https://git.kernel.org/stable/c/abe3cfb7a7c8e907b312c7dbd7bf4d142b745aa8
- https://git.kernel.org/stable/c/c548b99e1c37db6f7df86ecfe9a1f895d6c5966e
- https://git.kernel.org/stable/c/cc9a12e12808af178c600cc485338bac2e37d2a8
- https://git.kernel.org/stable/c/d5eb850b3e8836197a38475840725260b9783e94
- https://git.kernel.org/stable/c/d90419b8b8322b6924f6da9da952647f2dadc21b
- https://git.kernel.org/stable/c/df1875084898b15cbc42f712e93d7f113ae6271b
Modified: 2025-11-14
CVE-2022-49937
In the Linux kernel, the following vulnerability has been resolved:
media: mceusb: Use new usb_control_msg_*() routines
Automatic kernel fuzzing led to a WARN about invalid pipe direction in
the mceusb driver:
------------[ cut here ]------------
usb 6-1: BOGUS control dir, pipe 80000380 doesn't match bRequestType 40
WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410
usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410
Modules linked in:
CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410
Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8
44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b
e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41
RSP: 0018:ffffc900032becf0 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000
RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90
RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000
R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000
R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500
FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0
Call Trace:
Modified: 2025-11-14
CVE-2022-49938
In the Linux kernel, the following vulnerability has been resolved: cifs: fix small mempool leak in SMB2_negotiate() In some cases of failure (dialect mismatches) in SMB2_negotiate(), after the request is sent, the checks would return -EIO when they should be rather setting rc = -EIO and jumping to neg_exit to free the response buffer from mempool.
Modified: 2025-11-14
CVE-2022-49939
In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF of ref->proc caused by race condition A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20
- https://git.kernel.org/stable/c/06e5b43ca4dab06a92bf4c2f33766e6fb11b880a
- https://git.kernel.org/stable/c/229f47603dd306bc0eb1a831439adb8e48bb0eae
- https://git.kernel.org/stable/c/30d0901b307f27d36b2655fb3048cf31ee0e89c0
- https://git.kernel.org/stable/c/603a47f2ae56bf68288784d3c0a8c5b8e0a827ed
- https://git.kernel.org/stable/c/9629f2dfdb1dad294b468038ff8e161e94d0b609
- https://git.kernel.org/stable/c/a0e44c64b6061dda7e00b7c458e4523e2331b739
- https://git.kernel.org/stable/c/c2a4b5dc8fa71af73bab704d0cac42ac39767ed6
Modified: 2025-11-14
CVE-2022-49942
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected When we are not connected to a channel, sending channel "switch" announcement doesn't make any sense. The BSS list is empty in that case. This causes the for loop in cfg80211_get_bss() to be bypassed, so the function returns NULL (check line 1424 of net/wireless/scan.c), causing the WARN_ON() in ieee80211_ibss_csa_beacon() to get triggered (check line 500 of net/mac80211/ibss.c), which was consequently reported on the syzkaller dashboard. Thus, check if we have an existing connection before generating the CSA beacon in ieee80211_ibss_finish_csa().
- https://git.kernel.org/stable/c/15bc8966b6d3a5b9bfe4c9facfa02f2b69b1e5f0
- https://git.kernel.org/stable/c/1691a48aef0a82d1754b9853dae7e3f5cacdf70b
- https://git.kernel.org/stable/c/552ba102a6898630a7d16887f29e606d6fabe508
- https://git.kernel.org/stable/c/66689c5c02acd4d76c28498fe220998610aec61e
- https://git.kernel.org/stable/c/864e280cb3a9a0f5212b16ef5057c4e692f7039d
- https://git.kernel.org/stable/c/cdb9a8da9b84800eb15506cd9363cf0cf059e677
- https://git.kernel.org/stable/c/d9eb37db6a28b59a95a3461450ee209654c5f95b
- https://git.kernel.org/stable/c/dd649b49219a0388cc10fc40e4c2ea681566a780
Modified: 2025-11-14
CVE-2022-49945
In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix array out of bounds access The driver does not check if the cooling state passed to gpio_fan_set_cur_state() exceeds the maximum cooling state as stored in fan_data->num_speeds. Since the cooling state is later used as an array index in set_fan_speed(), an array out of bounds access can occur. This can be exploited by setting the state of the thermal cooling device to arbitrary values, causing for example a kernel oops when unavailable memory is accessed this way. Example kernel oops: [ 807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064 [ 807.987369] Mem abort info: [ 807.987398] ESR = 0x96000005 [ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits [ 807.987477] SET = 0, FnV = 0 [ 807.987507] EA = 0, S1PTW = 0 [ 807.987536] FSC = 0x05: level 1 translation fault [ 807.987570] Data abort info: [ 807.987763] ISV = 0, ISS = 0x00000005 [ 807.987801] CM = 0, WnR = 0 [ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000 [ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575 [ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.988691] sp : ffffffc008cf3bd0 [ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000 [ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920 [ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c [ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000 [ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70 [ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c [ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009 [ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8 [ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060 [ 807.989084] Call trace: [ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.989199] cur_state_store+0x84/0xd0 [ 807.989221] dev_attr_store+0x20/0x38 [ 807.989262] sysfs_kf_write+0x4c/0x60 [ 807.989282] kernfs_fop_write_iter+0x130/0x1c0 [ 807.989298] new_sync_write+0x10c/0x190 [ 807.989315] vfs_write+0x254/0x378 [ 807.989362] ksys_write+0x70/0xf8 [ 807.989379] __arm64_sys_write+0x24/0x30 [ 807.989424] invoke_syscall+0x4c/0x110 [ 807.989442] el0_svc_common.constprop.3+0xfc/0x120 [ 807.989458] do_el0_svc+0x2c/0x90 [ 807.989473] el0_svc+0x24/0x60 [ 807.989544] el0t_64_sync_handler+0x90/0xb8 [ 807.989558] el0t_64_sync+0x1a0/0x1a4 [ 807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416) [ 807.989627] ---[ end t ---truncated---
- https://git.kernel.org/stable/c/3263984c7acdcb0658155b05a724ed45a10de76d
- https://git.kernel.org/stable/c/3ff866455e1e263a9ac1958095fd440984248e2f
- https://git.kernel.org/stable/c/517dba798793e69b510779c3cde7224a65f3ed1d
- https://git.kernel.org/stable/c/53196e0376205ed49b75bfd0475af5e0fbd20156
- https://git.kernel.org/stable/c/7756eb1ed124753f4d64f761fc3d84290dffcb4d
- https://git.kernel.org/stable/c/c8ae6a18708f260ccdeef6ba53af7548457dc26c
- https://git.kernel.org/stable/c/e9f6972ab40a82bd7f6d36800792ba2e084474d8
- https://git.kernel.org/stable/c/f233d2be38dbbb22299192292983037f01ab363c
Modified: 2025-11-14
CVE-2022-49946
In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Prevent out-of-bounds access The while loop in raspberrypi_discover_clocks() relies on the assumption that the id of the last clock element is zero. Because this data comes from the Videocore firmware and it doesn't guarantuee such a behavior this could lead to out-of-bounds access. So fix this by providing a sentinel element.
Modified: 2025-11-14
CVE-2022-49948
In the Linux kernel, the following vulnerability has been resolved: vt: Clear selection before changing the font When changing the console font with ioctl(KDFONTOP) the new font size can be bigger than the previous font. A previous selection may thus now be outside of the new screen size and thus trigger out-of-bounds accesses to graphics memory if the selection is removed in vc_do_resize(). Prevent such out-of-memory accesses by dropping the selection before the various con_font_set() console handlers are called.
- https://git.kernel.org/stable/c/1cf1930369c9dc428d827b60260c53271bff3285
- https://git.kernel.org/stable/c/2535431ae967ad17585513649625fea7db28d4db
- https://git.kernel.org/stable/c/566f9c9f89337792070b5a6062dff448b3e7977f
- https://git.kernel.org/stable/c/989201bb8c00b222235aff04e6200230d29dc7bb
- https://git.kernel.org/stable/c/c555cf04684fde39b5b0dd9fd80730030ee10c4a
- https://git.kernel.org/stable/c/c904fe03c4bd1f356a58797d39e2a5d0ca15cefc
- https://git.kernel.org/stable/c/e9ba4611ddf676194385506222cce7b0844e708e
- https://git.kernel.org/stable/c/f74b4a41c5d7c9522469917e3072e55d435efd9e
Modified: 2025-12-31
CVE-2022-49950
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix memory corruption on open The probe session-duplication overflow check incremented the session count also when there were no more available sessions so that memory beyond the fixed-size slab-allocated session array could be corrupted in fastrpc_session_alloc() on open().
- https://git.kernel.org/stable/c/5cf2a57c7a01a0d7bdecf875a63682f542891b1b
- https://git.kernel.org/stable/c/cf20c3533efc89578ace94fa20a9e63446223c72
- https://git.kernel.org/stable/c/d245f43aab2b61195d8ebb64cef7b5a08c590ab4
- https://git.kernel.org/stable/c/e0578e603065f120a8759b75e0d6c216c7078a39
- https://git.kernel.org/stable/c/f8632b8bb53ebc005d8f24a68a0c1f9678c0e908
Modified: 2025-11-14
CVE-2022-49952
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix memory corruption on probe Add the missing sanity check on the probed-session count to avoid corrupting memory beyond the fixed-size slab-allocated session array when there are more than FASTRPC_MAX_SESSIONS sessions defined in the devicetree.
- https://git.kernel.org/stable/c/0e33b0f322fecd7a92d9dc186535cdf97940a856
- https://git.kernel.org/stable/c/9baa1415d9abdd1e08362ea2dcfadfacee8690b5
- https://git.kernel.org/stable/c/c0425c2facd9166fa083f90c9f3187ace0c7837a
- https://git.kernel.org/stable/c/c99bc901d5eb9fbdd7bd39f625e170ce97390336
- https://git.kernel.org/stable/c/ec186b9f4aa2e6444d5308a6cc268aada7007639
Modified: 2025-11-14
CVE-2022-49953
In the Linux kernel, the following vulnerability has been resolved: iio: light: cm3605: Fix an error handling path in cm3605_probe() The commit in Fixes also introduced a new error handling path which should goto the existing error handling path. Otherwise some resources leak.
Modified: 2025-11-14
CVE-2022-49954
In the Linux kernel, the following vulnerability has been resolved: Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag syzbot is reporting hung task at __input_unregister_device() [1], for iforce_close() waiting at wait_event_interruptible() with dev->mutex held is blocking input_disconnect_device() from __input_unregister_device(). It seems that the cause is simply that commit c2b27ef672992a20 ("Input: iforce - wait for command completion when closing the device") forgot to call wake_up() after clear_bit(). Fix this problem by introducing a helper that calls clear_bit() followed by wake_up_all().
- https://git.kernel.org/stable/c/98e01215708b6d416345465c09dce2bd4868c67a
- https://git.kernel.org/stable/c/b271090eea3899399e2adcf79c9c95367d472b03
- https://git.kernel.org/stable/c/b533b9d3a0d1327cbb31c201dc8dbbf98c8bfe3c
- https://git.kernel.org/stable/c/d186c65599bff0222da37b9215784ddfe39f9e1b
- https://git.kernel.org/stable/c/df1b53bc799d58f79701c465505a206c72ad4ab8
Modified: 2025-11-14
CVE-2022-49955
In the Linux kernel, the following vulnerability has been resolved:
powerpc/rtas: Fix RTAS MSR[HV] handling for Cell
The semi-recent changes to MSR handling when entering RTAS (firmware)
cause crashes on IBM Cell machines. An example trace:
kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0x2fff01a8
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.0.0-rc2-00433-gede0a8d3307a #207
NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000
REGS: c0000000015236b0 TRAP: 0400 Tainted: G W (6.0.0-rc2-00433-gede0a8d3307a)
MSR: 0000000008001002
Modified: 2025-11-17
CVE-2022-49956
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix use after free bugs _Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl() functions don't do anything except free the "pcmd" pointer. It results in a use after free. Delete them.
- https://git.kernel.org/stable/c/19e3f69d19801940abc2ac37c169882769ed9770
- https://git.kernel.org/stable/c/376e15487fec837301d888068a3fcc82efb6171a
- https://git.kernel.org/stable/c/7dce6b0ee7d78667d6c831ced957a08769973063
- https://git.kernel.org/stable/c/9fd6170c5e2d0ccd027abe26f6f5ffc528e1bb27
- https://git.kernel.org/stable/c/b1727def850904e4b8ba384043775672841663a1
- https://git.kernel.org/stable/c/d0aac7146e96bf39e79c65087d21dfa02ef8db38
- https://git.kernel.org/stable/c/dc02aaf950015850e7589696521c7fca767cea77
- https://git.kernel.org/stable/c/e230a4455ac3e9b112f0367d1b8e255e141afae0
Modified: 2025-11-14
CVE-2022-49957
In the Linux kernel, the following vulnerability has been resolved: kcm: fix strp_init() order and cleanup strp_init() is called just a few lines above this csk->sk_user_data check, it also initializes strp->work etc., therefore, it is unnecessary to call strp_done() to cancel the freshly initialized work. And if sk_user_data is already used by KCM, psock->strp should not be touched, particularly strp->work state, so we need to move strp_init() after the csk->sk_user_data check. This also makes a lockdep warning reported by syzbot go away.
- https://git.kernel.org/stable/c/0946ff31d1a8778787bf6708beb20f38715267cc
- https://git.kernel.org/stable/c/1b6666964ca1de93a7bf06e122bcf3616dbd33a9
- https://git.kernel.org/stable/c/473f394953216614087f4179e55cdf0cf616a13b
- https://git.kernel.org/stable/c/55fb8c3baa8071c5d533a9ad48624e44e2a04ef5
- https://git.kernel.org/stable/c/8fc29ff3910f3af08a7c40a75d436b5720efe2bf
- https://git.kernel.org/stable/c/a8a0c321319ad64a5427d6172cd9c23b4d6ca1e8
- https://git.kernel.org/stable/c/f865976baa85915c7672f351b74d5974b93215f6
Modified: 2025-11-14
CVE-2022-49958
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix netdevice reference leaks in attach_default_qdiscs() In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails to attach qdisc because there is no memory in attach_one_default_qdisc(). Then dev->qdisc will be noop_qdisc by default. But the other queues may be able to successfully attach to default qdisc. In this case, the fallback to noqueue process will be triggered. If the original attached qdisc is not released and a new one is directly attached, this will cause netdevice reference leaks. The following is the bug log: veth0: default qdisc (fq_codel) fail, fallback to noqueue unregister_netdevice: waiting for veth0 to become free. Usage count = 32 leaked reference. qdisc_alloc+0x12e/0x210 qdisc_create_dflt+0x62/0x140 attach_one_default_qdisc.constprop.41+0x44/0x70 dev_activate+0x128/0x290 __dev_open+0x12a/0x190 __dev_change_flags+0x1a2/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x332/0x1150 __rtnl_newlink+0x52f/0x8e0 rtnl_newlink+0x43/0x70 rtnetlink_rcv_msg+0x140/0x3b0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1bb/0x290 netlink_sendmsg+0x37c/0x4e0 sock_sendmsg+0x5f/0x70 ____sys_sendmsg+0x208/0x280 Fix this bug by clearing any non-noop qdiscs that may have been assigned before trying to re-attach.
Modified: 2025-11-14
CVE-2022-49959
In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix memory leak at failed datapath creation ovs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids() allocates array via kmalloc. If for some reason new_vport() fails during ovs_dp_cmd_new() dp->upcall_portids must be freed. Add missing kfree. Kmemleak example: unreferenced object 0xffff88800c382500 (size 64): comm "dump_state", pid 323, jiffies 4294955418 (age 104.347s) hex dump (first 32 bytes): 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8..... 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(... backtrace: [<0000000071bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0 [<000000000187d8bd>] ovs_dp_change+0x63/0xe0 [<000000002397e446>] ovs_dp_cmd_new+0x1f0/0x380 [<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150 [<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0 [<00000000fa10e377>] netlink_rcv_skb+0x50/0x100 [<000000004959cece>] genl_rcv+0x24/0x40 [<000000004699ac7f>] netlink_unicast+0x23e/0x360 [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0 [<000000006f4aa380>] sock_sendmsg+0x62/0x70 [<00000000d0068654>] ____sys_sendmsg+0x230/0x270 [<0000000012dacf7d>] ___sys_sendmsg+0x88/0xd0 [<0000000011776020>] __sys_sendmsg+0x59/0xa0 [<000000002e8f2dc1>] do_syscall_64+0x3b/0x90 [<000000003243e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Modified: 2025-11-14
CVE-2022-49960
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: fix null pointer dereference
Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
The root cause is null pointer defeference of bi_next
in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.
BUG: kernel NULL pointer dereference, address: 000000000000002e
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G U 5.17.0-rc1
Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021
RIP: 0010:tgl_get_bw_info+0x2de/0x510
...
[ 2.554467] Call Trace:
[ 2.554467]
Modified: 2025-11-14
CVE-2022-49961
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg->precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.
To show a concrete example of the problem:
0000000000000000
Modified: 2025-11-14
CVE-2022-49966
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid To avoid any potential memory leak.
Modified: 2025-11-14
CVE-2022-49967
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a data-race around bpf_jit_limit. While reading bpf_jit_limit, it can be changed concurrently via sysctl, WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit is long, so we need to add a paired READ_ONCE() to avoid load-tearing.
Modified: 2025-11-13
CVE-2022-49968
In the Linux kernel, the following vulnerability has been resolved: ieee802154/adf7242: defer destroy_workqueue call There is a possible race condition (use-after-free) like below (FREE) | (USE) adf7242_remove | adf7242_channel cancel_delayed_work_sync | destroy_workqueue (1) | adf7242_cmd_rx | mod_delayed_work (2) | The root cause for this race is that the upper layer (ieee802154) is unaware of this detaching event and the function adf7242_channel can be called without any checks. To fix this, we can add a flag write at the beginning of adf7242_remove and add flag check in adf7242_channel. Or we can just defer the destructive operation like other commit 3e0588c291d6 ("hamradio: defer ax25 kfree after unregister_netdev") which let the ieee802154_unregister_hw() to handle the synchronization. This patch takes the second option. runs")
- https://git.kernel.org/stable/c/15f3b89bd521d5770d36a61fc04a77c293138ba6
- https://git.kernel.org/stable/c/23a29932715ca43bceb2eae1bdb770995afe7271
- https://git.kernel.org/stable/c/9f8558c5c642c62c450c98c99b7d18a709fff485
- https://git.kernel.org/stable/c/afe7116f6d3b888778ed6d95e3cf724767b9aedf
- https://git.kernel.org/stable/c/bed12d7531df1417fc92c691999ff95e03835008
- https://git.kernel.org/stable/c/dede80aaf01f4b6e8657d23726cb4a3da226ec4c
Modified: 2025-11-13
CVE-2022-49969
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: clear optc underflow before turn off odm clock [Why] After ODM clock off, optc underflow bit will be kept there always and clear not work. We need to clear that before clock off. [How] Clear that if have when clock off.
- https://git.kernel.org/stable/c/3101839b080137c367f3f88c2a040f791de880aa
- https://git.kernel.org/stable/c/3c1dfeaeb3b4e3ea656041da1241e6ee3c3b3202
- https://git.kernel.org/stable/c/443687798d6f094412b7312b64b3bb4d99aedff7
- https://git.kernel.org/stable/c/5ee30bcfdb32526233d2572f3d9ec371928679f1
- https://git.kernel.org/stable/c/814b756d4ec3a8728debb116cf49005feada7750
- https://git.kernel.org/stable/c/b2a93490201300a749ad261b5c5d05cb50179c44
Modified: 2025-11-13
CVE-2022-49972
In the Linux kernel, the following vulnerability has been resolved: xsk: Fix corrupted packets for XDP_SHARED_UMEM Fix an issue in XDP_SHARED_UMEM mode together with aligned mode where packets are corrupted for the second and any further sockets bound to the same umem. In other words, this does not affect the first socket bound to the umem. The culprit for this bug is that the initialization of the DMA addresses for the pre-populated xsk buffer pool entries was not performed for any socket but the first one bound to the umem. Only the linear array of DMA addresses was populated. Fix this by populating the DMA addresses in the xsk buffer pool for every socket bound to the same umem.
Modified: 2025-11-13
CVE-2022-49974
In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: fix rumble worker null pointer deref We can dereference a null pointer trying to queue work to a destroyed workqueue. If the device is disconnected, nintendo_hid_remove is called, in which the rumble_queue is destroyed. Avoid using that queue to defer rumble work once the controller state is set to JOYCON_CTLR_STATE_REMOVED. This eliminates the null pointer dereference.
Modified: 2025-11-13
CVE-2022-49975
In the Linux kernel, the following vulnerability has been resolved: bpf: Don't redirect packets with invalid pkt_len Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly.
- https://git.kernel.org/stable/c/6204bf78b2a903b96ba43afff6abc0b04d6e0462
- https://git.kernel.org/stable/c/72f2dc8993f10262092745a88cb2dd0fef094f23
- https://git.kernel.org/stable/c/8b68e53d56697a59b5c53893b53f508bbdf272a0
- https://git.kernel.org/stable/c/a75987714bd2d8e59840667a28e15c1fa5c47554
- https://git.kernel.org/stable/c/fd1894224407c484f652ad456e1ce423e89bb3eb
Modified: 2025-11-13
CVE-2022-49976
In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix broken touchscreen on Chuwi Hi8 with Windows BIOS The x86-android-tablets handling for the Chuwi Hi8 is only necessary with the Android BIOS and it is causing problems with the Windows BIOS version. Specifically when trying to register the already present touchscreen x86_acpi_irq_helper_get() calls acpi_unregister_gsi(), this breaks the working of the touchscreen and also leads to an oops: [ 14.248946] ------------[ cut here ]------------ [ 14.248954] remove_proc_entry: removing non-empty directory 'irq/75', leaking at least 'MSSL0001:00' [ 14.248983] WARNING: CPU: 3 PID: 440 at fs/proc/generic.c:718 remove_proc_entry ... [ 14.249293] unregister_irq_proc+0xe0/0x100 [ 14.249305] free_desc+0x29/0x70 [ 14.249312] irq_free_descs+0x4b/0x80 [ 14.249320] mp_unmap_irq+0x5c/0x60 [ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40 [ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets] [ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets] Add an init callback for the Chuwi Hi8, which detects when the Windows BIOS is in use and exits with -ENODEV in that case, fixing this.
Modified: 2025-11-14
CVE-2022-49977
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead ftrace_startup does not remove ops from ftrace_ops_list when ftrace_startup_enable fails: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1 ... return 0 // ops is in the ftrace_ops_list. When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // return here, __unregister_ftrace_function is not executed, // as a result, ops is still in the ftrace_ops_list __unregister_ftrace_function ... If ops is dynamically allocated, it will be free later, in this case, is_ftrace_trampoline accesses NULL pointer: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL! Syzkaller reports as follows: [ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b [ 1203.508039] #PF: supervisor read access in kernel mode [ 1203.508798] #PF: error_code(0x0000) - not-present page [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8 [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866 [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Therefore, when ftrace_startup_enable fails, we need to rollback registration process and remove ops from ftrace_ops_list.
- https://git.kernel.org/stable/c/4c34a2a6c9927c239dd2e295a03d49b37b618d2c
- https://git.kernel.org/stable/c/8569b4ada1e0b9bfaa125bd0c0967918b6560fa2
- https://git.kernel.org/stable/c/934e49f7d696afdae9f979abe3f308408184e17b
- https://git.kernel.org/stable/c/c3b0f72e805f0801f05fa2aa52011c4bfc694c44
- https://git.kernel.org/stable/c/d81bd6671f45fde4c3ac7fd7733c6e3082ae9d8e
- https://git.kernel.org/stable/c/dbd8c8fc60480e3faa3ae7e27ebe03371ecd1b77
- https://git.kernel.org/stable/c/ddffe882d74ef43a3494f0ab0c24baf076c45f96
- https://git.kernel.org/stable/c/e4ae97295984ff1b9b340ed18ae1b066f36b7835
Modified: 2025-11-14
CVE-2022-49978
In the Linux kernel, the following vulnerability has been resolved:
fbdev: fb_pm2fb: Avoid potential divide by zero error
In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be
copied from user, then go through `fb_set_var()` and
`info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`.
Along the path, `var->pixclock` won't be modified. This function checks
whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is
zero, there will be a divide by zero error. So, it is necessary to check
whether denominator is zero to avoid crash. As this bug is found by
Syzkaller, logs are listed below.
divide error in pm2fb_check_var
Call Trace:
- https://git.kernel.org/stable/c/0f1174f4972ea9fad6becf8881d71adca8e9ca91
- https://git.kernel.org/stable/c/19f953e7435644b81332dd632ba1b2d80b1e37af
- https://git.kernel.org/stable/c/34c3dea1189525cd533071ed5c176fc4ea8d982b
- https://git.kernel.org/stable/c/3ec326a6a0d4667585ca595f438c7293e5ced7c4
- https://git.kernel.org/stable/c/7d9591b32a9092fc6391a316b56e8016c6181c3d
- https://git.kernel.org/stable/c/7f88cdfea8d7f4dbaf423d808241403b2bb945e4
- https://git.kernel.org/stable/c/8fc778ee2fb2853f7a3531fa7273349640d8e4e9
- https://git.kernel.org/stable/c/cb4bb011a683532841344ca7f281b5e04389b4f8
Modified: 2025-12-23
CVE-2022-49979
In the Linux kernel, the following vulnerability has been resolved:
net: fix refcount bug in sk_psock_get (2)
Syzkaller reports refcount bug as follows:
------------[ cut here ]------------
refcount_t: saturated; leaking memory.
WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19
Modules linked in:
CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0
Modified: 2025-11-14
CVE-2022-49980
In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: Fix use-after-free Read in usb_udc_uevent()
The syzbot fuzzer found a race between uevent callbacks and gadget
driver unregistration that can cause a use-after-free bug:
---------------------------------------------------------------
BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130
drivers/usb/gadget/udc/core.c:1732
Read of size 8 at addr ffff888078ce2050 by task udevd/2968
CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
06/29/2022
Call Trace:
Modified: 2025-11-14
CVE-2022-49981
In the Linux kernel, the following vulnerability has been resolved:
HID: hidraw: fix memory leak in hidraw_release()
Free the buffered reports before deleting the list entry.
BUG: memory leak
unreferenced object 0xffff88810e72f180 (size 32):
comm "softirq", pid 0, jiffies 4294945143 (age 16.080s)
hex dump (first 32 bytes):
64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/1bea0bbf66001b0c7bf239a4d70eaf47824d3feb
- https://git.kernel.org/stable/c/52a3c62a815161c2dcf38ac421f6c41d8679462b
- https://git.kernel.org/stable/c/53c7c4d5d40b45c127cb1193bf3e9670f844c3cf
- https://git.kernel.org/stable/c/7e2fa79226580b035b00260d9f240ab9bda4af5d
- https://git.kernel.org/stable/c/a5623a203cffe2d2b84d2f6c989d9017db1856af
- https://git.kernel.org/stable/c/c06b013f5cbfeafe0a9cfa5a7128604c34e0e517
- https://git.kernel.org/stable/c/dfd27a737283313a3e626e97b9d9b2d8d6a94188
- https://git.kernel.org/stable/c/f5b7e9611cffec345d62d5bdd8b6e30e89956818
Modified: 2025-11-14
CVE-2022-49982
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix memory leak in pvr_probe The error handling code in pvr2_hdw_create forgets to unregister the v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create, it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL, which leads to that pvr2_hdw_destroy directly returns. Fix this by adding v4l2_device_unregister to decrease the refcount of usb interface.
- https://git.kernel.org/stable/c/2fe46195d2f0d5d09ea65433aefe47a4d0d0ff4d
- https://git.kernel.org/stable/c/466b67c0543b2ae67814d053f6e29b39be6b33bb
- https://git.kernel.org/stable/c/491762b3250fb06a0c97b5198656ea48359eaeed
- https://git.kernel.org/stable/c/945a9a8e448b65bec055d37eba58f711b39f66f0
- https://git.kernel.org/stable/c/ba7dd8a9686a61a34b3a7b922ce721378d4740d0
- https://git.kernel.org/stable/c/bacb37bdc2a21c8f7fdc83dcc0dea2f4ca1341fb
- https://git.kernel.org/stable/c/c02d2a91a85c4c4d05826cd1ea74a9b8d42e4280
- https://git.kernel.org/stable/c/f2f6e67522916f53ad8ccd4dbe68dcf76e9776e5
Modified: 2025-11-14
CVE-2022-49983
In the Linux kernel, the following vulnerability has been resolved:
udmabuf: Set the DMA mask for the udmabuf device (v2)
If the DMA mask is not set explicitly, the following warning occurs
when the userspace tries to access the dma-buf via the CPU as
reported by syzbot here:
WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188
__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Modules linked in:
CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted
5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0
83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45
31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00
RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408
RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f
R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002
R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000
FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/63d8c1933ed280717f934e2bc2edd869bb66f329
- https://git.kernel.org/stable/c/872875c9ecf8fa2e1d82bb2f2f1963f571aa8959
- https://git.kernel.org/stable/c/9e9fa6a9198b767b00f48160800128e83a038f9f
- https://git.kernel.org/stable/c/e658538c610c6047b3c9f552e73801894d9284b1
- https://git.kernel.org/stable/c/f2f6ea1a8da1317430a84701fc0170449ee88315
Modified: 2025-11-14
CVE-2022-49984
In the Linux kernel, the following vulnerability has been resolved: HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report It is possible for a malicious device to forgo submitting a Feature Report. The HID Steam driver presently makes no prevision for this and de-references the 'struct hid_report' pointer obtained from the HID devices without first checking its validity. Let's change that.
- https://git.kernel.org/stable/c/989560b6d9e00d99e07bc33067fa1c770994bf4d
- https://git.kernel.org/stable/c/c20d03b82a2e3ddbb555dad4d4f3374a9763222c
- https://git.kernel.org/stable/c/cd11d1a6114bd4bc6450ae59f6e110ec47362126
- https://git.kernel.org/stable/c/dc815761948ab5b8c94db6cb53c95103588f16ae
- https://git.kernel.org/stable/c/dee1e51b54794e90763e70a3c78f27ba4fa930ec
- https://git.kernel.org/stable/c/fa2b822d86be5b5ad54fe4fa2daca464e71ff90a
Modified: 2025-11-14
CVE-2022-49985
In the Linux kernel, the following vulnerability has been resolved:
bpf: Don't use tnum_range on array range checking for poke descriptors
Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which
is based on a customized syzkaller:
BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0
Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489
CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
Modified: 2025-11-14
CVE-2022-49986
In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following warning: [ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]---
- https://git.kernel.org/stable/c/46fcb0fc884db78a0384be92cc2a51927e6581b8
- https://git.kernel.org/stable/c/828f57ac75eaccd6607ee4d1468d34e983e32c68
- https://git.kernel.org/stable/c/b4c928ace9a123629eeb14ec5d7ee8f73e5ac668
- https://git.kernel.org/stable/c/b692c238ddfa61f00d97c4c1f021425d132ba96f
- https://git.kernel.org/stable/c/cd2a50d0a097a42b6de283377da98ff757505120
- https://git.kernel.org/stable/c/d957e7ffb2c72410bcc1a514153a46719255a5da
Modified: 2025-11-14
CVE-2022-49987
In the Linux kernel, the following vulnerability has been resolved: md: call __md_stop_writes in md_stop From the link [1], we can see raid1d was running even after the path raid_dtr -> md_stop -> __md_stop. Let's stop write first in destructor to align with normal md-raid to fix the KASAN issue. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a
- https://git.kernel.org/stable/c/0dd84b319352bb8ba64752d4e45396d8b13e6018
- https://git.kernel.org/stable/c/1678ca35b80a94d474fdc31e2497ce5d7ed52512
- https://git.kernel.org/stable/c/661c01b2181d9413c799127f13143583b69f20fd
- https://git.kernel.org/stable/c/690b5c90fd2d81fd1d2b6110fa36783232f6dce2
- https://git.kernel.org/stable/c/8e7fb19f1a744fd34e982633ced756fee0498ef7
- https://git.kernel.org/stable/c/a5a58fab556bfe618b4c9719eb85712d78c6cb10
- https://git.kernel.org/stable/c/f42a9819ba84bed2e609a4dff56af37063dcabdc
Modified: 2025-11-14
CVE-2022-49989
In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: fix error exit of privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the expected number of pages.
Modified: 2025-11-14
CVE-2022-49990
In the Linux kernel, the following vulnerability has been resolved: s390: fix double free of GS and RI CBs on fork() failure The pointers for guarded storage and runtime instrumentation control blocks are stored in the thread_struct of the associated task. These pointers are initially copied on fork() via arch_dup_task_struct() and then cleared via copy_thread() before fork() returns. If fork() happens to fail after the initial task dup and before copy_thread(), the newly allocated task and associated thread_struct memory are freed via free_task() -> arch_release_task_struct(). This results in a double free of the guarded storage and runtime info structs because the fields in the failed task still refer to memory associated with the source task. This problem can manifest as a BUG_ON() in set_freepointer() (with CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled) when running trinity syscall fuzz tests on s390x. To avoid this problem, clear the associated pointer fields in arch_dup_task_struct() immediately after the new task is copied. Note that the RI flag is still cleared in copy_thread() because it resides in thread stack memory and that is where stack info is copied.
- https://git.kernel.org/stable/c/13cccafe0edcd03bf1c841de8ab8a1c8e34f77d9
- https://git.kernel.org/stable/c/25a95303b9e513cd2978aacc385d06e6fec23d07
- https://git.kernel.org/stable/c/297ae7e87a87a001dd3dfeac1cb26a42fd929708
- https://git.kernel.org/stable/c/8195e065abf3df84eb0ad2987e76a40f21d1791c
- https://git.kernel.org/stable/c/cacd522e6652fbc2dc0cc6ae11c4e30782fef14b
- https://git.kernel.org/stable/c/fbdc482d43eda40a70de4b0155843d5472f6de62
Modified: 2025-11-14
CVE-2022-49991
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte In MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the page cache are installed in the ptes. But hugepage_add_new_anon_rmap is called for them mistakenly because they're not vm_shared. This will corrupt the page->mapping used by page cache code.
Modified: 2025-11-14
CVE-2022-49993
In the Linux kernel, the following vulnerability has been resolved: loop: Check for overflow while configuring loop The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset. loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h). The function directly copies offset from info to the device as follows (See line 980 of loop.c): lo->lo_offset = info->lo_offset; This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Thus, check for negative value during loop_set_status_from_info(). Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e
- https://git.kernel.org/stable/c/0455bef69028c65065f16bb04635591b2374249b
- https://git.kernel.org/stable/c/18e28817cb516b39de6281f6db9b0618b2cc7b42
- https://git.kernel.org/stable/c/6858933131d0dadac071c4d33335a9ea4b8e76cf
- https://git.kernel.org/stable/c/9be7fa7ead18a48940df7b59d993bbc8b9055c15
- https://git.kernel.org/stable/c/a217715338fd48f72114725aa7a40e484a781ca7
- https://git.kernel.org/stable/c/adf0112d9b8acb03485624220b4934f69bf13369
- https://git.kernel.org/stable/c/b40877b8562c5720d0a7fce20729f56b75a3dede
- https://git.kernel.org/stable/c/c490a0b5a4f36da3918181a8acdc6991d967c5f3
Modified: 2025-11-14
CVE-2022-49994
In the Linux kernel, the following vulnerability has been resolved: bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem The vmemmap pages is marked by kmemleak when allocated from memblock. Remove it from kmemleak when freeing the page. Otherwise, when we reuse the page, kmemleak may report such an error and then stop working. kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6be00000 (size 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace:
Modified: 2025-11-14
CVE-2022-49995
In the Linux kernel, the following vulnerability has been resolved: writeback: avoid use-after-free after removing device When a disk is removed, bdi_unregister gets called to stop further writeback and wait for associated delayed work to complete. However, wb_inode_writeback_end() may schedule bandwidth estimation dwork after this has completed, which can result in the timer attempting to access the just freed bdi_writeback. Fix this by checking if the bdi_writeback is alive, similar to when scheduling writeback work. Since this requires wb->work_lock, and wb_inode_writeback_end() may get called from interrupt, switch wb->work_lock to an irqsafe lock.
Modified: 2025-11-14
CVE-2022-49996
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix possible memory leak in btrfs_get_dev_args_from_path() In btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() can fail if the path is invalid. In this case, btrfs_get_dev_args_from_path() returns directly without freeing args->uuid and args->fsid allocated before, which causes memory leak. To fix these possible leaks, when btrfs_get_bdev_and_sb() fails, btrfs_put_dev_args_from_path() is called to clean up the memory.
Modified: 2025-11-14
CVE-2022-49997
In the Linux kernel, the following vulnerability has been resolved: net: lantiq_xrx200: restore buffer if memory allocation failed In a situation where memory allocation fails, an invalid buffer address is stored. When this descriptor is used again, the system panics in the build_skb() function when accessing memory.
Modified: 2025-11-14
CVE-2022-49998
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix locking in rxrpc's sendmsg
Fix three bugs in the rxrpc's sendmsg implementation:
(1) rxrpc_new_client_call() should release the socket lock when returning
an error from rxrpc_get_call_slot().
(2) rxrpc_wait_for_tx_window_intr() will return without the call mutex
held in the event that we're interrupted by a signal whilst waiting
for tx space on the socket or relocking the call mutex afterwards.
Fix this by: (a) moving the unlock/lock of the call mutex up to
rxrpc_send_data() such that the lock is not held around all of
rxrpc_wait_for_tx_window*() and (b) indicating to higher callers
whether we're return with the lock dropped. Note that this means
recvmsg() will not block on this call whilst we're waiting.
(3) After dropping and regaining the call mutex, rxrpc_send_data() needs
to go and recheck the state of the tx_pending buffer and the
tx_total_len check in case we raced with another sendmsg() on the same
call.
Thinking on this some more, it might make sense to have different locks for
sendmsg() and recvmsg(). There's probably no need to make recvmsg() wait
for sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating
that a call is dead before a sendmsg() to that call returns - but that can
currently happen anyway.
Without fix (2), something like the following can be induced:
WARNING: bad unlock balance detected!
5.16.0-rc6-syzkaller #0 Not tainted
-------------------------------------
syz-executor011/3597 is trying to release lock (&call->user_mutex) at:
[
Modified: 2025-11-14
CVE-2022-49999
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix space cache corruption and potential double allocations When testing space_cache v2 on a large set of machines, we encountered a few symptoms: 1. "unable to add free space :-17" (EEXIST) errors. 2. Missing free space info items, sometimes caught with a "missing free space info for X" error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter made it onto disk, the next reboot would hit the BUG_ON() in add_new_free_space(). 4. On some hosts with no on-disk corruption or error messages, the in-memory space cache (dumped with drgn) disagreed with the free space tree. All of these symptoms have the same underlying cause: a race between caching the free space for a block group and returning free space to the in-memory space cache for pinned extents causes us to double-add a free range to the space cache. This race exists when free space is cached from the free space tree (space_cache=v2) or the extent tree (nospace_cache, or space_cache=v1 if the cache needs to be regenerated). struct btrfs_block_group::last_byte_to_unpin and struct btrfs_block_group::progress are supposed to protect against this race, but commit d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") subtly broke this by allowing multiple transactions to be unpinning extents at the same time. Specifically, the race is as follows: 1. An extent is deleted from an uncached block group in transaction A. 2. btrfs_commit_transaction() is called for transaction A. 3. btrfs_run_delayed_refs() -> __btrfs_free_extent() runs the delayed ref for the deleted extent. 4. __btrfs_free_extent() -> do_free_extent_accounting() -> add_to_free_space_tree() adds the deleted extent back to the free space tree. 5. do_free_extent_accounting() -> btrfs_update_block_group() -> btrfs_cache_block_group() queues up the block group to get cached. block_group->progress is set to block_group->start. 6. btrfs_commit_transaction() for transaction A calls switch_commit_roots(). It sets block_group->last_byte_to_unpin to block_group->progress, which is block_group->start because the block group hasn't been cached yet. 7. The caching thread gets to our block group. Since the commit roots were already switched, load_free_space_tree() sees the deleted extent as free and adds it to the space cache. It finishes caching and sets block_group->progress to U64_MAX. 8. btrfs_commit_transaction() advances transaction A to TRANS_STATE_SUPER_COMMITTED. 9. fsync calls btrfs_commit_transaction() for transaction B. Since transaction A is already in TRANS_STATE_SUPER_COMMITTED and the commit is for fsync, it advances. 10. btrfs_commit_transaction() for transaction B calls switch_commit_roots(). This time, the block group has already been cached, so it sets block_group->last_byte_to_unpin to U64_MAX. 11. btrfs_commit_transaction() for transaction A calls btrfs_finish_extent_commit(), which calls unpin_extent_range() for the deleted extent. It sees last_byte_to_unpin set to U64_MAX (by transaction B!), so it adds the deleted extent to the space cache again! This explains all of our symptoms above: * If the sequence of events is exactly as described above, when the free space is re-added in step 11, it will fail with EEXIST. * If another thread reallocates the deleted extent in between steps 7 and 11, then step 11 will silently re-add that space to the space cache as free even though it is actually allocated. Then, if that space is allocated *again*, the free space tree will be corrupted (namely, the wrong item will be deleted). * If we don't catch this free space tree corr ---truncated---
Modified: 2025-11-14
CVE-2022-50000
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix stuck flows on cleanup due to pending work To clear the flow table on flow table free, the following sequence normally happens in order: 1) gc_step work is stopped to disable any further stats/del requests. 2) All flow table entries are set to teardown state. 3) Run gc_step which will queue HW del work for each flow table entry. 4) Waiting for the above del work to finish (flush). 5) Run gc_step again, deleting all entries from the flow table. 6) Flow table is freed. But if a flow table entry already has pending HW stats or HW add work step 3 will not queue HW del work (it will be skipped), step 4 will wait for the pending add/stats to finish, and step 5 will queue HW del work which might execute after freeing of the flow table. To fix the above, this patch flushes the pending work, then it sets the teardown flag to all flows in the flowtable and it forces a garbage collector run to queue work to remove the flows from hardware, then it flushes this new pending work and (finally) it forces another garbage collector run to remove the entry from the software flowtable. Stack trace: [47773.882335] BUG: KASAN: use-after-free in down_read+0x99/0x460 [47773.883634] Write of size 8 at addr ffff888103b45aa8 by task kworker/u20:6/543704 [47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 Not tainted 5.12.0-rc7+ #2 [47773.886745] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) [47773.888438] Workqueue: nf_ft_offload_del flow_offload_work_handler [nf_flow_table] [47773.889727] Call Trace: [47773.890214] dump_stack+0xbb/0x107 [47773.890818] print_address_description.constprop.0+0x18/0x140 [47773.892990] kasan_report.cold+0x7c/0xd8 [47773.894459] kasan_check_range+0x145/0x1a0 [47773.895174] down_read+0x99/0x460 [47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table] [47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table] [47773.913372] process_one_work+0x8ac/0x14e0 [47773.921325] [47773.921325] Allocated by task 592159: [47773.922031] kasan_save_stack+0x1b/0x40 [47773.922730] __kasan_kmalloc+0x7a/0x90 [47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct] [47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct] [47773.925207] tcf_action_init_1+0x45b/0x700 [47773.925987] tcf_action_init+0x453/0x6b0 [47773.926692] tcf_exts_validate+0x3d0/0x600 [47773.927419] fl_change+0x757/0x4a51 [cls_flower] [47773.928227] tc_new_tfilter+0x89a/0x2070 [47773.936652] [47773.936652] Freed by task 543704: [47773.937303] kasan_save_stack+0x1b/0x40 [47773.938039] kasan_set_track+0x1c/0x30 [47773.938731] kasan_set_free_info+0x20/0x30 [47773.939467] __kasan_slab_free+0xe7/0x120 [47773.940194] slab_free_freelist_hook+0x86/0x190 [47773.941038] kfree+0xce/0x3a0 [47773.941644] tcf_ct_flow_table_cleanup_work Original patch description and stack trace by Paul Blakey.
Modified: 2025-11-14
CVE-2022-50001
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tproxy: restrict to prerouting hook TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this. This fixes a crash (null dereference) when using tproxy from e.g. output.
- https://git.kernel.org/stable/c/0b21edf4cc13516716848e0a4fdf726aa2a62cd9
- https://git.kernel.org/stable/c/18bbc3213383a82b05383827f4b1b882e3f0a5a5
- https://git.kernel.org/stable/c/343fed6b0daeb528ae5c9d4d84d9ff763ac95619
- https://git.kernel.org/stable/c/83ef55c4281f1b4c6bd4457c2e96ccd1c9e80200
- https://git.kernel.org/stable/c/9a1d92cbeac3335fee99fa865b8c5b0f2e71a8f7
- https://git.kernel.org/stable/c/eaba3f9b672c3a3f820da8ee9584b9520674eafa
Modified: 2025-11-14
CVE-2022-50002
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READY Only set MLX5_LAG_FLAG_NDEVS_READY if both netdevices are registered. Doing so guarantees that both ldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev have valid pointers when MLX5_LAG_FLAG_NDEVS_READY is set. The core issue is asymmetry in setting MLX5_LAG_FLAG_NDEVS_READY and clearing it. Setting it is done wrongly when both ldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev are set; clearing it is done right when either of ldev->pf[i].netdev is cleared. Consider the following scenario: 1. PF0 loads and sets ldev->pf[MLX5_LAG_P0].dev to a valid pointer 2. PF1 loads and sets both ldev->pf[MLX5_LAG_P1].dev and ldev->pf[MLX5_LAG_P1].netdev with valid pointers. This results in MLX5_LAG_FLAG_NDEVS_READY is set. 3. PF0 is unloaded before setting dev->pf[MLX5_LAG_P0].netdev. MLX5_LAG_FLAG_NDEVS_READY remains set. Further execution of mlx5_do_bond() will result in null pointer dereference when calling mlx5_lag_is_multipath() This patch fixes the following call trace actually encountered: [ 1293.475195] BUG: kernel NULL pointer dereference, address: 00000000000009a8 [ 1293.478756] #PF: supervisor read access in kernel mode [ 1293.481320] #PF: error_code(0x0000) - not-present page [ 1293.483686] PGD 0 P4D 0 [ 1293.484434] Oops: 0000 [#1] SMP PTI [ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 Not tainted 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1 [ 1293.488039] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 1293.490836] Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core] [ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core] [ 1293.494044] Code: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8 [ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202 [ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000 [ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000 [ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c [ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0 [ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858 [ 1293.508753] FS: 0000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000 [ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0 [ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Modified: 2025-11-14
CVE-2022-50003
In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: prohibit usage of non-balanced queue id
Fix the following scenario:
1. ethtool -L $IFACE rx 8 tx 96
2. xdpsock -q 10 -t -z
Above refers to a case where user would like to attach XSK socket in
txonly mode at a queue id that does not have a corresponding Rx queue.
At this moment ice's XSK logic is tightly bound to act on a "queue pair",
e.g. both Tx and Rx queues at a given queue id are disabled/enabled and
both of them will get XSK pool assigned, which is broken for the presented
queue configuration. This results in the splat included at the bottom,
which is basically an OOB access to Rx ring array.
To fix this, allow using the ids only in scope of "combined" queues
reported by ethtool. However, logic should be rewritten to allow such
configurations later on, which would end up as a complete rewrite of the
control path, so let us go with this temporary fix.
[420160.558008] BUG: kernel NULL pointer dereference, address: 0000000000000082
[420160.566359] #PF: supervisor read access in kernel mode
[420160.572657] #PF: error_code(0x0000) - not-present page
[420160.579002] PGD 0 P4D 0
[420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI
[420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10
[420160.597893] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice]
[420160.616968] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85
[420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282
[420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8
[420160.655893] RDX: 0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000
[420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000
[420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a
[420160.683833] R13: 000000000000000a R14: 0000000000000000 R15: ffff888117611828
[420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000
[420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[420160.711783] CR2: 0000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0
[420160.721399] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[420160.740707] PKRU: 55555554
[420160.745960] Call Trace:
[420160.750962]
Modified: 2025-11-14
CVE-2022-50004
In the Linux kernel, the following vulnerability has been resolved:
xfrm: policy: fix metadata dst->dev xmit null pointer dereference
When we try to transmit an skb with metadata_dst attached (i.e. dst->dev
== NULL) through xfrm interface we can hit a null pointer dereference[1]
in xfrmi_xmit2() -> xfrm_lookup_with_ifid() due to the check for a
loopback skb device when there's no policy which dereferences dst->dev
unconditionally. Not having dst->dev can be interepreted as it not being
a loopback device, so just add a check for a null dst_orig->dev.
With this fix xfrm interface's Tx error counters go up as usual.
[1] net-next calltrace captured via netconsole:
BUG: kernel NULL pointer dereference, address: 00000000000000c0
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 1 PID: 7231 Comm: ping Kdump: loaded Not tainted 5.19.0+ #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014
RIP: 0010:xfrm_lookup_with_ifid+0x5eb/0xa60
Code: 8d 74 24 38 e8 26 a4 37 00 48 89 c1 e9 12 fc ff ff 49 63 ed 41 83 fd be 0f 85 be 01 00 00 41 be ff ff ff ff 45 31 ed 48 8b 03
Modified: 2025-11-14
CVE-2022-50005
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Fix use-after-free bugs caused by pn532_cmd_timeout When the pn532 uart device is detaching, the pn532_uart_remove() is called. But there are no functions in pn532_uart_remove() that could delete the cmd_timeout timer, which will cause use-after-free bugs. The process is shown below: (thread 1) | (thread 2) | pn532_uart_send_frame pn532_uart_remove | mod_timer(&pn532->cmd_timeout,...) ... | (wait a time) kfree(pn532) //FREE | pn532_cmd_timeout | pn532_uart_send_frame | pn532->... //USE This patch adds del_timer_sync() in pn532_uart_remove() in order to prevent the use-after-free bugs. What's more, the pn53x_unregister_nfc() is well synchronized, it sets nfc_dev->shutting_down to true and there are no syscalls could restart the cmd_timeout timer.
Modified: 2025-11-14
CVE-2022-50006
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2 fix problems with __nfs42_ssc_open A destination server while doing a COPY shouldn't accept using the passed in filehandle if its not a regular filehandle. If alloc_file_pseudo() has failed, we need to decrement a reference on the newly created inode, otherwise it leaks.
Modified: 2025-11-14
CVE-2022-50007
In the Linux kernel, the following vulnerability has been resolved: xfrm: fix refcount leak in __xfrm_policy_check() The issue happens on an error path in __xfrm_policy_check(). When the fetching process of the object `pols[1]` fails, the function simply returns 0, forgetting to decrement the reference count of `pols[0]`, which is incremented earlier by either xfrm_sk_policy_lookup() or xfrm_policy_lookup(). This may result in memory leaks. Fix it by decreasing the reference count of `pols[0]` in that path.
- https://git.kernel.org/stable/c/0769491a8acd3e85ca4c3f65080eac2c824262df
- https://git.kernel.org/stable/c/1305d7d4f35ca6f214a2d23b075aa6a924cff3be
- https://git.kernel.org/stable/c/18e6b6e2555c93f5ca09f2b85ef1fa025c8accea
- https://git.kernel.org/stable/c/26ad2398fe4984f4f6f930bcb3bc9047fa77265b
- https://git.kernel.org/stable/c/63da7a2bbf3f28094920e0b8a17d2571a9bd842d
- https://git.kernel.org/stable/c/8f94b933103ee1bda119543369cc18a1be5536db
- https://git.kernel.org/stable/c/9c9cb23e00ddf45679b21b4dacc11d1ae7961ebe
- https://git.kernel.org/stable/c/d66c052879791313f90c0584420f196a038fb8b8
Modified: 2025-11-14
CVE-2022-50008
In the Linux kernel, the following vulnerability has been resolved:
kprobes: don't call disarm_kprobe() for disabled kprobes
The assumption in __disable_kprobe() is wrong, and it could try to disarm
an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can
easily reproduce this issue.
1. Write 0 to /sys/kernel/debug/kprobes/enabled.
# echo 0 > /sys/kernel/debug/kprobes/enabled
2. Run execsnoop. At this time, one kprobe is disabled.
# /usr/share/bcc/tools/execsnoop &
[1] 2460
PCOMM PID PPID RET ARGS
# cat /sys/kernel/debug/kprobes/list
ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]
ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes
kprobes_all_disarmed to false but does not arm the disabled kprobe.
# echo 1 > /sys/kernel/debug/kprobes/enabled
# cat /sys/kernel/debug/kprobes/list
ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]
ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the
disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().
# fg
/usr/share/bcc/tools/execsnoop
^C
Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses
some cleanups and leaves the aggregated kprobe in the hash table. Then,
__unregister_trace_kprobe() initialises tk->rp.kp.list and creates an
infinite loop like this.
aggregated kprobe.list -> kprobe.list -.
^ |
'.__.'
In this situation, these commands fall into the infinite loop and result
in RCU stall or soft lockup.
cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the
infinite loop with RCU.
/usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex,
and __get_valid_kprobe() is stuck in
the loop.
To avoid the issue, make sure we don't call disarm_kprobe() for disabled
kprobes.
[0]
Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2)
WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)
Modules linked in: ena
CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28
Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017
RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)
Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94
RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001
RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff
RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff
R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40
R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000
FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/19cd630712e7c13a3dedfc6986a9b983fed6fd98
- https://git.kernel.org/stable/c/55c7a91527343d2e0b5647cc308c6e04ddd2aa52
- https://git.kernel.org/stable/c/6f3c1bc22fc2165461883f506b4d2c3594bd7137
- https://git.kernel.org/stable/c/744b0d3080709a172f0408aedabd1cedd24c2ee6
- https://git.kernel.org/stable/c/9c80e79906b4ca440d09e7f116609262bb747909
- https://git.kernel.org/stable/c/b474ff1b20951f1eac75d100a93861e6da2b522b
- https://git.kernel.org/stable/c/bc3188d8a3b8c08c306a4c851ddb2c92ba4599ca
- https://git.kernel.org/stable/c/fc91d2db55acdaf0c0075b624e572d3520ca3bc3
Modified: 2025-11-14
CVE-2022-50009
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix null-ptr-deref in f2fs_get_dnode_of_data
There is issue as follows when test f2fs atomic write:
F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
F2FS-fs (loop0): invalid crc_offset: 0
F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=1, run fsck to fix.
F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=2, run fsck to fix.
==================================================================
BUG: KASAN: null-ptr-deref in f2fs_get_dnode_of_data+0xac/0x16d0
Read of size 8 at addr 0000000000000028 by task rep/1990
CPU: 4 PID: 1990 Comm: rep Not tainted 5.19.0-rc6-next-20220715 #266
Call Trace:
Modified: 2025-11-14
CVE-2022-50010
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: i740fb: Check the argument of i740_calc_vclk() Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug. If the user provides an improper 'pixclock' value that makes the argumet of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a divide-by-zero bug in: drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX))); The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline] RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline] RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of i740_calc_vclk() first.
- https://git.kernel.org/stable/c/2b7f559152a33c55f51b569b22efbe5e24886798
- https://git.kernel.org/stable/c/40bf722f8064f50200b8c4f8946cd625b441dda9
- https://git.kernel.org/stable/c/4b20c61365140d432dee7da7aa294215e7b900d9
- https://git.kernel.org/stable/c/59cefb583c984c0da8cf21a4c57d26d5a20dff5c
- https://git.kernel.org/stable/c/656689cb03ada4650016c153346939a1c334b1ae
- https://git.kernel.org/stable/c/d2d375eb68b4b8de6ea7460483a26fa9de56b443
- https://git.kernel.org/stable/c/e740e787f06671455b59d1e498c9945f7b4e7b3b
- https://git.kernel.org/stable/c/f350812e2d15278f1d867eeb997407782234fb3c
Modified: 2025-11-14
CVE-2022-50011
In the Linux kernel, the following vulnerability has been resolved: venus: pm_helpers: Fix warning in OPP during probe Fix the following WARN triggered during Venus driver probe on 5.19.0-rc8-next-20220728: WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610 Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+) videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5 phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6 CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dev_pm_opp_set_config+0x49c/0x610 lr : dev_pm_opp_set_config+0x58/0x610 sp : ffff8000093c3710 x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00 x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810 x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810 x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000 x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858 x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000 x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0 x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640 x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008 x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860 Call trace: dev_pm_opp_set_config+0x49c/0x610 devm_pm_opp_set_config+0x18/0x70 vcodec_domains_get+0xb8/0x1638 [venus_core] core_get_v4+0x1d8/0x218 [venus_core] venus_probe+0xf4/0x468 [venus_core] platform_probe+0x68/0xd8 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0xf0 __driver_attach+0x70/0x120 bus_for_each_dev+0x70/0xc0 driver_attach+0x24/0x30 bus_add_driver+0x150/0x200 driver_register+0x64/0x120 __platform_driver_register+0x28/0x38 qcom_venus_driver_init+0x24/0x1000 [venus_core] do_one_initcall+0x54/0x1c8 do_init_module+0x44/0x1d0 load_module+0x16c8/0x1aa0 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x20/0x30 invoke_syscall+0x44/0x108 el0_svc_common.constprop.0+0xcc/0xf0 do_el0_svc+0x2c/0xb8 el0_svc+0x2c/0x88 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x18c/0x190 qcom-venus: probe of aa00000.video-codec failed with error -16 The fix is re-ordering the code related to OPP core. The OPP core expects all configuration options to be provided before the OPP table is added.
Modified: 2025-12-23
CVE-2022-50012
In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Init jump labels before parse_early_param() On 64-bit, calling jump_label_init() in setup_feature_keys() is too late because static keys may be used in subroutines of parse_early_param() which is again subroutine of early_init_devtree(). For example booting with "threadirqs": static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0x120 Call Trace: static_key_enable_cpuslocked+0xf8/0x120 (unreliable) static_key_enable+0x30/0x50 setup_forced_irqthreads+0x28/0x40 do_early_param+0xa0/0x108 parse_args+0x290/0x4e0 parse_early_options+0x48/0x5c parse_early_param+0x58/0x84 early_init_devtree+0xd4/0x518 early_setup+0xb4/0x214 So call jump_label_init() just before parse_early_param() in early_init_devtree(). [mpe: Add call trace to change log and minor wording edits.]
Modified: 2025-11-14
CVE-2022-50013
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()
As Dipanjan Das
- https://git.kernel.org/stable/c/141170b759e03958f296033bb7001be62d1d363b
- https://git.kernel.org/stable/c/29e734ec33ae4bd7de4018fb0fb0eec808c36b92
- https://git.kernel.org/stable/c/43ce0a0bda2c54dad91d5a1943554eed9e050f55
- https://git.kernel.org/stable/c/5a01e45b925a0bc9718eccd33e5920f1a4e44caf
- https://git.kernel.org/stable/c/800ba8979111184d5194f4233cc83afe683efc54
- https://git.kernel.org/stable/c/fbfad62b29e9f8f1c1026a806c9e064ec2a7c342
Modified: 2025-11-14
CVE-2022-50014
In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW Ever since the Dirty COW (CVE-2016-5195) security issue happened, we know that FOLL_FORCE can be possibly dangerous, especially if there are races that can be exploited by user space. Right now, it would be sufficient to have some code that sets a PTE of a R/O-mapped shared page dirty, in order for it to erroneously become writable by FOLL_FORCE. The implications of setting a write-protected PTE dirty might not be immediately obvious to everyone. And in fact ever since commit 9ae0f87d009c ("mm/shmem: unconditionally set pte dirty in mfill_atomic_install_pte"), we can use UFFDIO_CONTINUE to map a shmem page R/O while marking the pte dirty. This can be used by unprivileged user space to modify tmpfs/shmem file content even if the user does not have write permissions to the file, and to bypass memfd write sealing -- Dirty COW restricted to tmpfs/shmem (CVE-2022-2590). To fix such security issues for good, the insight is that we really only need that fancy retry logic (FOLL_COW) for COW mappings that are not writable (!VM_WRITE). And in a COW mapping, we really only broke COW if we have an exclusive anonymous page mapped. If we have something else mapped, or the mapped anonymous page might be shared (!PageAnonExclusive), we have to trigger a write fault to break COW. If we don't find an exclusive anonymous page when we retry, we have to trigger COW breaking once again because something intervened. Let's move away from this mandatory-retry + dirty handling and rely on our PageAnonExclusive() flag for making a similar decision, to use the same COW logic as in other kernel parts here as well. In case we stumble over a PTE in a COW mapping that does not map an exclusive anonymous page, COW was not properly broken and we have to trigger a fake write-fault to break COW. Just like we do in can_change_pte_writable() added via commit 64fe24a3e05e ("mm/mprotect: try avoiding write faults for exclusive anonymous pages when changing protection") and commit 76aefad628aa ("mm/mprotect: fix soft-dirty check in can_change_pte_writable()"), take care of softdirty and uffd-wp manually. For example, a write() via /proc/self/mem to a uffd-wp-protected range has to fail instead of silently granting write access and bypassing the userspace fault handler. Note that FOLL_FORCE is not only used for debug access, but also triggered by applications without debug intentions, for example, when pinning pages via RDMA. This fixes CVE-2022-2590. Note that only x86_64 and aarch64 are affected, because only those support CONFIG_HAVE_ARCH_USERFAULTFD_MINOR. Fortunately, FOLL_COW is no longer required to handle FOLL_FORCE. So let's just get rid of it. Thanks to Nadav Amit for pointing out that the pte_dirty() check in FOLL_FORCE code is problematic and might be exploitable. Note 1: We don't check for the PTE being dirty because it doesn't matter for making a "was COWed" decision anymore, and whoever modifies the page has to set the page dirty either way. Note 2: Kernels before extended uffd-wp support and before PageAnonExclusive (< 5.19) can simply revert the problematic commit instead and be safe regarding UFFDIO_CONTINUE. A backport to v5.19 requires minor adjustments due to lack of vma_soft_dirty_enabled().
Modified: 2025-11-14
CVE-2022-50015
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot It is not yet clear, but it is possible to create a firmware so broken that it will send a reply message before a FW_READY message (it is not yet clear if FW_READY will arrive later). Since the reply_data is allocated only after the FW_READY message, this will lead to a NULL pointer dereference if not filtered out. The issue was reported with IPC4 firmware but the same condition is present for IPC3.
Modified: 2025-11-14
CVE-2022-50016
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: cnl: Do not process IPC reply before firmware boot It is not yet clear, but it is possible to create a firmware so broken that it will send a reply message before a FW_READY message (it is not yet clear if FW_READY will arrive later). Since the reply_data is allocated only after the FW_READY message, this will lead to a NULL pointer dereference if not filtered out. The issue was reported with IPC4 firmware but the same condition is present for IPC3.
Modified: 2025-11-13
CVE-2022-50017
In the Linux kernel, the following vulnerability has been resolved: mips: cavium-octeon: Fix missing of_node_put() in octeon2_usb_clocks_start We should call of_node_put() for the reference 'uctl_node' returned by of_get_parent() which will increase the refcount. Otherwise, there will be a refcount leak bug.
- https://git.kernel.org/stable/c/1b49707df679b5510ed06ace7378ddc2aec5c3fb
- https://git.kernel.org/stable/c/1e39037e44d7fa3728686af146f9285ea197097d
- https://git.kernel.org/stable/c/7822d994eb9579a1df4cdbc315db090a041e50f3
- https://git.kernel.org/stable/c/7a9f743ceead60ed454c46fbc3085ee9a79cbebb
- https://git.kernel.org/stable/c/9d1afa0169a84dcd5b79901d792edeb8403684ab
- https://git.kernel.org/stable/c/a80016c40cc797c7f3e5a705b8e12ae447280335
- https://git.kernel.org/stable/c/af87a469695dc2b2419b2fdff0bf41db5265b325
- https://git.kernel.org/stable/c/c06166a484eece51916dd700a870e53356b7e1bc
Modified: 2025-11-13
CVE-2022-50019
In the Linux kernel, the following vulnerability has been resolved: tty: serial: Fix refcount leak bug in ucc_uart.c In soc_info(), of_find_node_by_type() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/17c32546166d8a7d2579c4b57c8b16241f94a66b
- https://git.kernel.org/stable/c/59bc4c19d53bdac61ec952c01c6e864f5f0f8367
- https://git.kernel.org/stable/c/81939c4fbc2d5c754d0f1c1f05149d4b70d751ed
- https://git.kernel.org/stable/c/8245e7d1d7f75a9255ad1e8146752e5051d528b8
- https://git.kernel.org/stable/c/ca3fc1c38e4253bc019881301a28ea60b8b0bca3
- https://git.kernel.org/stable/c/d24d7bb2cd947676f9b71fb944d045e09b8b282f
- https://git.kernel.org/stable/c/ec56f886f3bf0f15f7a3844d4c025e165b8e8de7
- https://git.kernel.org/stable/c/f6ed634eedb1a8a6a8cb110a7695c7abb70ffcbf
Modified: 2025-12-23
CVE-2022-50020
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid resizing to a partial cluster size This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUG_ON and leaves the fs with a corrupted in-memory superblock.
- https://git.kernel.org/stable/c/0082e99a9074ff88eff729c70c93454c8588d8e1
- https://git.kernel.org/stable/c/69cb8e9d8cd97cdf5e293b26d70a9dee3e35e6bd
- https://git.kernel.org/stable/c/72b850a2a996f72541172e7cf686d54a2b29bcd8
- https://git.kernel.org/stable/c/7bdfb01fc5f6b3696728aeb527c50386e0ee09a1
- https://git.kernel.org/stable/c/80288883294c5b4ed18bae0d8bd9c4a12f297074
- https://git.kernel.org/stable/c/a6805b3dcf5cd41f2ae3a03dca43411135b99849
Modified: 2025-11-13
CVE-2022-50021
In the Linux kernel, the following vulnerability has been resolved:
ext4: block range must be validated before use in ext4_mb_clear_bb()
Block range to free is validated in ext4_free_blocks() using
ext4_inode_block_valid() and then it's passed to ext4_mb_clear_bb().
However in some situations on bigalloc file system the range might be
adjusted after the validation in ext4_free_blocks() which can lead to
troubles on corrupted file systems such as one found by syzkaller that
resulted in the following BUG
kernel BUG at fs/ext4/ext4.h:3319!
PREEMPT SMP NOPTI
CPU: 28 PID: 4243 Comm: repro Kdump: loaded Not tainted 5.19.0-rc6+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
RIP: 0010:ext4_free_blocks+0x95e/0xa90
Call Trace:
Modified: 2025-11-13
CVE-2022-50022
In the Linux kernel, the following vulnerability has been resolved: drivers:md:fix a potential use-after-free bug In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and may cause sh to be released. However, sh is subsequently used in lines 2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an use-after-free bug. It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of the function.
- https://git.kernel.org/stable/c/09cf99bace7789d91caa8d10fbcfc8b2fb35857f
- https://git.kernel.org/stable/c/104212471b1c1817b311771d817fb692af983173
- https://git.kernel.org/stable/c/5d8325fd15892c8ab1146edc1d7ed8463de39636
- https://git.kernel.org/stable/c/7470a4314b239e9a9580f248fdf4c9a92805490e
- https://git.kernel.org/stable/c/d9b94c3ace549433de8a93eeb27b0391fc8ac406
- https://git.kernel.org/stable/c/e5b3dd2d92c4511e81f6e4ec9c5bb7ad25e03d13
- https://git.kernel.org/stable/c/eb3a4f73f43f839df981dda5859e8e075067a360
- https://git.kernel.org/stable/c/f5d46f1b47f65da1faf468277b261eb78c8e25b5
Modified: 2025-11-13
CVE-2022-50023
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-axi-dmac: ignore interrupt if no descriptor If the channel has no descriptor and the interrupt is raised then the kernel will OOPS. Check the result of vchan_next_desc() in the handler axi_chan_block_xfer_complete() to avoid the error happening.
Modified: 2025-11-13
CVE-2022-50024
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-axi-dmac: do not print NULL LLI during error During debugging we have seen an issue where axi_chan_dump_lli() is passed a NULL LLI pointer which ends up causing an OOPS due to trying to get fields from it. Simply print NULL LLI and exit to avoid this.
Modified: 2025-11-13
CVE-2022-50025
In the Linux kernel, the following vulnerability has been resolved: cxl: Fix a memory leak in an error handling path A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the error handling path of afu_allocate_irqs().
- https://git.kernel.org/stable/c/3a15b45b5454da862376b5d69a4967f5c6fa1368
- https://git.kernel.org/stable/c/4be138bcd6d68cec0ce47051b117541061f5141a
- https://git.kernel.org/stable/c/6544ff559315498ad6c0a311359ca44987f9ca07
- https://git.kernel.org/stable/c/695af60af755873399ce01cb97176768828bc1fd
- https://git.kernel.org/stable/c/89d51dc6878c47b6400922fac21b6a33f9d1a588
- https://git.kernel.org/stable/c/addff638c41753639368c252d0c5ba0d8fe9ed97
- https://git.kernel.org/stable/c/c2557780ee7818b701681c226fa4cb7c0b171665
- https://git.kernel.org/stable/c/c2c7a29f99788e9e5dfe41d16868ea33da7cc235
Modified: 2025-11-13
CVE-2022-50026
In the Linux kernel, the following vulnerability has been resolved: habanalabs/gaudi: fix shift out of bounds When validating NIC queues, queue offset calculation must be performed only for NIC queues.
Modified: 2025-11-13
CVE-2022-50027
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE There is no corresponding free routine if lpfc_sli4_issue_wqe fails to issue the CMF WQE in lpfc_issue_cmf_sync_wqe. If ret_val is non-zero, then free the iocbq request structure.
Modified: 2025-11-13
CVE-2022-50028
In the Linux kernel, the following vulnerability has been resolved: gadgetfs: ep_io - wait until IRQ finishes after usb_ep_queue() if wait_for_completion_interruptible() is interrupted we need to wait until IRQ gets finished. Otherwise complete() from epio_complete() can corrupt stack.
- https://git.kernel.org/stable/c/04cb742d4d8f30dc2e83b46ac317eec09191c68e
- https://git.kernel.org/stable/c/118d967ce00a3d128bf731b35e4e2cb0facf5f00
- https://git.kernel.org/stable/c/2b06d5d97c0e067108a122986767731d40742138
- https://git.kernel.org/stable/c/67a4874461422e633236a0286a01b483cd647113
- https://git.kernel.org/stable/c/77040efe59a141286d090c8a0d37c65a355a1832
- https://git.kernel.org/stable/c/94aadba8d000d5de56af4ce8da3f334f21bf7a79
- https://git.kernel.org/stable/c/9ac14f973cb91f0c01776517e6d50981f32b8038
- https://git.kernel.org/stable/c/ca06b4cde54f8ec8be3aa53fd339bd56e62c12b3
Modified: 2025-11-13
CVE-2022-50029
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: ipq8074: dont disable gcc_sleep_clk_src Once the usb sleep clocks are disabled, clock framework is trying to disable the sleep clock source also. However, it seems that it cannot be disabled and trying to do so produces: [ 245.436390] ------------[ cut here ]------------ [ 245.441233] gcc_sleep_clk_src status stuck at 'on' [ 245.441254] WARNING: CPU: 2 PID: 223 at clk_branch_wait+0x130/0x140 [ 245.450435] Modules linked in: xhci_plat_hcd xhci_hcd dwc3 dwc3_qcom leds_gpio [ 245.456601] CPU: 2 PID: 223 Comm: sh Not tainted 5.18.0-rc4 #215 [ 245.463889] Hardware name: Xiaomi AX9000 (DT) [ 245.470050] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 245.474307] pc : clk_branch_wait+0x130/0x140 [ 245.481073] lr : clk_branch_wait+0x130/0x140 [ 245.485588] sp : ffffffc009f2bad0 [ 245.489838] x29: ffffffc009f2bad0 x28: ffffff8003e6c800 x27: 0000000000000000 [ 245.493057] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800226ef20 [ 245.500175] x23: ffffffc0089ff550 x22: 0000000000000000 x21: ffffffc008476ad0 [ 245.507294] x20: 0000000000000000 x19: ffffffc00965ac70 x18: fffffffffffc51a7 [ 245.514413] x17: 68702e3030303837 x16: 3a6d726f6674616c x15: ffffffc089f2b777 [ 245.521531] x14: ffffffc0095c9d18 x13: 0000000000000129 x12: 0000000000000129 [ 245.528649] x11: 00000000ffffffea x10: ffffffc009621d18 x9 : 0000000000000001 [ 245.535767] x8 : 0000000000000001 x7 : 0000000000017fe8 x6 : 0000000000000001 [ 245.542885] x5 : ffffff803fdca6d8 x4 : 0000000000000000 x3 : 0000000000000027 [ 245.550002] x2 : 0000000000000027 x1 : 0000000000000023 x0 : 0000000000000026 [ 245.557122] Call trace: [ 245.564229] clk_branch_wait+0x130/0x140 [ 245.566490] clk_branch2_disable+0x2c/0x40 [ 245.570656] clk_core_disable+0x60/0xb0 [ 245.574561] clk_core_disable+0x68/0xb0 [ 245.578293] clk_disable+0x30/0x50 [ 245.582113] dwc3_qcom_remove+0x60/0xc0 [dwc3_qcom] [ 245.585588] platform_remove+0x28/0x60 [ 245.590361] device_remove+0x4c/0x80 [ 245.594179] device_release_driver_internal+0x1dc/0x230 [ 245.597914] device_driver_detach+0x18/0x30 [ 245.602861] unbind_store+0xec/0x110 [ 245.607027] drv_attr_store+0x24/0x40 [ 245.610847] sysfs_kf_write+0x44/0x60 [ 245.614405] kernfs_fop_write_iter+0x128/0x1c0 [ 245.618052] new_sync_write+0xc0/0x130 [ 245.622391] vfs_write+0x1d4/0x2a0 [ 245.626123] ksys_write+0x58/0xe0 [ 245.629508] __arm64_sys_write+0x1c/0x30 [ 245.632895] invoke_syscall.constprop.0+0x5c/0x110 [ 245.636890] do_el0_svc+0xa0/0x150 [ 245.641488] el0_svc+0x18/0x60 [ 245.644872] el0t_64_sync_handler+0xa4/0x130 [ 245.647914] el0t_64_sync+0x174/0x178 [ 245.652340] ---[ end trace 0000000000000000 ]--- So, add CLK_IS_CRITICAL flag to the clock so that the kernel won't try to disable the sleep clock.
- https://git.kernel.org/stable/c/17d58499dc9c7e059dab7d170e9bae1e7e9c561b
- https://git.kernel.org/stable/c/1bf7305e79aab095196131bdc87a97796e0e3fac
- https://git.kernel.org/stable/c/38cee0d2b65eed42a44052de1bfdc0177b6c3f05
- https://git.kernel.org/stable/c/4203b76abe539f3cac258d4cf1e16e2dd95ea60f
- https://git.kernel.org/stable/c/459411b9f0180e3f382d7abfa3028dd3285984c3
- https://git.kernel.org/stable/c/6b90ab952401bd6c1a321dcfc0e0df080f2bc905
- https://git.kernel.org/stable/c/d401611a93b332914cf91eb9bc0b63fa1bdc17e9
Modified: 2025-11-13
CVE-2022-50030
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input Malformed user input to debugfs results in buffer overflow crashes. Adapt input string lengths to fit within internal buffers, leaving space for NULL terminators.
- https://git.kernel.org/stable/c/2d544e9d19c109dfe34b3dc1253a8b2971abe060
- https://git.kernel.org/stable/c/927907f1cbb3408cadde637fccfc17bb6b10a87d
- https://git.kernel.org/stable/c/b92506dc51f81741eb26609175ac206c20f06e0a
- https://git.kernel.org/stable/c/c29a4baaad38a332c0ae480cf6d6c5bf75ac1828
- https://git.kernel.org/stable/c/f8191d40aa612981ce897e66cda6a88db8df17bb
Modified: 2025-11-13
CVE-2022-50032
In the Linux kernel, the following vulnerability has been resolved: usb: renesas: Fix refcount leak bug In usbhs_rza1_hardware_init(), of_find_node_by_name() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/36b18b777dece704b7c2e9e7947ca41a9b0fb009
- https://git.kernel.org/stable/c/5c4b699193eba51f1bbf462d758d66f545fddd35
- https://git.kernel.org/stable/c/9790a5a4f07f38a5add85ec58c44797d3a7c3677
- https://git.kernel.org/stable/c/9d6d5303c39b8bc182475b22f45504106a07f086
- https://git.kernel.org/stable/c/cfa8f707a58d68b2341a9dd0b33cf048f0628b4d
- https://git.kernel.org/stable/c/fbdbd61a36d887e00114321c6758e359e9573a8e
Modified: 2025-11-13
CVE-2022-50033
In the Linux kernel, the following vulnerability has been resolved: usb: host: ohci-ppc-of: Fix refcount leak bug In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0334d23c56ecf1ee1563bb83e29cc5a51ed7fb4e
- https://git.kernel.org/stable/c/0fc62bbc95319bbd330e3645afc7c286acec9ef8
- https://git.kernel.org/stable/c/403132881e66db7aa98b55c6655daedd80d407fd
- https://git.kernel.org/stable/c/40a959d7042bb7711e404ad2318b30e9f92c6b9b
- https://git.kernel.org/stable/c/c5c5bd5cdcc6dc9f75f53d1c89af463d39a2bb96
- https://git.kernel.org/stable/c/cb5dd65e889163e723df1c2f02288cc527a57785
- https://git.kernel.org/stable/c/ec583e300aee9f152a64911445092d18e1c36729
- https://git.kernel.org/stable/c/fe6fe64403710287f0ae61a516954d8a4f7c9e3f
Modified: 2025-11-13
CVE-2022-50034
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3 fix use-after-free at workaround 2 BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xac cdns3_wa2_remove_old_request() { ... kfree(priv_req->request.buf); cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ^^^ use after free ... } cdns3_gadget_ep_free_request() free the space pointed by priv_req, but priv_req is used in the following list_del_init(). This patch move list_del_init() before cdns3_gadget_ep_free_request().
- https://git.kernel.org/stable/c/6d7ac60098b206d0472475b666cb09d556bec03d
- https://git.kernel.org/stable/c/6fd50446e7c9a98b4bcf96815f5c9602a16ea472
- https://git.kernel.org/stable/c/7d602f30149a117eea260208b1661bc404c21dfd
- https://git.kernel.org/stable/c/c3c1dbad3a2db32ecf371c97f2058491b8ba0f9a
- https://git.kernel.org/stable/c/e65d9b7147d7be3504893ca7dfb85286bda83d40
Modified: 2025-11-13
CVE-2022-50036
In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: dsi: Prevent underflow when computing packet sizes Currently, the packet overhead is subtracted using unsigned arithmetic. With a short sync pulse, this could underflow and wrap around to near the maximal u16 value. Fix this by using signed subtraction. The call to max() will correctly handle any negative numbers that are produced. Apply the same fix to the other timings, even though those subtractions are less likely to underflow.
Modified: 2025-11-13
CVE-2022-50038
In the Linux kernel, the following vulnerability has been resolved: drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors() In this function, there are two refcount leak bugs: (1) when breaking out of for_each_endpoint_of_node(), we need call the of_node_put() for the 'ep'; (2) we should call of_node_put() for the reference returned by of_graph_get_remote_port() when it is not used anymore.
- https://git.kernel.org/stable/c/3aa710e96747c8b4e52ba12ffe09edcb2755897c
- https://git.kernel.org/stable/c/6a758f0ba11699837af9e1a0f7cbac6ef765a23e
- https://git.kernel.org/stable/c/8dec38e19f6928235d4009ce55f7add8af34e5c7
- https://git.kernel.org/stable/c/91b3c8dbe898df158fd2a84675f3a284ff6666f7
- https://git.kernel.org/stable/c/d58ef256781398ad115aef44de0a02ad27ea6c3a
- https://git.kernel.org/stable/c/fc1fc2abfcb9235d0ece9a4d858426fb617cfa66
- https://git.kernel.org/stable/c/fe71d84c1a6c0d54657431e8eeaefc9d24895304
Modified: 2025-11-13
CVE-2022-50039
In the Linux kernel, the following vulnerability has been resolved: stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove() Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove paths") removed this clk_disable_unprepare() This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock handling on remove path") which removed this clk_disable_unprepare() because: " While unloading the dwmac-intel driver, clk_disable_unprepare() is being called twice in stmmac_dvr_remove() and intel_eth_pci_remove(). This causes kernel panic on the second call. " However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management for gmac driver") has updated stmmac_dvr_remove() which do not call clk_disable_unprepare() anymore. So this call should now be called from intel_eth_pci_remove().
Modified: 2025-11-13
CVE-2022-50040
In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regions() If an error occurs in dsa_devlink_region_create(), then 'priv->regions' array will be accessed by negative index '-1'. Found by Linux Verification Center (linuxtesting.org) with SVACE.
Modified: 2025-11-13
CVE-2022-50041
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix call trace with null VSI during VF reset
During stress test with attaching and detaching VF from KVM and
simultaneously changing VFs spoofcheck and trust there was a
call trace in ice_reset_vf that VF's VSI is null.
[145237.352797] WARNING: CPU: 46 PID: 840629 at drivers/net/ethernet/intel/ice/ice_vf_lib.c:508 ice_reset_vf+0x3d6/0x410 [ice]
[145237.352851] Modules linked in: ice(E) vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio iavf dm_mod xt_CHECKSUM xt_MASQUERADE
xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun
bridge stp llc sunrpc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iTCO_wdt iTC
O_vendor_support irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl ipmi_si intel_cstate ipmi_devintf joydev intel_uncore m
ei_me ipmi_msghandler i2c_i801 pcspkr mei lpc_ich ioatdma i2c_smbus acpi_pad acpi_power_meter ip_tables xfs libcrc32c i2c_algo_bit drm_sh
mem_helper drm_kms_helper sd_mod t10_pi crc64_rocksoft syscopyarea crc64 sysfillrect sg sysimgblt fb_sys_fops drm i40e ixgbe ahci libahci
libata crc32c_intel mdio dca wmi fuse [last unloaded: ice]
[145237.352917] CPU: 46 PID: 840629 Comm: kworker/46:2 Tainted: G S W I E 5.19.0-rc6+ #24
[145237.352921] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
[145237.352923] Workqueue: ice ice_service_task [ice]
[145237.352948] RIP: 0010:ice_reset_vf+0x3d6/0x410 [ice]
[145237.352984] Code: 30 ec f3 cc e9 28 fd ff ff 0f b7 4b 50 48 c7 c2 48 19 9c c0 4c 89 ee 48 c7 c7 30 fe 9e c0 e8 d1 21 9d cc 31 c0 e9 a
9 fe ff ff <0f> 0b b8 ea ff ff ff e9 c1 fc ff ff 0f 0b b8 fb ff ff ff e9 91 fe
[145237.352987] RSP: 0018:ffffb453e257fdb8 EFLAGS: 00010246
[145237.352990] RAX: ffff8bd0040181c0 RBX: ffff8be68db8f800 RCX: 0000000000000000
[145237.352991] RDX: 000000000000ffff RSI: 0000000000000000 RDI: ffff8be68db8f800
[145237.352993] RBP: ffff8bd0040181c0 R08: 0000000000001000 R09: ffff8bcfd520e000
[145237.352995] R10: 0000000000000000 R11: 00008417b5ab0bc0 R12: 0000000000000005
[145237.352996] R13: ffff8bcee061c0d0 R14: ffff8bd004019640 R15: 0000000000000000
[145237.352998] FS: 0000000000000000(0000) GS:ffff8be5dfb00000(0000) knlGS:0000000000000000
[145237.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[145237.353002] CR2: 00007fd81f651d68 CR3: 0000001a0fe10001 CR4: 00000000001726e0
[145237.353003] Call Trace:
[145237.353008]
Modified: 2025-11-13
CVE-2022-50042
In the Linux kernel, the following vulnerability has been resolved: net: genl: fix error path memory leak in policy dumping If construction of the array of policies fails when recording non-first policy we need to unwind. netlink_policy_dump_add_policy() itself also needs fixing as it currently gives up on error without recording the allocated pointer in the pstate pointer.
Modified: 2025-11-13
CVE-2022-50043
In the Linux kernel, the following vulnerability has been resolved: net: fix potential refcount leak in ndisc_router_discovery() The issue happens on specific paths in the function. After both the object `rt` and `neigh` are grabbed successfully, when `lifetime` is nonzero but the metric needs change, the function just deletes the route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh` again if above conditions hold. The function simply overwrite `neigh` if succeeds or returns if fails, without decreasing the reference count of previous `neigh`. This may result in memory leaks. Fix it by decrementing the reference count of `neigh` in place.
Modified: 2025-11-13
CVE-2022-50044
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: start MHI channel after endpoit creation MHI channel may generates event/interrupt right after enabling. It may leads to 2 race conditions issues. 1) Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return; Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at this moment. In this situation qrtr-ns will be unable to enumerate services in device. --------------------------------------------------------------- 2) Such event may come at the moment after dev_set_drvdata() and before qrtr_endpoint_register(). In this case kernel will panic with accessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd); Because endpoint is not created yet. -------------------------------------------------------------- So move mhi_prepare_for_transfer_autoqueue after endpoint creation to fix it.
Modified: 2025-11-13
CVE-2022-50046
In the Linux kernel, the following vulnerability has been resolved: net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change() The issue happens on some error handling paths. When the function fails to grab the object `xprt`, it simply returns 0, forgetting to decrease the reference count of another object `xps`, which is increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount leaks. Also, the function forgets to check whether `xps` is valid before using it, which may result in NULL-dereferencing issues. Fix it by adding proper error handling code when either `xprt` or `xps` is NULL.
Modified: 2025-11-13
CVE-2022-50047
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6060: prevent crash on an unused port If the port isn't a CPU port nor a user port, 'cpu_dp' is a null pointer and a crash happened on dereferencing it in mv88e6060_setup_port(): [ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014 ... [ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84 [ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54 [ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0 [ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c [ 9.967029] driver_probe_device from __device_attach_driver+0xb8/0x13c [ 9.973946] __device_attach_driver from bus_for_each_drv+0x90/0xe0 [ 9.980509] bus_for_each_drv from __device_attach+0x110/0x184 [ 9.986632] __device_attach from bus_probe_device+0x8c/0x94 [ 9.992577] bus_probe_device from deferred_probe_work_func+0x78/0xa8 [ 9.999311] deferred_probe_work_func from process_one_work+0x290/0x73c [ 10.006292] process_one_work from worker_thread+0x30/0x4b8 [ 10.012155] worker_thread from kthread+0xd4/0x10c [ 10.017238] kthread from ret_from_fork+0x14/0x3c
- https://git.kernel.org/stable/c/246bbf2f977ea36aaf41f5d24370fef433250728
- https://git.kernel.org/stable/c/92dc64e8f591425ce4dabf7d479ebf6e67fb8853
- https://git.kernel.org/stable/c/cb1753bc689c7a7f94da6eee7efc1ae6d8abb36c
- https://git.kernel.org/stable/c/dd236b62d25e44ecfa26b0910a12f8d8251aff00
- https://git.kernel.org/stable/c/f3a4b55829617cad2d36fa6524367ef629566ba6
Modified: 2025-11-13
CVE-2022-50048
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: possible module reference underflow in error path dst->ops is set on when nft_expr_clone() fails, but module refcount has not been bumped yet, therefore nft_expr_destroy() leads to module reference underflow.
Modified: 2025-11-13
CVE-2022-50049
In the Linux kernel, the following vulnerability has been resolved: ASoC: DPCM: Don't pick up BE without substream When DPCM tries to add valid BE connections at dpcm_add_paths(), it doesn't check whether the picked BE actually supports for the given stream direction. Due to that, when an asymmetric BE stream is present, it picks up wrongly and this may result in a NULL dereference at a later point where the code assumes the existence of a corresponding BE substream. This patch adds the check for the presence of the substream for the target BE for avoiding the problem above. Note that we have already some fix for non-existing BE substream at commit 6246f283d5e0 ("ASoC: dpcm: skip missing substream while applying symmetry"). But the code path we've hit recently is rather happening before the previous fix. So this patch tries to fix at picking up a BE instead of parsing BE lists.
Modified: 2025-11-13
CVE-2022-50050
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf() snprintf() returns the would-be-filled size when the string overflows the given buffer size, hence using this value may result in the buffer overflow (although it's unrealistic). This patch replaces with a safer version, scnprintf() for papering over such a potential issue.
Modified: 2025-11-13
CVE-2022-50051
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: debug: Fix potential buffer overflow by snprintf() snprintf() returns the would-be-filled size when the string overflows the given buffer size, hence using this value may result in the buffer overflow (although it's unrealistic). This patch replaces with a safer version, scnprintf() for papering over such a potential issue.
Modified: 2025-11-13
CVE-2022-50053
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix reset error handling
Do not call iavf_close in iavf_reset_task error handling. Doing so can
lead to double call of napi_disable, which can lead to deadlock there.
Removing VF would lead to iavf_remove task being stuck, because it
requires crit_lock, which is held by iavf_close.
Call iavf_disable_vf if reset fail, so that driver will clean up
remaining invalid resources.
During rapid VF resets, HW can fail to setup VF mailbox. Wrong
error handling can lead to iavf_remove being stuck with:
[ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53
...
[ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds.
[ 5267.189520] Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1
[ 5267.189764] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 5267.190062] task:repro.sh state:D stack: 0 pid:11219 ppid: 8162 flags:0x00000000
[ 5267.190347] Call Trace:
[ 5267.190647]
Modified: 2025-11-13
CVE-2022-50054
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix NULL pointer dereference in iavf_get_link_ksettings
Fix possible NULL pointer dereference, due to freeing of adapter->vf_res
in iavf_init_get_resources. Previous commit introduced a regression,
where receiving IAVF_ERR_ADMIN_QUEUE_NO_WORK from iavf_get_vf_config
would free adapter->vf_res. However, netdev is still registered, so
ethtool_ops can be called. Calling iavf_get_link_ksettings with no vf_res,
will result with:
[ 9385.242676] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 9385.242683] #PF: supervisor read access in kernel mode
[ 9385.242686] #PF: error_code(0x0000) - not-present page
[ 9385.242690] PGD 0 P4D 0
[ 9385.242696] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
[ 9385.242701] CPU: 6 PID: 3217 Comm: pmdalinux Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1
[ 9385.242708] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019
[ 9385.242710] RIP: 0010:iavf_get_link_ksettings+0x29/0xd0 [iavf]
[ 9385.242745] Code: 00 0f 1f 44 00 00 b8 01 ef ff ff 48 c7 46 30 00 00 00 00 48 c7 46 38 00 00 00 00 c6 46 0b 00 66 89 46 08 48 8b 87 68 0e 00 00
Modified: 2025-11-13
CVE-2022-50055
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix adminq error handling iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent memory for VF mailbox. Free DMA regions for both ASQ and ARQ in case error happens during configuration of ASQ/ARQ registers. Without this change it is possible to see when unloading interface: 74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32] One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
- https://git.kernel.org/stable/c/35c63581fdefdcbaeae8cded18908523252353ad
- https://git.kernel.org/stable/c/419831617ed349992c84344dbd9e627f9e68f842
- https://git.kernel.org/stable/c/4fe80492d53971d9a49f39f3c86d2d67c6f3638a
- https://git.kernel.org/stable/c/dab6b551f5ba4c79a0dd4970dd8533c37a7b100f
- https://git.kernel.org/stable/c/ff289f2be5899efd0e897d2b434a78e36df2c69b
Modified: 2025-11-13
CVE-2022-50056
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix missing i_op in ntfs_read_mft There is null pointer dereference because i_op == NULL. The bug happens because we don't initialize i_op for records in $Extend.
Modified: 2025-11-13
CVE-2022-50057
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr
If ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL.
Code should check this ptr before dereferencing. Syzbot hit this issue
via passing wrong mount param as can be seen from log below
Fail log:
ntfs3: Unknown parameter 'iochvrset'
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0
...
Call Trace:
Modified: 2025-11-13
CVE-2022-50059
In the Linux kernel, the following vulnerability has been resolved: ceph: don't leak snap_rwsem in handle_cap_grant When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is held and the function is expected to release it before returning. It currently fails to do that in all cases which could lead to a deadlock.
Modified: 2025-11-13
CVE-2022-50060
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix mcam entry resource leak The teardown sequence in FLR handler returns if no NIX LF is attached to PF/VF because it indicates that graceful shutdown of resources already happened. But there is a chance of all allocated MCAM entries not being freed by PF/VF. Hence free mcam entries even in case of detached LF.
Modified: 2025-11-13
CVE-2022-50061
In the Linux kernel, the following vulnerability has been resolved: pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak."
- https://git.kernel.org/stable/c/4b32e054335ea0ce50967f63a7bfd4db058b14b9
- https://git.kernel.org/stable/c/587ac8ac00a1a9f4572785229d9441870fd7b187
- https://git.kernel.org/stable/c/78d05103891d3e96144b846fbc39f2cfb3384eae
- https://git.kernel.org/stable/c/81abaab5a4b815c0ed9f4d2c9745777ac5cc395b
- https://git.kernel.org/stable/c/9272265f2f76629e1a67e6d49b3a4461b3da1a73
- https://git.kernel.org/stable/c/c26012a1e61c7bbd1b393d3bbae8dffdb6df65bb
- https://git.kernel.org/stable/c/c35f89a9021fa947ecede0584ae509368a52ec5a
- https://git.kernel.org/stable/c/f498542bc703bf1e5c6a1610e1ea493a437f0196
Modified: 2025-11-13
CVE-2022-50062
In the Linux kernel, the following vulnerability has been resolved:
net: bgmac: Fix a BUG triggered by wrong bytes_compl
On one of our machines we got:
kernel BUG at lib/dynamic_queue_limits.c:27!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G W O 4.14.275-rt132 #1
Hardware name: BRCM XGS iProc
task: ee3415c0 task.stack: ee32a000
PC is at dql_completed+0x168/0x178
LR is at bgmac_poll+0x18c/0x6d8
pc : [
- https://git.kernel.org/stable/c/1b7680c6c1f6de9904f1d9b05c952f0c64a03350
- https://git.kernel.org/stable/c/ab2b55bb25db289ba0b68e3d58494476bdb1041d
- https://git.kernel.org/stable/c/ac6d4482f29ab992b605c1b4bd1347f1f679f4e4
- https://git.kernel.org/stable/c/c506c9a97120f43257e9b3ce7b1f9a24eafc3787
- https://git.kernel.org/stable/c/da1421a29d3b8681ba6a7f686bd0b40dda5acaf3
Modified: 2025-11-17
CVE-2022-50065
In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix memory leak inside XPD_TX with mergeable When we call xdp_convert_buff_to_frame() to get xdpf, if it returns NULL, we should check if xdp_page was allocated by xdp_linearize_page(). If it is newly allocated, it should be freed here alone. Just like any other "goto err_xdp".
Modified: 2025-11-17
CVE-2022-50066
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: fix aq_vec index out of range error
The final update statement of the for loop exceeds the array range, the
dereference of self->aq_vec[i] is not checked and then leads to the
index out of range error.
Also fixed this kind of coding style in other for loop.
[ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48
[ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]'
[ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2
[ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022
[ 97.937611] Workqueue: events_unbound async_run_entry_fn
[ 97.937616] Call Trace:
[ 97.937617]
Modified: 2025-11-17
CVE-2022-50067
In the Linux kernel, the following vulnerability has been resolved: btrfs: unset reloc control if transaction commit fails in prepare_to_relocate() In btrfs_relocate_block_group(), the rc is allocated. Then btrfs_relocate_block_group() calls relocate_block_group() prepare_to_relocate() set_reloc_control() that assigns rc to the variable fs_info->reloc_ctl. When prepare_to_relocate() returns, it calls btrfs_commit_transaction() btrfs_start_dirty_block_groups() btrfs_alloc_path() kmem_cache_zalloc() which may fail for example (or other errors could happen). When the failure occurs, btrfs_relocate_block_group() detects the error and frees rc and doesn't set fs_info->reloc_ctl to NULL. After that, in btrfs_init_reloc_root(), rc is retrieved from fs_info->reloc_ctl and then used, which may cause a use-after-free bug. This possible bug can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag(). To fix this possible bug, in prepare_to_relocate(), check if btrfs_commit_transaction() fails. If the failure occurs, unset_reloc_control() is called to set fs_info->reloc_ctl to NULL. The error log in our fault-injection testing is shown as follows: [ 58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs] ... [ 58.753577] Call Trace: ... [ 58.755800] kasan_report+0x45/0x60 [ 58.756066] btrfs_init_reloc_root+0x7ca/0x920 [btrfs] [ 58.757304] record_root_in_trans+0x792/0xa10 [btrfs] [ 58.757748] btrfs_record_root_in_trans+0x463/0x4f0 [btrfs] [ 58.758231] start_transaction+0x896/0x2950 [btrfs] [ 58.758661] btrfs_defrag_root+0x250/0xc00 [btrfs] [ 58.759083] btrfs_ioctl_defrag+0x467/0xa00 [btrfs] [ 58.759513] btrfs_ioctl+0x3c95/0x114e0 [btrfs] ... [ 58.768510] Allocated by task 23683: [ 58.768777] ____kasan_kmalloc+0xb5/0xf0 [ 58.769069] __kmalloc+0x227/0x3d0 [ 58.769325] alloc_reloc_control+0x10a/0x3d0 [btrfs] [ 58.769755] btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs] [ 58.770228] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.770655] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.771071] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.771472] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.771902] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ... [ 58.773337] Freed by task 23683: ... [ 58.774815] kfree+0xda/0x2b0 [ 58.775038] free_reloc_control+0x1d6/0x220 [btrfs] [ 58.775465] btrfs_relocate_block_group+0x115c/0x1e20 [btrfs] [ 58.775944] btrfs_relocate_chunk+0xf1/0x760 [btrfs] [ 58.776369] __btrfs_balance+0x1326/0x1f10 [btrfs] [ 58.776784] btrfs_balance+0x3150/0x3d30 [btrfs] [ 58.777185] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] [ 58.777621] btrfs_ioctl+0x4caa/0x114e0 [btrfs] ...
- https://git.kernel.org/stable/c/5d741afed0bac206640cc64d77b97853283cf719
- https://git.kernel.org/stable/c/78f8c2370e3d33e35f23bdc648653d779aeacb6e
- https://git.kernel.org/stable/c/85f02d6c856b9f3a0acf5219de6e32f58b9778eb
- https://git.kernel.org/stable/c/8e546674031fc1576da501e27a8fd165222e5a37
- https://git.kernel.org/stable/c/b60e862e133f646f19023ece1d476d630a660de1
- https://git.kernel.org/stable/c/dcb11fe0a0a9cca2b7425191b9bf30dc29f2ad0f
- https://git.kernel.org/stable/c/ff0e8ed8dfb584575cffc1561f17a1d094e8565b
Modified: 2025-11-17
CVE-2022-50068
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix dummy res NULL ptr deref bug
Check the bo->resource value before accessing the resource
mem_type.
v2: Fix commit description unwrapped warning
Modified: 2025-11-17
CVE-2022-50069
In the Linux kernel, the following vulnerability has been resolved:
BPF: Fix potential bad pointer dereference in bpf_sys_bpf()
The bpf_sys_bpf() helper function allows an eBPF program to load another
eBPF program from within the kernel. In this case the argument union
bpf_attr pointer (as well as the insns and license pointers inside) is a
kernel address instead of a userspace address (which is the case of a
usual bpf() syscall). To make the memory copying process in the syscall
work in both cases, bpfptr_t was introduced to wrap around the pointer
and distinguish its origin. Specifically, when copying memory contents
from a bpfptr_t, a copy_from_user() is performed in case of a userspace
address and a memcpy() is performed for a kernel address.
This can lead to problems because the in-kernel pointer is never checked
for validity. The problem happens when an eBPF syscall program tries to
call bpf_sys_bpf() to load a program but provides a bad insns pointer --
say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()
which would then call bpf_prog_load() to load the program.
bpf_prog_load() is responsible for copying the eBPF instructions to the
newly allocated memory for the program; it creates a kernel bpfptr_t for
insns and invokes copy_from_bpfptr(). Internally, all bpfptr_t
operations are backed by the corresponding sockptr_t operations, which
performs direct memcpy() on kernel pointers for copy_from/strncpy_from
operations. Therefore, the code is always happy to dereference the bad
pointer to trigger a un-handle-able page fault and in turn an oops.
However, this is not supposed to happen because at that point the eBPF
program is already verified and should not cause a memory error.
Sample KASAN trace:
[ 25.685056][ T228] ==================================================================
[ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30
[ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228
[ 25.686732][ T228]
[ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7
[ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014
[ 25.687991][ T228] Call Trace:
[ 25.688223][ T228]
Modified: 2025-11-17
CVE-2022-50070
In the Linux kernel, the following vulnerability has been resolved:
mptcp: do not queue data on closed subflows
Dipanjan reported a syzbot splat at close time:
WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153
inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
Modules linked in: uio_ivshmem(OE) uio(E)
CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE
5.19.0-rc6-g2eae0556bb9d #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91
f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b
e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d
RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00
RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002
RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000
R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400
R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258
FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0
Call Trace:
Modified: 2025-11-17
CVE-2022-50071
In the Linux kernel, the following vulnerability has been resolved: mptcp: move subflow cleanup in mptcp_destroy_common() If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE eBPF program, the MPTCP protocol ends-up leaking all the subflows: the related cleanup happens in __mptcp_destroy_sock() that is not invoked in such code path. Address the issue moving the subflow sockets cleanup in the mptcp_destroy_common() helper, which is invoked in every msk cleanup path. Additionally get rid of the intermediate list_splice_init step, which is an unneeded relic from the past. The issue is present since before the reported root cause commit, but any attempt to backport the fix before that hash will require a complete rewrite.
Modified: 2025-11-17
CVE-2022-50072
In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: Fix a use-after-free bug in open If someone cancels the open RPC call, then we must not try to free either the open slot or the layoutget operation arguments, since they are likely still in use by the hung RPC call.
- https://git.kernel.org/stable/c/0fffb46ff3d5ed4668aca96441ec7a25b793bd6f
- https://git.kernel.org/stable/c/2135e5d56278ffdb1c2e6d325dc6b87f669b9dac
- https://git.kernel.org/stable/c/76ffd2042438769298f34b76102b40dea89de616
- https://git.kernel.org/stable/c/a4cf3dadd1fa43609f7c6570c9116b0e0a9923d1
- https://git.kernel.org/stable/c/b03d1117e9be7c7da60e466eaf9beed85c5916c8
- https://git.kernel.org/stable/c/f7ee3b772d9de87387a725caa04bc041ac7fe5ec
Modified: 2025-11-17
CVE-2022-50073
In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30
Modified: 2025-11-17
CVE-2022-50074
In the Linux kernel, the following vulnerability has been resolved: apparmor: Fix memleak in aa_simple_write_to_buffer() When copy_from_user failed, the memory is freed by kvfree. however the management struct and data blob are allocated independently, so only kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to fix this issue.
- https://git.kernel.org/stable/c/417ea9fe972d2654a268ad66e89c8fcae67017c3
- https://git.kernel.org/stable/c/6500eb3a48ac221051b1791818a1ac74744ef617
- https://git.kernel.org/stable/c/6583edbf459de2e06b9759f264c0ae27e452b97a
- https://git.kernel.org/stable/c/7db182a2ebeefded86fea542fcc5d6a68bb77f58
- https://git.kernel.org/stable/c/8aab4295582eb397a125d2788b829fa62b88dbf7
- https://git.kernel.org/stable/c/bf7ebebce2c25071c719fd8a2f1307e0c243c2d7
Modified: 2025-11-17
CVE-2022-50075
In the Linux kernel, the following vulnerability has been resolved: tracing/eprobes: Have event probes be consistent with kprobes and uprobes Currently, if a symbol "@" is attempted to be used with an event probe (eprobes), it will cause a NULL pointer dereference crash. Both kprobes and uprobes can reference data other than the main registers. Such as immediate address, symbols and the current task name. Have eprobes do the same thing. For "comm", if "comm" is used and the event being attached to does not have the "comm" field, then make it the "$comm" that kprobes has. This is consistent to the way histograms and filters work.
Modified: 2025-11-17
CVE-2022-50076
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory leak on the deferred close xfstests on smb21 report kmemleak as below: unreferenced object 0xffff8881767d6200 (size 64): comm "xfs_io", pid 1284, jiffies 4294777434 (age 20.789s) hex dump (first 32 bytes): 80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c.... 00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .q.v............ backtrace: [<00000000ad04e6ea>] cifs_close+0x92/0x2c0 [<0000000028b93c82>] __fput+0xff/0x3f0 [<00000000d8116851>] task_work_run+0x85/0xc0 [<0000000027e14f9e>] do_exit+0x5e5/0x1240 [<00000000fb492b95>] do_group_exit+0x58/0xe0 [<00000000129a32d9>] __x64_sys_exit_group+0x28/0x30 [<00000000e3f7d8e9>] do_syscall_64+0x35/0x80 [<00000000102e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 When cancel the deferred close work, we should also cleanup the struct cifs_deferred_close.
Modified: 2025-11-17
CVE-2022-50077
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix reference count leak in aa_pivotroot() The aa_pivotroot() function has a reference counting bug in a specific path. When aa_replace_current_label() returns on success, the function forgets to decrement the reference count of “target”, which is increased earlier by build_pivotroot(), causing a reference leak. Fix it by decreasing the refcount of “target” in that path.
- https://git.kernel.org/stable/c/11c3627ec6b56c1525013f336f41b79a983b4d46
- https://git.kernel.org/stable/c/2ceeb3296e9dde1d5772348046affcefdea605e2
- https://git.kernel.org/stable/c/3ca40ad7afae144169a43988ef1a3f16182faf0a
- https://git.kernel.org/stable/c/64103ea357734b82384c925cba4758fdb909be0c
- https://git.kernel.org/stable/c/d53194707d2a1851be027cd74266b96ceff799d3
- https://git.kernel.org/stable/c/ef6fb6f0d0d8440595b45a7e53c6162c737177f4
- https://git.kernel.org/stable/c/f4d5c7796571624e3f380b447ada52834270a287
Modified: 2025-11-17
CVE-2022-50078
In the Linux kernel, the following vulnerability has been resolved:
tracing/eprobes: Do not allow eprobes to use $stack, or % for regs
While playing with event probes (eprobes), I tried to see what would
happen if I attempted to retrieve the instruction pointer (%rip) knowing
that event probes do not use pt_regs. The result was:
BUG: kernel NULL pointer dereference, address: 0000000000000024
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ #309
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
v03.03 07/14/2016
RIP: 0010:get_event_field.isra.0+0x0/0x50
Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8
50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24
8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74
RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086
RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000
RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8
R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8
R13: ffff916c854041b0 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff916c9ea40000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0
Call Trace:
Modified: 2025-11-17
CVE-2022-50079
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check correct bounds for stream encoder instances for DCN303 [Why & How] eng_id for DCN303 cannot be more than 1, since we have only two instances of stream encoders. Check the correct boundary condition for engine ID for DCN303 prevent the potential out of bounds access.
Modified: 2025-11-18
CVE-2022-50080
In the Linux kernel, the following vulnerability has been resolved: tee: add overflow check in register_shm_helper() With special lengths supplied by user space, register_shm_helper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region. This causes internal_get_user_pages_fast() a helper function of pin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114 Fix this by adding an an explicit call to access_ok() in tee_shm_register_user_buf() to catch an invalid user space address early.
- https://git.kernel.org/stable/c/2f8e79a1a6128214cb9b205a9869341af5dfb16b
- https://git.kernel.org/stable/c/573ae4f13f630d6660008f1974c0a8a29c30e18a
- https://git.kernel.org/stable/c/578c349570d2a912401963783b36e0ec7a25c053
- https://git.kernel.org/stable/c/58c008d4d398f792ca67f35650610864725518fd
- https://git.kernel.org/stable/c/965333345fe952cc7eebc8e3a565ffc709441af2
- https://git.kernel.org/stable/c/b37e0f17653c00b586cdbcdf0dbca475358ecffd
- https://git.kernel.org/stable/c/c12f0e6126ad223806a365084e86370511654bf1
Modified: 2025-11-18
CVE-2022-50082
In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_iomap_begin as race between bmap and write We got issue as follows: ------------[ cut here ]------------ WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0 RIP: 0010:ext4_iomap_begin+0x182/0x5d0 RSP: 0018:ffff88812460fa08 EFLAGS: 00010293 RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001 R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: bmap write bmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on To solved above issue hold inode lock in ext4_bamp.
- https://git.kernel.org/stable/c/30dfb75e1f8645404a536c74d468d498adcd4e74
- https://git.kernel.org/stable/c/51ae846cff568c8c29921b1b28eb2dfbcd4ac12d
- https://git.kernel.org/stable/c/a9fe6d1e3d343d7309f501b1f48020ce7127221f
- https://git.kernel.org/stable/c/e1682c7171a6c0ff576fe8116b8cba5b8f538b94
- https://git.kernel.org/stable/c/fa6482f374fda29a71ad44d76d35b4842d43cda4
Modified: 2025-11-18
CVE-2022-50084
In the Linux kernel, the following vulnerability has been resolved:
dm raid: fix address sanitizer warning in raid_status
There is this warning when using a kernel with the address sanitizer
and running this testsuite:
https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid
==================================================================
BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]
Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319
CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.
- https://git.kernel.org/stable/c/1ae0ebfb576b72c2ef400917a5484ebe7892d80b
- https://git.kernel.org/stable/c/1fbeea217d8f297fe0e0956a1516d14ba97d0396
- https://git.kernel.org/stable/c/49dba30638e091120256a9e89125340795f034dc
- https://git.kernel.org/stable/c/4c233811a49578634d10a5e70a9dfa569d451e94
- https://git.kernel.org/stable/c/90b006da40dd42285b24dd3c940d2c32aca9a70b
- https://git.kernel.org/stable/c/b4c6c07c92b6cba2bf3cb2dfa722debeaf8a8abe
- https://git.kernel.org/stable/c/b856ce5f4b55f752144baf17e9d5c415072652c5
- https://git.kernel.org/stable/c/cb583ca6125ac64c98e9d65128e95ebb5be7d322
- https://git.kernel.org/stable/c/d8971b595d7adac3421c21f59918241f1574061e
Modified: 2025-11-18
CVE-2022-50085
In the Linux kernel, the following vulnerability has been resolved: dm raid: fix address sanitizer warning in raid_resume There is a KASAN warning in raid_resume when running the lvm test lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks is greater than rs->raid_disks, so the loop touches one entry beyond the allocated length.
- https://git.kernel.org/stable/c/2a9faa704d83ff0b04387e385efd8ae21cd95af6
- https://git.kernel.org/stable/c/3bfdc95466f5be4d8d95db5a5b470d61641a7c24
- https://git.kernel.org/stable/c/50235d9a1f1f742619ed9963cb9f240e5b821d46
- https://git.kernel.org/stable/c/71f601c779b3cc1baf497796f5b922c3fe5d2a1e
- https://git.kernel.org/stable/c/74af83732a39ab7d3bc9b49219a535853e25679f
- https://git.kernel.org/stable/c/7dad24db59d2d2803576f2e3645728866a056dab
- https://git.kernel.org/stable/c/c2d47bef93fb74aa97d90f9a40ca657b8f376083
- https://git.kernel.org/stable/c/c2f075e729636a44e98d9722e3852c2fa6fa49b6
Modified: 2025-11-18
CVE-2022-50086
In the Linux kernel, the following vulnerability has been resolved: block: don't allow the same type rq_qos add more than once In our test of iocost, we encountered some list add/del corruptions of inner_walk list in ioc_timer_fn. The reason can be described as follows: cpu 0 cpu 1 ioc_qos_write ioc_qos_write ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ... } When the io.cost.qos file is written by two cpus concurrently, rq_qos may be added to one disk twice. In that case, there will be two iocs enabled and running on one disk. They own different iocgs on their active list. In the ioc_timer_fn function, because of the iocgs from two iocs have the same root iocg, the root iocg's walk_list may be overwritten by each other and this leads to list add/del corruptions in building or destroying the inner_walk list. And so far, the blk-rq-qos framework works in case that one instance for one type rq_qos per queue by default. This patch make this explicit and also fix the crash above.
Modified: 2025-11-18
CVE-2022-50087
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails.
- https://git.kernel.org/stable/c/08272646cd7c310642c39b7f54348fddd7987643
- https://git.kernel.org/stable/c/0c29e149b6bb498778ed8a1c9597b51acfba7856
- https://git.kernel.org/stable/c/18048cba444a7c41dbf42c180d6b46606fc24c51
- https://git.kernel.org/stable/c/4f2d7b46d6b53c07f44a4f8f8f4438888f0e9e87
- https://git.kernel.org/stable/c/5aa558232edc30468d1f35108826dd5b3ffe978f
- https://git.kernel.org/stable/c/689640efc0a2c4e07e6f88affe6d42cd40cc3f85
- https://git.kernel.org/stable/c/87c4896d5dd7fd9927c814cf3c6289f41de3b562
Modified: 2025-11-18
CVE-2022-50088
In the Linux kernel, the following vulnerability has been resolved: mm/damon/reclaim: fix potential memory leak in damon_reclaim_init() damon_reclaim_init() allocates a memory chunk for ctx with damon_new_ctx(). When damon_select_ops() fails, ctx is not released, which will lead to a memory leak. We should release the ctx with damon_destroy_ctx() when damon_select_ops() fails to fix the memory leak.
Modified: 2025-11-18
CVE-2022-50089
In the Linux kernel, the following vulnerability has been resolved:
btrfs: ensure pages are unlocked on cow_file_range() failure
There is a hung_task report on zoned btrfs like below.
https://github.com/naota/linux/issues/59
[726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds.
[726.329839] Not tainted 5.16.0-rc1+ #1
[726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000
[726.331608] Call Trace:
[726.331611]
Modified: 2025-11-18
CVE-2022-50090
In the Linux kernel, the following vulnerability has been resolved:
btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size
On zoned filesystem, data write out is limited by max_zone_append_size,
and a large ordered extent is split according the size of a bio. OTOH,
the number of extents to be written is calculated using
BTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve the
metadata bytes to update and/or create the metadata items.
The metadata reservation is done at e.g, btrfs_buffered_write() and then
released according to the estimation changes. Thus, if the number of extent
increases massively, the reserved metadata can run out.
The increase of the number of extents easily occurs on zoned filesystem
if BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. And, it causes the
following warning on a small RAM environment with disabling metadata
over-commit (in the following patch).
[75721.498492] ------------[ cut here ]------------
[75721.505624] BTRFS: block rsv 1 returned -28
[75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs]
[75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109
[75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021
[75721.607310] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
[75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs]
[75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286
[75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000
[75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e
[75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7
[75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28
[75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a
[75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000
[75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0
[75721.730499] Call Trace:
[75721.735166]
Modified: 2025-11-18
CVE-2022-50091
In the Linux kernel, the following vulnerability has been resolved: locking/csd_lock: Change csdlock_debug from early_param to __setup The csdlock_debug kernel-boot parameter is parsed by the early_param() function csdlock_debug(). If set, csdlock_debug() invokes static_branch_enable() to enable csd_lock_wait feature, which triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and CONFIG_SPARSEMEM_VMEMMAP=n. With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in static_key_enable() and returns NULL, resulting in a NULL dereference because mem_section is initialized only later in sparse_init(). This is also a problem for powerpc because early_param() functions are invoked earlier than jump_label_init(), also resulting in static_key_enable() failures. These failures cause the warning "static key 'xxx' used before call to jump_label_init()". Thus, early_param is too early for csd_lock_wait to run static_branch_enable(), so changes it to __setup to fix these.
Modified: 2025-11-18
CVE-2022-50092
In the Linux kernel, the following vulnerability has been resolved:
dm thin: fix use-after-free crash in dm_sm_register_threshold_callback
Fault inject on pool metadata device reports:
BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80
Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950
CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/05cef0999b3208b5a6ede1bfac855139e4de55ef
- https://git.kernel.org/stable/c/1a199fa9217d28511ff88529238fd9980ea64cf3
- https://git.kernel.org/stable/c/3534e5a5ed2997ca1b00f44a0378a075bd05e8a3
- https://git.kernel.org/stable/c/5e2cf705155a1514be3c96ea664a9cd356998ee7
- https://git.kernel.org/stable/c/e4dbe24f4bfd8377e7ba79fdcdb7c4d6eb1c6790
- https://git.kernel.org/stable/c/f83131a3071a0b61a4d7dca70f95adb3ffad920e
Modified: 2025-11-18
CVE-2022-50093
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)
KASAN reports:
[ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
[ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0
[ 4.683454][ T0]
[ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1
[ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016
[ 4.703196][ T0] Call Trace:
[ 4.706334][ T0]
- https://git.kernel.org/stable/c/0b4c0003aeda32a600f95df53b2848da8a5aa3fa
- https://git.kernel.org/stable/c/5659efdadf04b56707d58c1b758df16d2e0eff2c
- https://git.kernel.org/stable/c/73ce2046e04ad488cecc66757c36cbe1bdf089d4
- https://git.kernel.org/stable/c/b0b0b77ea611e3088e9523e60860f4f41b62b235
- https://git.kernel.org/stable/c/b12304984654d8e58a2b22ff94c4410906d6267f
- https://git.kernel.org/stable/c/c2304c50f4d94f56c2e326f25c9dc8cf2ba6f5fa
Modified: 2025-11-18
CVE-2022-50094
In the Linux kernel, the following vulnerability has been resolved: spmi: trace: fix stack-out-of-bound access in SPMI tracing functions trace_spmi_write_begin() and trace_spmi_read_end() both call memcpy() with a length of "len + 1". This leads to one extra byte being read beyond the end of the specified buffer. Fix this out-of-bound memory access by using a length of "len" instead. Here is a KASAN log showing the issue: BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234 Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314 ... Call trace: dump_backtrace+0x0/0x3e8 show_stack+0x2c/0x3c dump_stack_lvl+0xdc/0x11c print_address_description+0x74/0x384 kasan_report+0x188/0x268 kasan_check_range+0x270/0x2b0 memcpy+0x90/0xe8 trace_event_raw_event_spmi_read_end+0x1d0/0x234 spmi_read_cmd+0x294/0x3ac spmi_ext_register_readl+0x84/0x9c regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi] _regmap_raw_read+0x40c/0x754 regmap_raw_read+0x3a0/0x514 regmap_bulk_read+0x418/0x494 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3] ... __arm64_sys_read+0x4c/0x60 invoke_syscall+0x80/0x218 el0_svc_common+0xec/0x1c8 ... addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame: adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] this frame has 1 object: [32, 33) 'status' Memory state around the buggy address: ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00 ^ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00 ==================================================================
- https://git.kernel.org/stable/c/1e0ca3d809c36ad3d1f542917718fc22ec6316e7
- https://git.kernel.org/stable/c/2af28b241eea816e6f7668d1954f15894b45d7e3
- https://git.kernel.org/stable/c/37690cb8662cec672cacda19e6e4fd2ca7b13f0b
- https://git.kernel.org/stable/c/504090815c1ad3fd3fa34618b54d706727f8911c
- https://git.kernel.org/stable/c/80f7c93e573ea9f524924bb529c2af8cb28b1c43
- https://git.kernel.org/stable/c/ac730c72bddc889f5610d51d8a7abf425e08da1a
- https://git.kernel.org/stable/c/bcc1b6b1ed3f42ed25858c1f1eb24a2f741db93f
- https://git.kernel.org/stable/c/dc6033a7761254e5a5ba7df36b64db787a53313c
- https://git.kernel.org/stable/c/dd02510fb43168310abfd0b9ccf49993a722fb91
Modified: 2025-11-18
CVE-2022-50095
In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Cleanup CPU timers before freeing them during exec Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") started looking up tasks by PID when deleting a CPU timer. When a non-leader thread calls execve, it will switch PIDs with the leader process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find the task because the timer still points out to the old PID. That means that armed timers won't be disarmed, that is, they won't be removed from the timerqueue_list. exit_itimers will still release their memory, and when that list is later processed, it leads to a use-after-free. Clean up the timers from the de-threaded task before freeing them. This prevents a reported use-after-free.
- https://git.kernel.org/stable/c/541840859ace9c2ccebc32fa9e376c7bd3def490
- https://git.kernel.org/stable/c/9e255ed238fc67058df87b0388ad6d4b2ef3a2bd
- https://git.kernel.org/stable/c/b2fc1723eb65abb83e00d5f011de670296af0b28
- https://git.kernel.org/stable/c/e362359ace6f87c201531872486ff295df306d13
- https://git.kernel.org/stable/c/e8cb6e8fd9890780f1bfcf5592889e1b879e779c
Modified: 2025-11-19
CVE-2022-50096
In the Linux kernel, the following vulnerability has been resolved: x86/kprobes: Update kcb status flag after singlestepping Fix kprobes to update kcb (kprobes control block) status flag to KPROBE_HIT_SSDONE even if the kp->post_handler is not set. This bug may cause a kernel panic if another INT3 user runs right after kprobes because kprobe_int3_handler() misunderstands the INT3 is kprobe's single stepping INT3.
- https://git.kernel.org/stable/c/1cbf3882cb372bbe752efd7c3045ca1c9ab40ac6
- https://git.kernel.org/stable/c/663cdda2716b70751df9c7e60b81bd0850fdfe3c
- https://git.kernel.org/stable/c/b9c3401f7cac6ae291a16784dadcd1bf116218fe
- https://git.kernel.org/stable/c/dec8784c9088b131a1523f582c2194cfc8107dc0
- https://git.kernel.org/stable/c/edc2ac7c7265b33660fa0190898966b49966b855
Modified: 2025-11-19
CVE-2022-50097
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: s3fb: Check the size of screen before memset_io() In the function s3fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000 [ 54.083742] #PF: supervisor write access in kernel mode [ 54.083744] #PF: error_code(0x0002) - not-present page [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0 [ 54.083782] Call Trace: [ 54.083788] s3fb_set_par+0x1ec6/0x4040 [ 54.083806] fb_set_var+0x604/0xeb0 [ 54.083836] do_fb_ioctl+0x234/0x670 Fix the this by checking the value of 'screen_size' before memset_io().
- https://git.kernel.org/stable/c/3c35a0dc2b4e7acf24c796043b64fa3eee799239
- https://git.kernel.org/stable/c/52461d387cc8c8f8dc40320caa2e9e101f73e7ba
- https://git.kernel.org/stable/c/574912261528589012b61f82d368256247c3a5a8
- https://git.kernel.org/stable/c/5e0da18956d38e7106664dc1d06367b22f06edd3
- https://git.kernel.org/stable/c/6ba592fa014f21f35a8ee8da4ca7b95a018f13e8
- https://git.kernel.org/stable/c/ce50d94afcb8690813c5522f24cd38737657db81
- https://git.kernel.org/stable/c/e2d7cacc6a2a1d77e7e20a492daf458a12cf19e0
- https://git.kernel.org/stable/c/eacb50f1733660911827d7c3720f4c5425d0cdda
Modified: 2025-11-19
CVE-2022-50098
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path. Following crash stack was seen: BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390
Modified: 2025-11-19
CVE-2022-50099
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: arkfb: Check the size of screen before memset_io() In the function arkfb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000 [ 659.399077] #PF: supervisor write access in kernel mode [ 659.399079] #PF: error_code(0x0002) - not-present page [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0 [ 659.399116] Call Trace: [ 659.399122] arkfb_set_par+0x143f/0x24c0 [ 659.399130] fb_set_var+0x604/0xeb0 [ 659.399161] do_fb_ioctl+0x234/0x670 [ 659.399189] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io().
- https://git.kernel.org/stable/c/0701df594bc1d7ae55fed407fb65dd90a93f8a9c
- https://git.kernel.org/stable/c/09e733d6ac948e6fda4b16252e44ea46f98fc8b4
- https://git.kernel.org/stable/c/2ce61c39c2a0b8ec82f48e0f7136f0dac105ae75
- https://git.kernel.org/stable/c/352305ea50d682b8e081d826da53caf9e744d7d0
- https://git.kernel.org/stable/c/4a20c5510aa2c031a096a58deb356e91609781c9
- https://git.kernel.org/stable/c/53198b81930e567ad6b879812d88052a1e8ac79e
- https://git.kernel.org/stable/c/8bcb1a06e3091716b7cbebe0e91d1de9895068cd
- https://git.kernel.org/stable/c/96b550971c65d54d64728d8ba973487878a06454
Modified: 2025-11-19
CVE-2022-50100
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Do not requeue task on CPU excluded from cpus_mask
The following warning was triggered on a large machine early in boot on
a distribution kernel but the same problem should also affect mainline.
WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440
Call Trace:
Modified: 2025-11-19
CVE-2022-50101
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: vt8623fb: Check the size of screen before memset_io() In the function vt8623fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000 [ 583.339049] #PF: supervisor write access in kernel mode [ 583.339052] #PF: error_code(0x0002) - not-present page [ 583.339074] RIP: 0010:memset_orig+0x33/0xb0 [ 583.339110] Call Trace: [ 583.339118] vt8623fb_set_par+0x11cd/0x21e0 [ 583.339146] fb_set_var+0x604/0xeb0 [ 583.339181] do_fb_ioctl+0x234/0x670 [ 583.339209] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io().
- https://git.kernel.org/stable/c/4a3cef1eaced13ba9b55381d46bfad937a3dac2c
- https://git.kernel.org/stable/c/52ad9bfeb8a0e62de30de6d39e8a49a72dd78150
- https://git.kernel.org/stable/c/73280a184aa2e1a625ce54ce761042955cc79cd0
- https://git.kernel.org/stable/c/b17caec5127bba6f90af92bcc85871df54548ac0
- https://git.kernel.org/stable/c/bd8269e57621e5b38cc0b4bd2fa02e85c9f2a441
- https://git.kernel.org/stable/c/c7a3f41e4b133d4dd25bc996b69039b19a34d69d
- https://git.kernel.org/stable/c/d71528ccdc7ae8d7500d414091d27805c51407a2
- https://git.kernel.org/stable/c/ec0754c60217248fa77cc9005d66b2b55200ac06
Modified: 2025-11-19
CVE-2022-50102
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock() Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug in: drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul); with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0. and then in: drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock); we'll get a division-by-zero. The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline] RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of ark_set_pixclock() first.
- https://git.kernel.org/stable/c/0288fa799e273b08839037499d704dc7bdc13e9a
- https://git.kernel.org/stable/c/15661642511b2b192077684a89f42a8d95d54286
- https://git.kernel.org/stable/c/236c1502520b7b08955467ec2e50b3232e34f1f9
- https://git.kernel.org/stable/c/2f1c4523f7a3aaabe7e53d3ebd378292947e95c8
- https://git.kernel.org/stable/c/76b3f0a0b56e53a960a14624a0f48b3d94b5e7e7
- https://git.kernel.org/stable/c/9ebc5031958c1f3a2795e4533b4091d77c738d14
- https://git.kernel.org/stable/c/a249e1b89ca25e1c34bdf96154e3f6224a91a9af
- https://git.kernel.org/stable/c/b9a66f23612b84617e04412169e155a4b92f632d
Modified: 2025-11-19
CVE-2022-50103
In the Linux kernel, the following vulnerability has been resolved: sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed With cgroup v2, the cpuset's cpus_allowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpuset_can_attach() can call task_can_attach() with an empty mask. This can lead to cpumask_any_and() returns nr_cpu_ids causing the call to dl_bw_of() to crash due to percpu value access of an out of bound CPU value. For example: [80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpuset_can_attach+0xa0/0x140 [80468.209953] cgroup_migrate_execute+0x8c/0x490 [80468.210931] cgroup_update_dfl_csses+0x254/0x270 [80468.211898] cgroup_subtree_control_write+0x322/0x400 [80468.212854] kernfs_fop_write_iter+0x11c/0x1b0 [80468.213777] new_sync_write+0x11f/0x1b0 [80468.214689] vfs_write+0x1eb/0x280 [80468.215592] ksys_write+0x5f/0xe0 [80468.216463] do_syscall_64+0x5c/0x80 [80468.224287] entry_SYSCALL_64_after_hwframe+0x44/0xae Fix that by using effective_cpus instead. For cgroup v1, effective_cpus is the same as cpus_allowed. For v2, effective_cpus is the real cpumask to be used by tasks within the cpuset anyway. Also update task_can_attach()'s 2nd argument name to cs_effective_cpus to reflect the change. In addition, a check is added to task_can_attach() to guard against the possibility that cpumask_any_and() may return a value >= nr_cpu_ids.
- https://git.kernel.org/stable/c/147f66d22f58712dce7ccdd6a1f6cb3ee8042df4
- https://git.kernel.org/stable/c/336626564b58071b8980a4e6a31a8f5d92705d9b
- https://git.kernel.org/stable/c/357f3f0e522a6ce1ce4a571cb780d9861d53bec7
- https://git.kernel.org/stable/c/b6e8d40d43ae4dec00c8fea2593eeea3114b8f44
- https://git.kernel.org/stable/c/f56607b44c9896e51678a7e8cdd3a5479f4b4548
Modified: 2025-11-19
CVE-2022-50104
In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: Fix refcount leak in xive_get_max_prio of_find_node_by_path() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/255b650cbec6849443ce2e0cdd187fd5e61c218c
- https://git.kernel.org/stable/c/2e18b869a8d574cfe9ee64df9c3d0a7ac7ed07a8
- https://git.kernel.org/stable/c/5ed9709d262bf026b2ff64979fbfe0f496287588
- https://git.kernel.org/stable/c/6d1e53f7f181a11a8a343def1e0d0209905b7c64
- https://git.kernel.org/stable/c/79b8eae24b7ee157bda07695d802be8576983fa8
- https://git.kernel.org/stable/c/d99733ad47a6c990b52e136608455643bfa708f2
- https://git.kernel.org/stable/c/ea494e8a9852abd0ba60f69b254ce0d7c38449e2
- https://git.kernel.org/stable/c/f658d5b528ce97a68efbb64ee54f6fe0909b189a
Modified: 2025-11-19
CVE-2022-50105
In the Linux kernel, the following vulnerability has been resolved: powerpc/spufs: Fix refcount leak in spufs_init_isolated_loader of_find_node_by_path() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/0aa5de2547b7ccf0a31bc740d12f829fae243112
- https://git.kernel.org/stable/c/14329d29a048dc35aac2374fb3d588d8190095a2
- https://git.kernel.org/stable/c/4288eb035ba4ddb53245e9365c919bb51ac00c2c
- https://git.kernel.org/stable/c/43584490ee6c8a104797444af6bf89d0dafe95c0
- https://git.kernel.org/stable/c/69e9fa07b229badab808980e984a9fe824116f00
- https://git.kernel.org/stable/c/6ac059dacffa8ab2f7798f20e4bd3333890c541c
- https://git.kernel.org/stable/c/85aff6a9b7b7ec4e5c319f7946c9864c8d5e3d4a
- https://git.kernel.org/stable/c/d0cb99948c5f6d8fe56f6e69b8dd0a05ee5f9cec
Modified: 2025-11-19
CVE-2022-50106
In the Linux kernel, the following vulnerability has been resolved: powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() in the error path to avoid refcount leak.
- https://git.kernel.org/stable/c/00dc7cbbb558955ff410fd392cc9b0366eb06df0
- https://git.kernel.org/stable/c/02ed44125d7a7238999750ca126b60f8dd7a88b1
- https://git.kernel.org/stable/c/51cf876b11fb6ca06f69e9d1de58f892d1522e9d
- https://git.kernel.org/stable/c/5eaa93caa63abf382b319dbe2f032232026740c2
- https://git.kernel.org/stable/c/6263ec8032c411b8ef6b7f00198cb18c855ee6cb
- https://git.kernel.org/stable/c/af41cff4ada533b1cf40de6c468ba164fd32c22d
- https://git.kernel.org/stable/c/df5d4b616ee76abc97e5bd348e22659c2b095b1c
- https://git.kernel.org/stable/c/f388643657cd5a04dc47a68d85321876c5b4c208
Modified: 2025-11-17
CVE-2022-50107
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory leak when using fscache If we hit the 'index == next_cached' case, we leak a refcount on the struct page. Fix this by using readahead_folio() which takes care of the refcount for you.
Modified: 2025-11-19
CVE-2022-50108
In the Linux kernel, the following vulnerability has been resolved: mfd: max77620: Fix refcount leak in max77620_initialise_fps of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1520669c8255bd637c6b248b2be910e2688d38dd
- https://git.kernel.org/stable/c/50d5fe8cb94c319cb4316f4d824570c075565354
- https://git.kernel.org/stable/c/a29c40814039535b950149311986a5f348b5db14
- https://git.kernel.org/stable/c/afdbadbf18c19779d7bc5df70d872924f9bbd76b
- https://git.kernel.org/stable/c/b948ff8a9e9ad46d4dff9127777caa14c8c2b53c
- https://git.kernel.org/stable/c/facd31bbc799f4d0cd25d9d688af7ca41e7f38ee
Modified: 2025-11-19
CVE-2022-50109
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: amba-clcd: Fix refcount leak bugs In clcdfb_of_init_display(), we should call of_node_put() for the references returned by of_graph_get_next_endpoint() and of_graph_get_remote_port_parent() which have increased the refcount. Besides, we should call of_node_put() both in fail path or when the references are not used anymore.
- https://git.kernel.org/stable/c/2688df86c02da6bdc9866b62d974e169a2678883
- https://git.kernel.org/stable/c/26c2b7d9fac42eb8317f3ceefa4c1a9a9170ca69
- https://git.kernel.org/stable/c/29f06f1905c312671a09ee85ca92ac04a1d9f305
- https://git.kernel.org/stable/c/49a4c1a87ef884e43cdda58b142a2a30f2f09efc
- https://git.kernel.org/stable/c/a51519ebd0fdad3546463018b8f6bc3b0f4d3032
- https://git.kernel.org/stable/c/a88ab277cca99aeb9a3b2b7db358f1a6dd528b0c
- https://git.kernel.org/stable/c/a97ff8a949dbf41be89f436b2b1a2b3d794493df
- https://git.kernel.org/stable/c/da276dc288bf838ea0fd778b5441ec0f601c69f7
Modified: 2025-11-17
CVE-2022-50110
In the Linux kernel, the following vulnerability has been resolved: watchdog: sp5100_tco: Fix a memory leak of EFCH MMIO resource Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak.
Modified: 2025-11-19
CVE-2022-50111
In the Linux kernel, the following vulnerability has been resolved: ASoC: mt6359: Fix refcount leak bug In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount.
Modified: 2025-11-18
CVE-2022-50112
In the Linux kernel, the following vulnerability has been resolved: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done.
- https://git.kernel.org/stable/c/43e42c25a232a6862e7d2f292a069ac828559030
- https://git.kernel.org/stable/c/65382585f067d4256ba087934f30f85c9b6984de
- https://git.kernel.org/stable/c/8ee5d40ae29e63f6fd6cbf9dcfc0a48c474013db
- https://git.kernel.org/stable/c/9715809b9eeb85b3f9b083857a2f29a9e2351125
- https://git.kernel.org/stable/c/ae7fdbab97df6a2115eed6b7e39c278b805c9c7d
- https://git.kernel.org/stable/c/cb50423e46ea585620a6be307d7f7b71587936b7
- https://git.kernel.org/stable/c/ece6cfe62a103cc6032664983be557f1b5a1ff7e
Modified: 2025-11-18
CVE-2022-50113
In the Linux kernel, the following vulnerability has been resolved: ASoc: audio-graph-card2: Fix refcount leak bug in __graph_get_type() We should call of_node_put() for the reference before its replacement as it returned by of_get_parent() which has increased the refcount. Besides, we should also call of_node_put() before return.
Modified: 2025-11-18
CVE-2022-50114
In the Linux kernel, the following vulnerability has been resolved: net: 9p: fix refcount leak in p9_read_work() error handling p9_req_put need to be called when m->rreq->rc.sdata is NULL to avoid temporary refcount leak. [Dominique: commit wording adjustments, p9_req_put argument fixes for rebase]
Modified: 2025-11-18
CVE-2022-50115
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc3-topology: Prevent double freeing of ipc_control_data via load_bytes We have sanity checks for byte controls and if any of the fail the locally allocated scontrol->ipc_control_data is freed up, but not set to NULL. On a rollback path of the error the higher level code will also try to free the scontrol->ipc_control_data which will eventually going to lead to memory corruption as double freeing memory is not a good thing.
Modified: 2025-11-18
CVE-2022-50116
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix deadlock and link starvation in outgoing data path
The current implementation queues up new control and user packets as needed
and processes this queue down to the ldisc in the same code path.
That means that the upper and the lower layer are hard coupled in the code.
Due to this deadlocks can happen as seen below while transmitting data,
especially during ldisc congestion. Furthermore, the data channels starve
the control channel on high transmission load on the ldisc.
Introduce an additional control channel data queue to prevent timeouts and
link hangups during ldisc congestion. This is being processed before the
user channel data queue in gsm_data_kick(), i.e. with the highest priority.
Put the queue to ldisc data path into a workqueue and trigger it whenever
new data has been put into the transmission queue. Change
gsm_dlci_data_sweep() accordingly to fill up the transmission queue until
TX_THRESH_HI. This solves the locking issue, keeps latency low and provides
good performance on high data load.
Note that now all packets from a DLCI are removed from the internal queue
if the associated DLCI was closed. This ensures that no data is sent by the
introduced write task to an already closed DLCI.
BUG: spinlock recursion on CPU#0, test_v24_loop/124
lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0
CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
Modified: 2025-11-18
CVE-2022-50117
In the Linux kernel, the following vulnerability has been resolved: vfio: Split migration ops from main device ops vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op. However, currently mlx5 driver sets the above ops without regards to its migration caps. This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable. As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags. HISI driver was changed as well to match this scheme. This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps.
Modified: 2025-11-18
CVE-2022-50118
In the Linux kernel, the following vulnerability has been resolved: powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt") Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SP ---truncated---
- https://git.kernel.org/stable/c/0a24ea26c3278216642a43291df7976a73a0a7ee
- https://git.kernel.org/stable/c/7e83af3dd4a3afca8f83ffde518cafd52f45b830
- https://git.kernel.org/stable/c/875b2bf469d094754ac2ba9af91dcd529eb12bf6
- https://git.kernel.org/stable/c/87b1a9175f08313f40fcb6d6dc536dbe451090eb
- https://git.kernel.org/stable/c/890005a7d98f7452cfe86dcfb2aeeb7df01132ce
Modified: 2025-11-18
CVE-2022-50120
In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. This function has two paths missing of_node_put().
Modified: 2025-11-18
CVE-2022-50121
In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. When breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the child node. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/3f83c4cf1b78331c23876977aa7b9151aff2f9e1
- https://git.kernel.org/stable/c/61cd8cd3b6b33c7eae3b45cf783b114f2ae53528
- https://git.kernel.org/stable/c/75358732af9b26acfe3e609943290bcba13330fc
- https://git.kernel.org/stable/c/cf112a52d758092ca3d5ebdad51dd17bda5ba3e5
- https://git.kernel.org/stable/c/fa220c05d282e7479abe08b54e3bdffd06c25e97
Modified: 2025-11-18
CVE-2022-50122
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix refcount leak in some error paths.
- https://git.kernel.org/stable/c/06ace427953f5036b64aed658f0055f65d76fd27
- https://git.kernel.org/stable/c/403d46971936f9f704b91cecffe66e44aa39e915
- https://git.kernel.org/stable/c/5ec83aa7a9e5bcca80ccd49978916feb4e0ffc07
- https://git.kernel.org/stable/c/79f566907d27abbd7600cebe51def5081d5796b5
- https://git.kernel.org/stable/c/994f2edeeb2114bb22b62741cb8fb030fc7e5441
- https://git.kernel.org/stable/c/e024a24fb264523149658c10c76bb363b3d0004d
- https://git.kernel.org/stable/c/e38e4952ac7a316c9002af30980d6aa850214474
- https://git.kernel.org/stable/c/efe2178d1a32492f99e7f1f2568eea5c88a85729
Modified: 2025-11-18
CVE-2022-50123
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8173: Fix refcount leak in mt8173_rt5650_rt5676_dev_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix missing of_node_put() in error paths.
- https://git.kernel.org/stable/c/540c7b7385fb110740703888b4b2bbfa06c7f79c
- https://git.kernel.org/stable/c/58567ed2878f70e0ded242cb529fb4a7618ea9f8
- https://git.kernel.org/stable/c/769399bce8825e1dcc5050dab78e15ab578baf4f
- https://git.kernel.org/stable/c/aa1214ece37944e4dbbb5cfb1d02bf37e4d89b02
- https://git.kernel.org/stable/c/aa668f8e93199cda8fa1612eb49ff70f5ecd8c92
- https://git.kernel.org/stable/c/ae4f11c1ed2d67192fdf3d89db719ee439827c11
- https://git.kernel.org/stable/c/d6d41f04640db0f946e2c3f7963bb2774afc7a0d
- https://git.kernel.org/stable/c/fab5eb31819a2693b0c3d6f3df6a0d193af9a089
Modified: 2025-11-18
CVE-2022-50124
In the Linux kernel, the following vulnerability has been resolved: ASoC: mt6797-mt6351: Fix refcount leak in mt6797_mt6351_dev_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1042353bb67cd1c9109d7481ea182c7794336458
- https://git.kernel.org/stable/c/38dc6faef05f33b4c889be8b7d65878e465c1c4b
- https://git.kernel.org/stable/c/67a28402a9e8c229c7588f214d81d52903ea06ea
- https://git.kernel.org/stable/c/7472eb8d7dd12b6b9b1a4f4527719cc9c7f5965f
- https://git.kernel.org/stable/c/7dee72b1bcecb26bfff8d6360f2169f8656dbaf6
- https://git.kernel.org/stable/c/a0381a9f3e595988e83bac4c4dd1e45ed2b3c744
- https://git.kernel.org/stable/c/b488ceb2336905f071f80627bc8a7d657274e5de
Modified: 2025-11-18
CVE-2022-50125
In the Linux kernel, the following vulnerability has been resolved: ASoC: cros_ec_codec: Fix refcount leak in cros_ec_codec_platform_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/0a034d93ee929a9ea89f3fa5f1d8492435b9ee6e
- https://git.kernel.org/stable/c/1065c385325845c88350c765cc6e449f46741984
- https://git.kernel.org/stable/c/b3e64b5562c077218295f2230fb5cf181193cb06
- https://git.kernel.org/stable/c/bae95c5aee1f67da6608ceaebfb744d900e5ffbf
- https://git.kernel.org/stable/c/ca6c9244e6c9827a0b2fe8808c5e7b1ee8ab7104
Modified: 2025-11-18
CVE-2022-50126
In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted
Following process will fail assertion 'jh->b_frozen_data == NULL' in
jbd2_journal_dirty_metadata():
jbd2_journal_commit_transaction
unlink(dir/a)
jh->b_transaction = trans1
jh->b_jlist = BJ_Metadata
journal->j_running_transaction = NULL
trans1->t_state = T_COMMIT
unlink(dir/b)
handle->h_trans = trans2
do_get_write_access
jh->b_modified = 0
jh->b_frozen_data = frozen_buffer
jh->b_next_transaction = trans2
jbd2_journal_dirty_metadata
is_handle_aborted
is_journal_aborted // return false
--> jbd2 abort <--
while (commit_transaction->t_buffers)
if (is_journal_aborted)
jbd2_journal_refile_buffer
__jbd2_journal_refile_buffer
WRITE_ONCE(jh->b_transaction,
jh->b_next_transaction)
WRITE_ONCE(jh->b_next_transaction, NULL)
__jbd2_journal_file_buffer(jh, BJ_Reserved)
J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure !
The reproducer (See detail in [Link]) reports:
------------[ cut here ]------------
kernel BUG at fs/jbd2/transaction.c:1629!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 584 Comm: unlink Tainted: G W
5.19.0-rc6-00115-g4a57a8400075-dirty #697
RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470
RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202
Call Trace:
- https://git.kernel.org/stable/c/0f61c6dc4b714be9d79cf0782ca02ba01c1b7ac3
- https://git.kernel.org/stable/c/4a734f0869f970b8a9b65062ea40b09a5da9dba8
- https://git.kernel.org/stable/c/6073389db83b903678a0920554fa19f5bdc51c48
- https://git.kernel.org/stable/c/731c1662d838fe954c6759e3ee43229b0d928fe4
- https://git.kernel.org/stable/c/ddd896792e1718cb84c96f3e618270589b6886dc
- https://git.kernel.org/stable/c/e62f79827784f56499a50ea2e893c98317b5407b
- https://git.kernel.org/stable/c/f7161d0da975adc234161cd0641d0e484f5ce375
- https://git.kernel.org/stable/c/fa5b65d39332fef7a11ae99cb1f0696012a61527
Modified: 2025-11-18
CVE-2022-50127
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix error unwind in rxe_create_qp() In the function rxe_create_qp(), rxe_qp_from_init() is called to initialize qp, internally things like the spin locks are not setup until rxe_qp_init_req(). If an error occures before this point then the unwind will call rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task() which will oops when trying to access the uninitialized spinlock. Move the spinlock initializations earlier before any failures.
- https://git.kernel.org/stable/c/1a63f24e724f677db1ab21251f4d0011ae0bb5b5
- https://git.kernel.org/stable/c/2ceeb04252e621c0b128ecc8fedbca922d11adba
- https://git.kernel.org/stable/c/3c838ca6fbdb173102780d7bdf18f2f7d9e30979
- https://git.kernel.org/stable/c/3ef491b26c720a87fcfbd78b7dc8eb83d9753fe6
- https://git.kernel.org/stable/c/b348e204a53103f51070513a7494da7c62ecbdaa
- https://git.kernel.org/stable/c/db924bd8484c76558a4ac4c4b5aeb52e857f0341
- https://git.kernel.org/stable/c/f05b7cf02123aaf99db78abfe638efefdbe15555
- https://git.kernel.org/stable/c/fd5382c5805c4bcb50fd25b7246247d3f7114733
Modified: 2025-11-18
CVE-2022-50129
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Fix a use-after-free
Change the LIO port members inside struct srpt_port from regular members
into pointers. Allocate the LIO port data structures from inside
srpt_make_tport() and free these from inside srpt_make_tport(). Keep
struct srpt_device as long as either an RDMA port or a LIO target port is
associated with it. This patch decouples the lifetime of struct srpt_port
(controlled by the RDMA core) and struct srpt_port_id (controlled by LIO).
This patch fixes the following KASAN complaint:
BUG: KASAN: use-after-free in srpt_enable_tpg+0x31/0x70 [ib_srpt]
Read of size 8 at addr ffff888141cc34b8 by task check/5093
Call Trace:
- https://git.kernel.org/stable/c/388326bb1c32fcd09371c1d494af71471ef3a04b
- https://git.kernel.org/stable/c/4ee8c39968a648d58b273582d4b021044a41ee5e
- https://git.kernel.org/stable/c/b5605148e6ce36bb21020d49010b617693933128
- https://git.kernel.org/stable/c/de95b52d9aabc979166aba81ccbe623aaf9c16a1
- https://git.kernel.org/stable/c/e60d7e2462bf57273563c4e00dbfa79ee973b9e2
Modified: 2025-11-18
CVE-2022-50130
In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: core: set smem_len before fb_deferred_io_init call The fbtft_framebuffer_alloc() calls fb_deferred_io_init() before initializing info->fix.smem_len. It is set to zero by the framebuffer_alloc() function. It will trigger a WARN_ON() at the start of fb_deferred_io_init() and the function will not do anything.
Modified: 2025-11-18
CVE-2022-50131
In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: prevent a buffer overflow in mcp_smbus_write() Smatch Warning: drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() '&mcp->txbuf[5]' too small (59 vs 255) drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() 'buf' too small (34 vs 255) The 'len' variable can take a value between 0-255 as it can come from data->block[0] and it is user data. So add an bound check to prevent a buffer overflow in memcpy().
- https://git.kernel.org/stable/c/3c0f8a59f2cc8841ee6653399a77f4f3e6e9a270
- https://git.kernel.org/stable/c/62ac2473553a00229e67bdf3cb023b62cf7f5a9a
- https://git.kernel.org/stable/c/6402116a7b5ec80fa40fd145a80c813019cd555f
- https://git.kernel.org/stable/c/66c8e816f2f2ca4a61b406503bd10bad1b35f72f
- https://git.kernel.org/stable/c/91443c669d280937968f0aa4edefa741cfe35314
Modified: 2025-11-18
CVE-2022-50132
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable() If 'ep' is NULL, result of ep_to_cdns3_ep(ep) is invalid pointer and its dereference with priv_ep->cdns3_dev may cause panic. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/7af83bb516d7aa4f96835288e4aeda21d7aa2a17
- https://git.kernel.org/stable/c/bfa0201468587072454dba7933e4a4a7be44467a
- https://git.kernel.org/stable/c/c3ffc9c4ca44bfe9562166793d133e1fb0630ea6
- https://git.kernel.org/stable/c/d342203df9f2d0851b4acd9ed577d73d10eade77
- https://git.kernel.org/stable/c/eb82c0382285ee17a9966aaab27b8becb08eb1ac
Modified: 2025-11-18
CVE-2022-50134
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: fix potential memory leak in setup_base_ctxt() setup_base_ctxt() allocates a memory chunk for uctxt->groups with hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups is not released, which will lead to a memory leak. We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups() when init_user_ctxt() fails.
- https://git.kernel.org/stable/c/1750be1e9f18787cf717c24dbc5fa029fc372a22
- https://git.kernel.org/stable/c/2f90813f1c21c3d780585390af961bd17c8515ae
- https://git.kernel.org/stable/c/90ef48a718f88935d4af53d7dadd1ceafe103ce6
- https://git.kernel.org/stable/c/a85c7dd1edadcdeca24e603a6618153a3bcc81ca
- https://git.kernel.org/stable/c/a9055dfe437efae77e28e57205437c878a03ccb7
- https://git.kernel.org/stable/c/aa2a1df3a2c85f855af7d54466ac10bd48645d63
- https://git.kernel.org/stable/c/e25b828553aecb3185a8d8d0c4f9b4e133fb5db6
- https://git.kernel.org/stable/c/fc4de8009fd6c2ca51986c6757efa964040e7d02
Modified: 2025-11-18
CVE-2022-50136
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event
If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn't
been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY
in this case. This may trigger a call trace in iw_cm. A simple way to
trigger this:
server: ib_send_lat
client: ib_send_lat -R
- https://git.kernel.org/stable/c/0066246d2d7e2619f3ecf3cf07333c59e6e7d84d
- https://git.kernel.org/stable/c/11edf0bba15ea9df49478affec7974f351bb2f6e
- https://git.kernel.org/stable/c/1434de50a5d9dab91c8ce031bc23b3e2178379c5
- https://git.kernel.org/stable/c/3056fc6c32e613b760422b94c7617ac9a24a4721
- https://git.kernel.org/stable/c/9ade92ddaf2347fb34298c02080caaa3cdd7c27b
- https://git.kernel.org/stable/c/f6e26e1a5f600b760dc32135d3fac846eabe09e7
Modified: 2025-11-18
CVE-2022-50137
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix a window for use-after-free During a destroy CQ an interrupt may cause processing of a CQE after CQ resources are freed by irdma_cq_free_rsrc(). Fix this by moving the call to irdma_cq_free_rsrc() after the irdma_sc_cleanup_ceqes(), which is called under the cq_lock.
Modified: 2025-11-18
CVE-2022-50138
In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() __qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr" is released while "mr->info.pbl_table" is not released, which will lead to a memory leak. We should release the "mr->info.pbl_table" with qedr_free_pbl() when error occurs to fix the memory leak.
- https://git.kernel.org/stable/c/07ba048df306dc93fc4d2ef670b9e24644a2069f
- https://git.kernel.org/stable/c/79ce50dddaf28b5c57911ecc80a2be17a0b17f83
- https://git.kernel.org/stable/c/7e647a8d5fc0a2c8e0f36f585a6388286a25bb15
- https://git.kernel.org/stable/c/b3236a64ddd125a455ef5b5316c1b9051b732974
- https://git.kernel.org/stable/c/b4c9f7db9f0148423557539af0fdf513338efe08
Modified: 2025-11-18
CVE-2022-50139
In the Linux kernel, the following vulnerability has been resolved: usb: aspeed-vhub: Fix refcount leak bug in ast_vhub_init_desc() We should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount.
- https://git.kernel.org/stable/c/0e0a40c803643f4edc30f0660f2f3bea4d57a99a
- https://git.kernel.org/stable/c/220fafb4ed04187e9c17be4152da5a7f2ffbdd8c
- https://git.kernel.org/stable/c/3503305225ca24c3229414c769323fb8bf39b4bf
- https://git.kernel.org/stable/c/4070f3c83cd28267f469a59751480ad39435f26a
- https://git.kernel.org/stable/c/e6db5780c2bf6e23be7b315809ef349b4b4f2213
Modified: 2025-11-18
CVE-2022-50140
In the Linux kernel, the following vulnerability has been resolved: memstick/ms_block: Fix a memory leak 'erased_blocks_bitmap' is never freed. As it is allocated at the same time as 'used_blocks_bitmap', it is likely that it should be freed also at the same time. Add the corresponding bitmap_free() in msb_data_clear().
- https://git.kernel.org/stable/c/16e07966638717416abf45393d6a80a5a1034429
- https://git.kernel.org/stable/c/37958980eb4cd71ae594ace093c11b6a91e165e8
- https://git.kernel.org/stable/c/39be95d1ff7b44c1e969af72ba9da7332dfcc1da
- https://git.kernel.org/stable/c/54eb7a55be6779c4d0c25eaf5056498a28595049
- https://git.kernel.org/stable/c/9260a154b3b5e387dbceec7c0ac441470646bc6f
- https://git.kernel.org/stable/c/961d7d12080fe70847f944d656e36cd0dd0214ba
- https://git.kernel.org/stable/c/9d8b911fe3c3ed788c66edba7c90e32a4a7a5f53
- https://git.kernel.org/stable/c/efd675246aec045507b9425c67b548cc2d782d8f
Modified: 2025-11-18
CVE-2022-50141
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer.
- https://git.kernel.org/stable/c/352377cf74710bc3368dddf78f17210dfe456933
- https://git.kernel.org/stable/c/4c472a2c9ed6ea9d272268d7f484d4303c549f1a
- https://git.kernel.org/stable/c/547db1dd98d1815574ebea7358015a17199a93bc
- https://git.kernel.org/stable/c/8b902840f6a3584f702bcb59834691b30f3d7c5a
- https://git.kernel.org/stable/c/a63d5d01e83b984b1b9c7ae8fc9c8c93697a3820
- https://git.kernel.org/stable/c/b074f1e8060836baeb0ee91181f4194b9a0ee16a
- https://git.kernel.org/stable/c/b305475df756256a186623f0991d05a816de881a
- https://git.kernel.org/stable/c/b5899a3e2f783a27b268e38d37f9b24c71bddf45
Modified: 2025-11-19
CVE-2022-50142
In the Linux kernel, the following vulnerability has been resolved:
intel_th: msu: Fix vmalloced buffers
After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there's
a chance of DMA buffer getting allocated via vmalloc(), which messes up
the mmapping code:
> RIP: msc_mmap_fault [intel_th_msu]
> Call Trace:
>
- https://git.kernel.org/stable/c/0ed72c6bc632cbf8d979ac60f982ff84b7bb610a
- https://git.kernel.org/stable/c/4914c50670b6a531e2cb17cd984cc565b4681312
- https://git.kernel.org/stable/c/566887bad7ff2297d6b3f9659c702ba075f3d62d
- https://git.kernel.org/stable/c/6ae2881c1d1fa0e33f4763b7c786f8ef05a9c828
- https://git.kernel.org/stable/c/ac12ad3ccf6d386e64a9d6a890595a2509d24edd
- https://git.kernel.org/stable/c/b5d924cb4c7b952eaa61622f14427723a78137a3
Modified: 2025-11-20
CVE-2022-50143
In the Linux kernel, the following vulnerability has been resolved: intel_th: Fix a resource leak in an error handling path If an error occurs after calling 'pci_alloc_irq_vectors()', 'pci_free_irq_vectors()' must be called as already done in the remove function.
- https://git.kernel.org/stable/c/086c28ab7c5699256aced0049aae9c42f1410313
- https://git.kernel.org/stable/c/859342220accd0d332864fafbf4e3d2d0492bc3f
- https://git.kernel.org/stable/c/9b5469573a274729bdb04b60a8d71f8d09940a31
- https://git.kernel.org/stable/c/a8f3b78b1f8e959d06801ae82149f140a75724e8
- https://git.kernel.org/stable/c/ed4d5ecb7d7fd80336afb2f9ac6685651a6aa32f
- https://git.kernel.org/stable/c/fae9da7d4c2ccad3792de03e3cac1fe2bfabb73d
Modified: 2025-11-20
CVE-2022-50144
In the Linux kernel, the following vulnerability has been resolved:
soundwire: revisit driver bind/unbind and callbacks
In the SoundWire probe, we store a pointer from the driver ops into
the 'slave' structure. This can lead to kernel oopses when unbinding
codec drivers, e.g. with the following sequence to remove machine
driver and codec driver.
/sbin/modprobe -r snd_soc_sof_sdw
/sbin/modprobe -r snd_soc_rt711
The full details can be found in the BugLink below, for reference the
two following examples show different cases of driver ops/callbacks
being invoked after the driver .remove().
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150
kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence]
kernel: RIP: 0010:mutex_lock+0x19/0x30
kernel: Call Trace:
kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae]
kernel: ? newidle_balance+0x26a/0x400
kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]
kernel: BUG: unable to handle page fault for address: ffffffffc07654c8
kernel: Workqueue: pm pm_runtime_work
kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus]
kernel: Call Trace:
kernel:
Modified: 2025-11-20
CVE-2022-50145
In the Linux kernel, the following vulnerability has been resolved: dmaengine: sf-pdma: Add multithread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 64 > /sys/module/dmatest/parameters/threads_per_chan % echo 10000 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [ 89.480664] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 89.488725] Oops [#1] [ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted 5.17.0-rc5 [ 89.509385] epc : vchan_find_desc+0x32/0x46 [ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6 This happens because of data race. Each thread rewrite channels's descriptor as soon as device_prep_dma_memcpy() is called. It leads to the situation when the driver thinks that it uses right descriptor that actually is freed or substituted for other one. With current fixes a descriptor changes its value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. Now it is just possible to queue a descriptor for further processing.
- https://git.kernel.org/stable/c/4c7350b1dd8a192af844de32fc99b9e34c876fda
- https://git.kernel.org/stable/c/5ab2782c944e324008ef5d658f2494a9f0e3c5ac
- https://git.kernel.org/stable/c/a93b3f1e11971a91b6441b6d47488f4492cc113f
- https://git.kernel.org/stable/c/b2cc5c465c2cb8ab697c3fd6583c614e3f6cfbcc
- https://git.kernel.org/stable/c/b9b4992f897be9b0b9e3a3b956cab6b75ccc3f11
Modified: 2025-11-17
CVE-2022-50146
In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors If dw_pcie_ep_init() fails to perform any action after the EPC memory is initialized and the MSI memory region is allocated, the latter parts won't be undone thus causing a memory leak. Add a cleanup-on-error path to fix these leaks. [bhelgaas: commit log]
- https://git.kernel.org/stable/c/2d546db5c80c45cac3ccd929550244fd58f4ff58
- https://git.kernel.org/stable/c/3b453f5d06d1f1d6b20a75ea51dc7b53ae78f479
- https://git.kernel.org/stable/c/8161e9626b50892eaedbd8070ecb1586ecedb109
- https://git.kernel.org/stable/c/b03a8f1264ea8c363bec9ef6e37b467f27cb04ea
- https://git.kernel.org/stable/c/e7599a5974d4c64eaae8009c3f2e47b9e3223e07
Modified: 2025-11-17
CVE-2022-50147
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix get_nodes out of bound access When user specified more nodes than supported, get_nodes will access nmask array out of bounds.
Modified: 2025-11-17
CVE-2022-50148
In the Linux kernel, the following vulnerability has been resolved: kernfs: fix potential NULL dereference in __kernfs_remove When lockdep is enabled, lockdep_assert_held_write would cause potential NULL pointer dereference. Fix the following smatch warnings: fs/kernfs/dir.c:1353 __kernfs_remove() warn: variable dereferenced before check 'kn' (see line 1346)
Modified: 2025-11-17
CVE-2022-50149
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
In __driver_attach function, The lock holding logic is as follows:
...
__driver_attach
if (driver_allows_async_probing(drv))
device_lock(dev) // get lock dev
async_schedule_dev(__driver_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__driver_attach_async_helper will get lock dev as
will, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As above show, when it is allowed to do async probes, because of
out of memory or work limit, async work is not be allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__driver_attach_async_helper getting lock dev.
Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:
0 flags:0x00004000
[ 370.788865] Call Trace:
[ 370.789374]
- https://git.kernel.org/stable/c/37f908038402c9b8325763f306a1c65d88757e15
- https://git.kernel.org/stable/c/70fe758352cafdee72a7b13bf9db065f9613ced8
- https://git.kernel.org/stable/c/733ab0c19bf17f6ad7c2b580ede006e369d5ab1b
- https://git.kernel.org/stable/c/779b634714c51d05baaeff4868ce2fd9fc7399bf
- https://git.kernel.org/stable/c/8191b6cd9ada09b675f17446d5872eb1f77685cb
- https://git.kernel.org/stable/c/a93f33aeef4e6a94ae9c9d3f5b2f9085ad0572ec
Modified: 2025-11-20
CVE-2022-50151
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix random warning message when driver load Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] ___slab_alloc.part.108+0x4d4/0x748 [ 4.191419] __slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0 pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(*page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... } kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning. GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely.
Modified: 2025-11-20
CVE-2022-50152
In the Linux kernel, the following vulnerability has been resolved: usb: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/302970b4cad3ebfda2c05ce06c322ccdc447d17e
- https://git.kernel.org/stable/c/4db00c2fa6f8c9876a7e20511dccf43b50be9006
- https://git.kernel.org/stable/c/50238c4b54c2ac6c2da7a84a4a2b0a570e3da0e2
- https://git.kernel.org/stable/c/59026d5cc615da28e0c9806a71bf07065c906464
- https://git.kernel.org/stable/c/591ab8dbf6c21927f23f83ddb90691f48b86d136
- https://git.kernel.org/stable/c/65d36ec409b635dfc2f95f0d7c5877c9d0cb7630
- https://git.kernel.org/stable/c/a0fbac3bf26a11f084233519ddf3fd5e5bb28939
- https://git.kernel.org/stable/c/d35903e9650f4fa79426ce390db8678dbf5ac432
Modified: 2025-11-25
CVE-2022-50153
In the Linux kernel, the following vulnerability has been resolved: usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/038453b17fe30ea38f0f3c916e2ae2b7f8cef84e
- https://git.kernel.org/stable/c/3a50c917c67dd0bc39c14de4a8b75a1d50fdce66
- https://git.kernel.org/stable/c/585d22a5624ef2b540c337665c72fea8cd33db50
- https://git.kernel.org/stable/c/8cbc3870ff356366842af3228dd8e7bc278e5edd
- https://git.kernel.org/stable/c/8e51a512c1079109bec4c80915e647692d583e79
- https://git.kernel.org/stable/c/b5c5b13cb45e2c88181308186b0001992cb41954
- https://git.kernel.org/stable/c/b9c4a480cb0ada07154debf681454cbb55e30b59
- https://git.kernel.org/stable/c/c0a4b454486b23bb4d94ce49f490830ecc354040
Modified: 2025-11-25
CVE-2022-50154
In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek-gen3: Fix refcount leak in mtk_pcie_init_irq_domains() of_get_child_by_name() returns a node pointer with refcount incremented, so we should use of_node_put() on it when we don't need it anymore. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-21
CVE-2022-50155
In the Linux kernel, the following vulnerability has been resolved: mtd: parsers: ofpart: Fix refcount leak in bcm4908_partitions_fw_offset of_find_node_by_path() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-25
CVE-2022-50156
In the Linux kernel, the following vulnerability has been resolved: HID: cp2112: prevent a buffer overflow in cp2112_xfer() Smatch warnings: drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'data->block[1]' too small (33 vs 255) drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'buf' too small (64 vs 255) The 'read_length' variable is provided by 'data->block[0]' which comes from user and it(read_length) can take a value between 0-255. Add an upper bound to 'read_length' variable to prevent a buffer overflow in memcpy().
- https://git.kernel.org/stable/c/26e427ac85c2b8d0d108cc80b6de34d33e2780c4
- https://git.kernel.org/stable/c/381583845d19cb4bd21c8193449385f3fefa9caf
- https://git.kernel.org/stable/c/3af7d60e9a6c17d6d41c4341f8020511887d372d
- https://git.kernel.org/stable/c/519ff31a6ddd87aa4905bd9bf3b92e8b88801614
- https://git.kernel.org/stable/c/8489a20ac481b08c0391608d81ed3796d373cfdf
- https://git.kernel.org/stable/c/e7028944e61014ae915e7fb74963d3835f2f761a
- https://git.kernel.org/stable/c/ebda3d6b004bb6127a66a616524a2de152302ca7
Modified: 2025-11-25
CVE-2022-50157
In the Linux kernel, the following vulnerability has been resolved: PCI: microchip: Fix refcount leak in mc_pcie_init_irq_domains() of_get_next_child() returns a node pointer with refcount incremented, so we should use of_node_put() on it when we don't need it anymore. mc_pcie_init_irq_domains() only calls of_node_put() in the normal path, missing it in some error paths. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-25
CVE-2022-50158
In the Linux kernel, the following vulnerability has been resolved: mtd: partitions: Fix refcount leak in parse_redboot_of of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/55d0f7da66dec93c4d53d0886a1555618079a900
- https://git.kernel.org/stable/c/7ec48ac18d8f9e002ce9bfbad32741086739e499
- https://git.kernel.org/stable/c/8ea607579d300b2f7fc997f3dd20949114565fcd
- https://git.kernel.org/stable/c/9f7e62815cf3cbbcb1b8cb21649fb4dfdb3aa016
- https://git.kernel.org/stable/c/e24af43d0cbe9f6aaa413c15ccce50bbbfd61e0e
- https://git.kernel.org/stable/c/f3cc27198c5d78cdda60a55ae749f815cd1fe5eb
Modified: 2025-11-25
CVE-2022-50159
In the Linux kernel, the following vulnerability has been resolved:
of: check previous kernel's ima-kexec-buffer against memory bounds
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:
$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
Modified: 2025-11-18
CVE-2022-50160
In the Linux kernel, the following vulnerability has been resolved: mtd: maps: Fix refcount leak in ap_flash_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/77087a04c8fd554134bddcb8a9ff87b21f357926
- https://git.kernel.org/stable/c/80b1465b2ae81ebb59bbe62bcb7a7f7d4e9ece6f
- https://git.kernel.org/stable/c/941ef6997f9db704fe4fd62fc01e420fdd5048b2
- https://git.kernel.org/stable/c/995fb2874bb5696357846a91e59181c600e6aac8
- https://git.kernel.org/stable/c/a74322d4b897ddc268b340c4a397f6066c2f945d
- https://git.kernel.org/stable/c/babd7b0124650ab71a6487e38588b8659b3aa2dc
- https://git.kernel.org/stable/c/d10855876a6f47add6ff621cef25cc0171dac162
- https://git.kernel.org/stable/c/d5730780e9ea84e5476752a47c749036c6a74af5
Modified: 2025-11-18
CVE-2022-50161
In the Linux kernel, the following vulnerability has been resolved: mtd: maps: Fix refcount leak in of_flash_probe_versatile of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/33ec82a6d2b119938f26e5c8040ed5d92378eb54
- https://git.kernel.org/stable/c/3c8de6a838b7e0eb392754ac89dd66e698684342
- https://git.kernel.org/stable/c/4d67c8f74d804b20febf716ec96e9a475457ec60
- https://git.kernel.org/stable/c/52ae2b14f76ef2d490337ddc0037bc37125be7b8
- https://git.kernel.org/stable/c/5d5ddd8771fa9cabeb247fba5f6ab60d63f3fbce
- https://git.kernel.org/stable/c/79e57889aa0d92a6d769bad808fb105e7b6ea495
- https://git.kernel.org/stable/c/9124d51e01232a91da4034768a2a8d1688472179
- https://git.kernel.org/stable/c/f516fbb63873ee23cba5b7c3d239677c30f13df8
Modified: 2025-11-18
CVE-2022-50162
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: Fix possible refcount leak in if_usb_probe() usb_get_dev will be called before lbs_get_firmware_async which means that usb_put_dev need to be called when lbs_get_firmware_async fails.
- https://git.kernel.org/stable/c/00d0c4e59c0f8ad1f86874bb64b220394e687028
- https://git.kernel.org/stable/c/4c8e2f9ce1428e44cb103035eeced7aeb6b80980
- https://git.kernel.org/stable/c/5b92f406a5199b6b01dc664b9226d824ae2835f0
- https://git.kernel.org/stable/c/61b2ec97487399c58ae2e34f250f4884e671799b
- https://git.kernel.org/stable/c/6fd57e1d120bf13d4dc6c200a7cf914e6347a316
- https://git.kernel.org/stable/c/878e7f39803a9ab5bb9766956a7a04351d4bf99d
- https://git.kernel.org/stable/c/97e5d3e46a3a2100253a9717a4df98d68aeb10b8
- https://git.kernel.org/stable/c/d7365590d15bbd9008f424ef043d1778ffe29f42
Modified: 2025-11-18
CVE-2022-50163
In the Linux kernel, the following vulnerability has been resolved:
ax25: fix incorrect dev_tracker usage
While investigating a separate rose issue [1], and enabling
CONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reported an orthogonal ax25 issue [2]
An ax25_dev can be used by one (or many) struct ax25_cb.
We thus need different dev_tracker, one per struct ax25_cb.
After this patch is applied, we are able to focus on rose.
[1] https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/
[2]
[ 205.798723] reference already released.
[ 205.798732] allocated in:
[ 205.798734] ax25_bind+0x1a2/0x230 [ax25]
[ 205.798747] __sys_bind+0xea/0x110
[ 205.798753] __x64_sys_bind+0x18/0x20
[ 205.798758] do_syscall_64+0x5c/0x80
[ 205.798763] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 205.798768] freed in:
[ 205.798770] ax25_release+0x115/0x370 [ax25]
[ 205.798778] __sock_release+0x42/0xb0
[ 205.798782] sock_close+0x15/0x20
[ 205.798785] __fput+0x9f/0x260
[ 205.798789] ____fput+0xe/0x10
[ 205.798792] task_work_run+0x64/0xa0
[ 205.798798] exit_to_user_mode_prepare+0x18b/0x190
[ 205.798804] syscall_exit_to_user_mode+0x26/0x40
[ 205.798808] do_syscall_64+0x69/0x80
[ 205.798812] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 205.798827] ------------[ cut here ]------------
[ 205.798829] WARNING: CPU: 2 PID: 2605 at lib/ref_tracker.c:136 ref_tracker_free.cold+0x60/0x81
[ 205.798837] Modules linked in: rose netrom mkiss ax25 rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_hda_codec_hdmi nls_iso8859_1 i915 rtw88_8821ce rtw88_8821c x86_pkg_temp_thermal rtw88_pci intel_powerclamp rtw88_core snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp snd_hda_intel kvm_intel snd_intel_dspcfg mac80211 snd_hda_codec kvm i2c_algo_bit drm_buddy drm_dp_helper btusb drm_kms_helper snd_hwdep btrtl snd_hda_core btbcm joydev crct10dif_pclmul btintel crc32_pclmul ghash_clmulni_intel mei_hdcp btmtk intel_rapl_msr aesni_intel bluetooth input_leds snd_pcm crypto_simd syscopyarea processor_thermal_device_pci_legacy sysfillrect cryptd intel_soc_dts_iosf snd_seq sysimgblt ecdh_generic fb_sys_fops rapl libarc4 processor_thermal_device intel_cstate processor_thermal_rfim cec snd_timer ecc snd_seq_device cfg80211 processor_thermal_mbox mei_me processor_thermal_rapl mei rc_core at24 snd intel_pch_thermal intel_rapl_common ttm soundcore int340x_thermal_zone video
[ 205.798948] mac_hid acpi_pad sch_fq_codel ipmi_devintf ipmi_msghandler drm msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 hid_generic usbhid hid i2c_i801 i2c_smbus r8169 xhci_pci ahci libahci realtek lpc_ich xhci_pci_renesas [last unloaded: ax25]
[ 205.798992] CPU: 2 PID: 2605 Comm: ax25ipd Not tainted 5.18.11-F6BVP #3
[ 205.798996] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020
[ 205.798999] RIP: 0010:ref_tracker_free.cold+0x60/0x81
[ 205.799005] Code: e8 d2 01 9b ff 83 7b 18 00 74 14 48 c7 c7 2f d7 ff 98 e8 10 6e fc ff 8b 7b 18 e8 b8 01 9b ff 4c 89 ee 4c 89 e7 e8 5d fd 07 00 <0f> 0b b8 ea ff ff ff e9 30 05 9b ff 41 0f b6 f7 48 c7 c7 a0 fa 4e
[ 205.799008] RSP: 0018:ffffaf5281073958 EFLAGS: 00010286
[ 205.799011] RAX: 0000000080000000 RBX: ffff9a0bd687ebe0 RCX: 0000000000000000
[ 205.799014] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 00000000ffffffff
[ 205.799016] RBP: ffffaf5281073a10 R08: 0000000000000003 R09: fffffffffffd5618
[ 205.799019] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff9a0bc53384d0
[ 205.799022] R13: 0000000000000282 R14: 00000000ae000001 R15: 0000000000000001
[ 205.799024] FS: 0000000000000000(0000) GS:ffff9a0d0f300000(0000) knlGS:0000000000000000
[ 205.799028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 205.799031] CR2: 00007ff6b8311554 CR3: 000000001ac10004 CR4: 00000000001706e0
[ 205.799033] Call Trace:
[ 205.799035]
Modified: 2025-11-18
CVE-2022-50164
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix double list_add at iwl_mvm_mac_wake_tx_queue
After successfull station association, if station queues are disabled for
some reason, the related lists are not emptied. So if some new element is
added to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old
one and produce a BUG like this:
[ 46.535263] list_add corruption. prev->next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388).
[ 46.535283] ------------[ cut here ]------------
[ 46.535284] kernel BUG at lib/list_debug.c:26!
[ 46.535290] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 46.585304] CPU: 0 PID: 623 Comm: wpa_supplicant Not tainted 5.19.0-rc3+ #1
[ 46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012
[ 46.600336] RIP: 0010:__list_add_valid.cold+0x3d/0x3f
[ 46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff <0f> 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1
[ 46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286
[ 46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000
[ 46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff
[ 46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666
[ 46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388
[ 46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0
[ 46.666108] FS: 00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000
[ 46.674331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0
[ 46.687422] Call Trace:
[ 46.689906]
- https://git.kernel.org/stable/c/14a3aacf517a9de725dd3219dbbcf741e31763c4
- https://git.kernel.org/stable/c/182d3c1385f44ba7c508bf5b1292a7fe96ad4e9e
- https://git.kernel.org/stable/c/38d71acc15a2e72806b516380af0adb3830d4639
- https://git.kernel.org/stable/c/4a40af2b0b9517fca7ae2a030c9c0a16836303c0
- https://git.kernel.org/stable/c/5cca5f714fe6cedd2df9d8451ad8df21e6464f62
- https://git.kernel.org/stable/c/ff068c25bf90d26f0aee1751553f18076b797e8d
Modified: 2025-11-17
CVE-2022-50165
In the Linux kernel, the following vulnerability has been resolved: wifi: wil6210: debugfs: fix uninitialized variable use in `wil_write_file_wmi()` Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user() but it forgets to change the value to be returned that came from simple_write_to_buffer() call. It results in the following warning: warning: variable 'rc' is uninitialized when used here [-Wuninitialized] return rc; ^~ Remove rc variable and just return the passed in length if the memdup_user() succeeds.
- https://git.kernel.org/stable/c/409bd72e544fdf4809ea0dac337bb5a1f11a25a9
- https://git.kernel.org/stable/c/52b11a48cf073e0aab923ae809a765d756cecf13
- https://git.kernel.org/stable/c/689e5caf63e99e15d2f485ec297c1bf9243e0e28
- https://git.kernel.org/stable/c/6c5fee83bdbeffe8d607d1ab125122a75f40bd1a
- https://git.kernel.org/stable/c/b13c84e877d7a3095bacb14665db304b2c00e95f
- https://git.kernel.org/stable/c/c9fde3a44da566d8929070ab6bda4f0dfa9955d0
- https://git.kernel.org/stable/c/d4742c886043b69d2d058bfde3998ef333b66595
- https://git.kernel.org/stable/c/d578e0af3a003736f6c440188b156483d451b329
Modified: 2025-11-17
CVE-2022-50166
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: When HCI work queue is drained, only queue chained work
The HCI command, event, and data packet processing workqueue is drained
to avoid deadlock in commit
76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").
There is another delayed work, which will queue command to this drained
workqueue. Which results in the following error report:
Bluetooth: hci2: command 0x040f tx timeout
WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140
Workqueue: events hci_cmd_timeout
RIP: 0010:__queue_work+0xdad/0x1140
RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093
RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000
RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08
RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700
R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60
R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800
FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-17
CVE-2022-50167
In the Linux kernel, the following vulnerability has been resolved: bpf: fix potential 32-bit overflow when accessing ARRAY map element If BPF array map is bigger than 4GB, element pointer calculation can overflow because both index and elem_size are u32. Fix this everywhere by forcing 64-bit multiplication. Extract this formula into separate small helper and use it consistently in various places. Speculative-preventing formula utilizing index_mask trick is left as is, but explicit u64 casts are added in both places.
Modified: 2025-12-03
CVE-2022-50168
In the Linux kernel, the following vulnerability has been resolved: bpf, x86: fix freeing of not-finalized bpf_prog_pack syzbot reported a few issues with bpf_prog_pack [1], [2]. This only happens with multiple subprogs. In jit_subprogs(), we first call bpf_int_jit_compile() on each sub program. And then, we call it on each sub program again. jit_data is not freed in the first call of bpf_int_jit_compile(). Similarly we don't call bpf_jit_binary_pack_finalize() in the first call of bpf_int_jit_compile(). If bpf_int_jit_compile() failed for one sub program, we will call bpf_jit_binary_pack_finalize() for this sub program. However, we don't have a chance to call it for other sub programs. Then we will hit "goto out_free" in jit_subprogs(), and call bpf_jit_free on some subprograms that haven't got bpf_jit_binary_pack_finalize() yet. At this point, bpf_jit_binary_pack_free() is called and the whole 2MB page is freed erroneously. Fix this with a custom bpf_jit_free() for x86_64, which calls bpf_jit_binary_pack_finalize() if necessary. Also, with custom bpf_jit_free(), bpf_prog_aux->use_bpf_prog_pack is not needed any more, remove it. [1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f [2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445
Modified: 2026-01-23
CVE-2022-50169
In the Linux kernel, the following vulnerability has been resolved: wifi: wil6210: debugfs: fix info leak in wil_write_file_wmi() The simple_write_to_buffer() function will succeed if even a single byte is initialized. However, we need to initialize the whole buffer to prevent information leaks. Just use memdup_user().
- https://git.kernel.org/stable/c/05ceda14ef7c73104e709c414c3680d8a59f51d4
- https://git.kernel.org/stable/c/074e865b37da55aa87baa16d68b96896f85f8adb
- https://git.kernel.org/stable/c/4615458db7793fadc6d546ac3564b36819e77a22
- https://git.kernel.org/stable/c/60c9983425167ec5073c628d83a6875760d18059
- https://git.kernel.org/stable/c/67470920cd3f3cb38699b1ad23234f96bead4d21
- https://git.kernel.org/stable/c/789edc1af9c1a2293956e8534bfef3d18d629de9
- https://git.kernel.org/stable/c/7a4836560a6198d245d5732e26f94898b12eb760
- https://git.kernel.org/stable/c/c1216e699a1ce83ea005510844bd7508d34c6cef
Modified: 2025-11-28
CVE-2022-50170
In the Linux kernel, the following vulnerability has been resolved: kunit: executor: Fix a memory leak on failure in kunit_filter_tests It's possible that memory allocation for 'filtered' will fail, but for the copy of the suite to succeed. In this case, the copy could be leaked. Properly free 'copy' in the error case for the allocation of 'filtered' failing. Note that there may also have been a similar issue in kunit_filter_subsuites, before it was removed in "kunit: flatten kunit_suite*** to kunit_suite** in .kunit_test_suites". This was reported by clang-analyzer via the kernel test robot, here: https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/ And by smatch via Dan Carpenter and the kernel test robot: https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/
Modified: 2025-11-28
CVE-2022-50171
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - don't sleep when in softirq When kunpeng920 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. The kernel will report the following error: BUG: scheduling while atomic: swapper/57/0/0x00000300 Call trace: dump_backtrace+0x0/0x1e4 show_stack+0x20/0x2c dump_stack+0xd8/0x140 __schedule_bug+0x68/0x80 __schedule+0x728/0x840 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x24 __mutex_lock.constprop.0+0x594/0x5dc __mutex_lock_slowpath+0x1c/0x30 mutex_lock+0x50/0x60 sec_request_init+0x8c/0x1a0 [hisi_sec2] sec_process+0x28/0x1ac [hisi_sec2] sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2] sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2] crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp_output_tail+0x348/0x5c0 [esp4] esp_output+0x120/0x19c [esp4] xfrm_output_one+0x25c/0x4d4 xfrm_output_resume+0x6c/0x1fc xfrm_output+0xac/0x3c0 xfrm4_output+0x64/0x130 ip_build_and_send_pkt+0x158/0x20c tcp_v4_send_synack+0xdc/0x1f0 tcp_conn_request+0x7d0/0x994 tcp_v4_conn_request+0x58/0x6c tcp_v6_conn_request+0xf0/0x100 tcp_rcv_state_process+0x1cc/0xd60 tcp_v4_do_rcv+0x10c/0x250 tcp_v4_rcv+0xfc4/0x10a4 ip_protocol_deliver_rcu+0xf4/0x200 ip_local_deliver_finish+0x58/0x70 ip_local_deliver+0x68/0x120 ip_sublist_rcv_finish+0x70/0x94 ip_list_rcv_finish.constprop.0+0x17c/0x1d0 ip_sublist_rcv+0x40/0xb0 ip_list_rcv+0x140/0x1dc __netif_receive_skb_list_core+0x154/0x28c __netif_receive_skb_list+0x120/0x1a0 netif_receive_skb_list_internal+0xe4/0x1f0 napi_complete_done+0x70/0x1f0 gro_cell_poll+0x9c/0xb0 napi_poll+0xcc/0x264 net_rx_action+0xd4/0x21c __do_softirq+0x130/0x358 irq_exit+0x11c/0x13c __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x78/0x2c0 el1_irq+0xb8/0x140 arch_cpu_idle+0x18/0x40 default_idle_call+0x5c/0x1c0 cpuidle_idle_call+0x174/0x1b0 do_idle+0xc8/0x160 cpu_startup_entry+0x30/0x11c secondary_start_kernel+0x158/0x1e4 softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with preempt_count 00000100, exited with fffffe00?
- https://git.kernel.org/stable/c/02884a4f12de11f54d4ca67a07dd1f111d96fdbd
- https://git.kernel.org/stable/c/16e18a8ac7c9748cf35a8d2f0ba2c6e8850e7568
- https://git.kernel.org/stable/c/4a461ba5b9753352f438824fdd915cba675b1733
- https://git.kernel.org/stable/c/aa495dfe71229b9034b59d8072ff0b2325ddd5ee
- https://git.kernel.org/stable/c/c9be45e4c69fde36522274f04d1aa0d097ae3958
Modified: 2025-11-28
CVE-2022-50172
In the Linux kernel, the following vulnerability has been resolved: mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine.
- https://git.kernel.org/stable/c/2f53ba46d8c97aca681adbe5098e1f84580c446d
- https://git.kernel.org/stable/c/3ad958bc488e3ecb0207d31621c00efb86f17482
- https://git.kernel.org/stable/c/cffd93411575afd987788e2ec3cb8eaff70f0215
- https://git.kernel.org/stable/c/da1ab462b96c5d47a0755aec957bae3d685538c5
- https://git.kernel.org/stable/c/f1609c4f4a21777e081b36596224802b85052ad9
Modified: 2025-11-28
CVE-2022-50173
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Fix global state lock backoff We need to grab the lock after the early return for !hwpipe case. Otherwise, we could have hit contention yet still returned 0. Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged in CI: WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock+0xf8/0x154 lr : drm_atomic_get_private_obj_state+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drm_modeset_lock+0xf8/0x154 drm_atomic_get_private_obj_state+0x84/0x170 mdp5_get_global_state+0x54/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x2ec/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x148/0x154 mdp5_get_global_state+0x30/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x290/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 drm_atomic_check_only+0x4b0/0x8f4 drm_atomic_commit+0x68/0xe0 Patchwork: https://patchwork.freedesktop.org/patch/492701/
- https://git.kernel.org/stable/c/0b07f28c23ff50a7fa5dbc3f6b3b6bd53ac9fc70
- https://git.kernel.org/stable/c/247f2934324f9a18d18df24ea4bfcc7d4631d0ef
- https://git.kernel.org/stable/c/2e34d6c8180a398de6448a93df25068bf3062042
- https://git.kernel.org/stable/c/2fdf5a54ef9376ff69149a48c5616f1141008c9f
- https://git.kernel.org/stable/c/92ef86ab513593c6329d04146e61f9a670e72fc5
- https://git.kernel.org/stable/c/bf386c955f35a0a01bef482b6035d40ff2f6cc75
- https://git.kernel.org/stable/c/f4e3a8c7e890049e7ba2b49ad0315dae841dfa55
Modified: 2025-11-28
CVE-2022-50174
In the Linux kernel, the following vulnerability has been resolved: net: hinic: avoid kernel hung in hinic_get_stats64() When using hinic device as a bond slave device, and reading device stats of master bond device, the kernel may hung. The kernel panic calltrace as follows: Kernel panic - not syncing: softlockup: hung tasks Call trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324 When getting device stats from bond, kernel will call bond_get_stats(). It first holds the spinlock bond->stats_lock, and then call hinic_get_stats64() to collect hinic device's stats. However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to protect its critical section, which may schedule current task out. And if system is under high pressure, the task cannot be woken up immediately, which eventually triggers kernel hung panic. Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local variable in hinic_get_stats64(), there is nothing need to be protected by lock, so just removing down()/up() is ok.
- https://git.kernel.org/stable/c/3ba59bbe4f306bb6ee15753db0a40564c0eb7909
- https://git.kernel.org/stable/c/693f31dc91568e61047fd2980a8235e856cd9ce8
- https://git.kernel.org/stable/c/98f9fcdee35add80505b6c73f72de5f750d5c03c
- https://git.kernel.org/stable/c/e74f3097a9c713ce855cda07713393bcc23a005d
- https://git.kernel.org/stable/c/fced5bce712122654ec8a20356342698cce104d2
Modified: 2025-11-28
CVE-2022-50175
In the Linux kernel, the following vulnerability has been resolved: media: tw686x: Fix memory leak in tw686x_video_init video_device_alloc() allocates memory for vdev, when video_register_device() fails, it doesn't release the memory and leads to memory leak, call video_device_release() to fix this.
- https://git.kernel.org/stable/c/0597bcf774896a002edcc7934a9cdbb932b66702
- https://git.kernel.org/stable/c/611f86965df013d6021e6cd0d155b1734ad2cf21
- https://git.kernel.org/stable/c/8b412db51db24dfba22c96948580d4a12f831397
- https://git.kernel.org/stable/c/c142a7531b90c6b0f946c82d3f504b3f36a207df
- https://git.kernel.org/stable/c/e0b212ec9d8177d6f7c404315293f6a085d6ee42
Modified: 2025-11-25
CVE-2022-50176
In the Linux kernel, the following vulnerability has been resolved: drm/mcde: Fix refcount leak in mcde_dsi_bind Every iteration of for_each_available_child_of_node() decrements the reference counter of the previous node. There is no decrement when break out from the loop and results in refcount leak. Add missing of_node_put() to fix this.
- https://git.kernel.org/stable/c/3123ae6fdd4013d24a3a4877084b14e917faae5c
- https://git.kernel.org/stable/c/32c827e30bb44ae809950a9efab59e98e44d30e5
- https://git.kernel.org/stable/c/3a149169e4a2f9127022fec6ef5d71b4e804b3b9
- https://git.kernel.org/stable/c/7214902de5b1fb2b632a7b8b3b9540e41aabab38
- https://git.kernel.org/stable/c/87c35bbefdfa3c5edfb8c80f5c04717aaacc629d
- https://git.kernel.org/stable/c/f57699a9b66ea11f000f56d1f1179059239b8690
Modified: 2025-11-28
CVE-2022-50177
In the Linux kernel, the following vulnerability has been resolved:
rcutorture: Fix ksoftirqd boosting timing and iteration
The RCU priority boosting can fail in two situations:
1) If (nr_cpus= > maxcpus=), which means if the total number of CPUs
is higher than those brought online at boot, then torture_onoff() may
later bring up CPUs that weren't online on boot. Now since rcutorture
initialization only boosts the ksoftirqds of the CPUs that have been
set online on boot, the CPUs later set online by torture_onoff won't
benefit from the boost, making RCU priority boosting fail.
2) The ksoftirqd kthreads are boosted after the creation of
rcu_torture_boost() kthreads, which opens a window large enough for these
rcu_torture_boost() kthreads to wait (despite running at FIFO priority)
for ksoftirqds that are still running at SCHED_NORMAL priority.
The issues can trigger for example with:
./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y"
[ 34.968561] rcu-torture: !!!
[ 34.968627] ------------[ cut here ]------------
[ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610
[ 35.052043] Modules linked in:
[ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1
[ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
[ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610
[ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82
[ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202
[ 37.277320] rcu: De-offloading 8
[ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001
[ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff
[ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff
[ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20
[ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0
[ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000
[ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0
[ 37.290470] Call Trace:
[ 37.295049]
Modified: 2025-11-28
CVE-2022-50178
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: 8852a: rfk: fix div 0 exception
The DPK is a kind of RF calibration whose algorithm is to fine tune
parameters and calibrate, and check the result. If the result isn't good
enough, it could adjust parameters and try again.
This issue is to read and show the result, but it could be a negative
calibration result that causes divisor 0 and core dump. So, fix it by
phy_div() that does division only if divisor isn't zero; otherwise,
zero is adopted.
divide error: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1
Modified: 2025-11-20
CVE-2022-50179
In the Linux kernel, the following vulnerability has been resolved:
ath9k: fix use-after-free in ath9k_hif_usb_rx_cb
Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The
problem was in incorrect htc_handle->drv_priv initialization.
Probable call trace which can trigger use-after-free:
ath9k_htc_probe_device()
/* htc_handle->drv_priv = priv; */
ath9k_htc_wait_for_target() <--- Failed
ieee80211_free_hw() <--- priv pointer is freed
- https://git.kernel.org/stable/c/03ca957c5f7b55660957eda20b5db4110319ac7a
- https://git.kernel.org/stable/c/0ac4827f78c7ffe8eef074bc010e7e34bc22f533
- https://git.kernel.org/stable/c/62bc1ea5c7401d77eaf73d0c6a15f3d2e742856e
- https://git.kernel.org/stable/c/6b14ab47937ba441e75e8dbb9fbfc9c55efa41c6
- https://git.kernel.org/stable/c/ab7a0ddf5f1cdec63cb21840369873806fc36d80
- https://git.kernel.org/stable/c/b66ebac40f64336ae2d053883bee85261060bd27
- https://git.kernel.org/stable/c/e9e21206b8ea62220b486310c61277e7ebfe7cec
- https://git.kernel.org/stable/c/eccd7c3e2596b574241a7670b5b53f5322f470e5
Modified: 2025-11-20
CVE-2022-50181
In the Linux kernel, the following vulnerability has been resolved: virtio-gpu: fix a missing check to avoid NULL dereference 'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset() and it will lead to a NULL dereference by a lately use of it (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check. [ kraxel: minor codestyle fixup ]
- https://git.kernel.org/stable/c/259773fc874258606c0121767a4a27466ff337eb
- https://git.kernel.org/stable/c/367882a5a9448b5e1ba756125308092d614cb96c
- https://git.kernel.org/stable/c/39caef09666c1d8274abf9472c72bcac236dc5fb
- https://git.kernel.org/stable/c/adbdd21983fa292e53aec3eab97306b2961ea887
- https://git.kernel.org/stable/c/bd63f11f4c3c46afec07d821f74736161ff6e526
Modified: 2025-11-19
CVE-2022-50182
In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Align upwards buffer size The hardware can support any image size WxH, with arbitrary W (image width) and H (image height) dimensions. Align upwards buffer size for both encoder and decoder. and leave the picture resolution unchanged. For decoder, the risk of memory out of bounds can be avoided. For both encoder and decoder, the driver will lift the limitation of resolution alignment. For example, the decoder can support jpeg whose resolution is 227x149 the encoder can support nv12 1080P, won't change it to 1920x1072.
Modified: 2025-11-19
CVE-2022-50183
In the Linux kernel, the following vulnerability has been resolved: drm/meson: encoder_cvbs: Fix refcount leak in meson_encoder_cvbs_init of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-19
CVE-2022-50184
In the Linux kernel, the following vulnerability has been resolved: drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_init of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
Modified: 2025-11-19
CVE-2022-50185
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers() The last case label can write two buffers 'mc_reg_address[j]' and 'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE since there are no checks for this value in both case labels after the last 'j++'. Instead of changing '>' to '>=' there, add the bounds check at the start of the second 'case' (the first one already has it). Also, remove redundant last checks for 'j' index bigger than array size. The expression is always false. Moreover, before or after the patch 'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it seems it can be a valid value. Detected using the static analysis tool - Svace.
- https://git.kernel.org/stable/c/136f614931a2bb73616b292cf542da3a18daefd5
- https://git.kernel.org/stable/c/1f341053852be76f82610ce47a505d930512f05c
- https://git.kernel.org/stable/c/782e413e38dffd37cc85b08b1ccb982adb4a93ce
- https://git.kernel.org/stable/c/8508d6d23a247c29792ce2fc0df3f3404d6a6a80
- https://git.kernel.org/stable/c/9faff03617afeced1c4e5daa89e79b3906374342
- https://git.kernel.org/stable/c/db1a9add3f90ff1c641974d5bb910c16b87af4ef
- https://git.kernel.org/stable/c/deb603c5928e546609c0d5798e231d0205748943
- https://git.kernel.org/stable/c/ea73869df6ef386fc0feeb28ff66742ca835b18f
Modified: 2025-11-19
CVE-2022-50186
In the Linux kernel, the following vulnerability has been resolved: ath11k: fix missing skb drop on htc_tx_completion error On htc_tx_completion error the skb is not dropped. This is wrong since the completion_handler logic expect the skb to be consumed anyway even when an error is triggered. Not freeing the skb on error is a memory leak since the skb won't be freed anywere else. Correctly free the packet on eid >= ATH11K_HTC_EP_COUNT before returning. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Modified: 2025-11-19
CVE-2022-50187
In the Linux kernel, the following vulnerability has been resolved: ath11k: fix netdev open race Make sure to allocate resources needed before registering the device. This specifically avoids having a racing open() trigger a BUG_ON() in mod_timer() when ath11k_mac_op_start() is called before the mon_reap_timer as been set up. I did not see this issue with next-20220310, but I hit it on every probe with next-20220511. Perhaps some timing changed in between. Here's the backtrace: [ 51.346947] kernel BUG at kernel/time/timer.c:990! [ 51.346958] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ... [ 51.578225] Call trace: [ 51.583293] __mod_timer+0x298/0x390 [ 51.589518] mod_timer+0x14/0x20 [ 51.595368] ath11k_mac_op_start+0x41c/0x4a0 [ath11k] [ 51.603165] drv_start+0x38/0x60 [mac80211] [ 51.610110] ieee80211_do_open+0x29c/0x7d0 [mac80211] [ 51.617945] ieee80211_open+0x60/0xb0 [mac80211] [ 51.625311] __dev_open+0x100/0x1c0 [ 51.631420] __dev_change_flags+0x194/0x210 [ 51.638214] dev_change_flags+0x24/0x70 [ 51.644646] do_setlink+0x228/0xdb0 [ 51.650723] __rtnl_newlink+0x460/0x830 [ 51.657162] rtnl_newlink+0x4c/0x80 [ 51.663229] rtnetlink_rcv_msg+0x124/0x390 [ 51.669917] netlink_rcv_skb+0x58/0x130 [ 51.676314] rtnetlink_rcv+0x18/0x30 [ 51.682460] netlink_unicast+0x250/0x310 [ 51.688960] netlink_sendmsg+0x19c/0x3e0 [ 51.695458] ____sys_sendmsg+0x220/0x290 [ 51.701938] ___sys_sendmsg+0x7c/0xc0 [ 51.708148] __sys_sendmsg+0x68/0xd0 [ 51.714254] __arm64_sys_sendmsg+0x28/0x40 [ 51.720900] invoke_syscall+0x48/0x120 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
- https://git.kernel.org/stable/c/307ce58270b3b50ca21cfcc910568429b06803f7
- https://git.kernel.org/stable/c/a2c45f8c3d18269e641f0c7da2dde47ef8414034
- https://git.kernel.org/stable/c/abb7dc8fbb27c15dcc927df56190f3c5ede58bd5
- https://git.kernel.org/stable/c/d4ba1ff87b17e81686ada8f429300876f55f95ad
- https://git.kernel.org/stable/c/eaff3946a86fc63280a30158a4ae1e141449817c
Modified: 2025-11-19
CVE-2022-50188
In the Linux kernel, the following vulnerability has been resolved: drm/meson: Fix refcount leak in meson_encoder_hdmi_init of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() in error path to avoid refcount leak.
Modified: 2025-11-19
CVE-2022-50190
In the Linux kernel, the following vulnerability has been resolved: spi: Fix simplification of devm_spi_register_controller This reverts commit 59ebbe40fb51 ("spi: simplify devm_spi_register_controller"). If devm_add_action() fails in devm_add_action_or_reset(), devm_spi_unregister() will be called, it decreases the refcount of 'ctlr->dev' to 0, then it will cause uaf in the drivers that calling spi_put_controller() in error path.
Modified: 2025-11-19
CVE-2022-50191
In the Linux kernel, the following vulnerability has been resolved: regulator: of: Fix refcount leak bug in of_get_regulation_constraints() We should call the of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount.
- https://git.kernel.org/stable/c/11ecb4f8735b0230d54a82c18b21ea778b695d61
- https://git.kernel.org/stable/c/332e555dca074c4eb2084898021c3676423814c3
- https://git.kernel.org/stable/c/35f9e861d9b9434903a8ede37a3561f78985826d
- https://git.kernel.org/stable/c/66efb665cd5ad69b27dca8571bf89fc6b9c628a4
- https://git.kernel.org/stable/c/a23098cc32860272dc6c3200ff20c34c65b7b694
- https://git.kernel.org/stable/c/b9ca8585c766616563cf3c062c6878f61f83cf00
- https://git.kernel.org/stable/c/c9df8ff290097aabd5c9200f7f729b0813d37b19
- https://git.kernel.org/stable/c/fc7b19f547bc9e622060a0a9a39da2330aa21c53
Modified: 2025-11-19
CVE-2022-50192
In the Linux kernel, the following vulnerability has been resolved: spi: tegra20-slink: fix UAF in tegra_slink_remove() After calling spi_unregister_master(), the refcount of master will be decrease to 0, and it will be freed in spi_controller_release(), the device data also will be freed, so it will lead a UAF when using 'tspi'. To fix this, get the master before unregister and put it when finish using it.
Modified: 2025-11-19
CVE-2022-50193
In the Linux kernel, the following vulnerability has been resolved:
erofs: wake up all waiters after z_erofs_lzma_head ready
When the user mounts the erofs second times, the decompression thread
may hung. The problem happens due to a sequence of steps like the
following:
1) Task A called z_erofs_load_lzma_config which obtain all of the node
from the z_erofs_lzma_head.
2) At this time, task B called the z_erofs_lzma_decompress and wanted to
get a node. But the z_erofs_lzma_head was empty, the Task B had to
sleep.
3) Task A release nodes and push nodes into the z_erofs_lzma_head. But
task B was still sleeping.
One example report when the hung happens:
task:kworker/u3:1 state:D stack:14384 pid: 86 ppid: 2 flags:0x00004000
Workqueue: erofs_unzipd z_erofs_decompressqueue_work
Call Trace:
Modified: 2025-11-19
CVE-2022-50194
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. When breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the child node. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/053543ac1d095132fcfd1263805d6e25afbdc6a8
- https://git.kernel.org/stable/c/591f0697ccbac33760d3bb1ad96a5ba2b76ae9f0
- https://git.kernel.org/stable/c/97713ed9b6cc4abaa2dcc8357113c56520dc6d7f
- https://git.kernel.org/stable/c/bc73c72a856c26df7410ddf15f42257cb4960fe9
- https://git.kernel.org/stable/c/ca83c61a6ccf3934cf8d01d5ade30a5034993a86
- https://git.kernel.org/stable/c/e6e0951414a314e7db3e9e24fd924b3e15515288
Modified: 2025-11-19
CVE-2022-50195
In the Linux kernel, the following vulnerability has been resolved: ARM: dts: qcom: replace gcc PXO with pxo_board fixed clock Replace gcc PXO phandle to pxo_board fixed clock declared in the dts. gcc driver doesn't provide PXO_SRC as it's a fixed-clock. This cause a kernel panic if any driver actually try to use it.
Modified: 2025-11-19
CVE-2022-50196
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: ocmem: Fix refcount leak in of_get_ocmem of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer.
- https://git.kernel.org/stable/c/07aea6819d569d1e172227486655e4fb5bd4cdb9
- https://git.kernel.org/stable/c/84a928b44cb303d5756e3bff2734921de8dce4f6
- https://git.kernel.org/stable/c/92a563fcf14b3093226fb36f12e9b5cf630c5a5d
- https://git.kernel.org/stable/c/a1e4243c0dddeafb4ace6d9906d3f5129b81a9fe
- https://git.kernel.org/stable/c/ed40a48d0a9166edb22e2b8efafea822e93dd79a
Modified: 2025-11-19
CVE-2022-50197
In the Linux kernel, the following vulnerability has been resolved: cpufreq: zynq: Fix refcount leak in zynq_get_revision of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/179034fb108e3655142f2af0c309cef171c34d68
- https://git.kernel.org/stable/c/22e6d8bcde8e66b64f46bf9bd2d3d0f88d40c39f
- https://git.kernel.org/stable/c/3b01353f1825151a29d08e0868b2bf01e1116ab5
- https://git.kernel.org/stable/c/a530fa52d4fdffc5f010f90c05ac63019b8ff5f8
- https://git.kernel.org/stable/c/d1ff2559cef0f6f8d97fba6337b28adb10689e16
- https://git.kernel.org/stable/c/dcbb974254d2a27240c2e50185afdde90f923feb
- https://git.kernel.org/stable/c/ecefd22d5db7ccb8bec2646e5d25e058fc33162a
- https://git.kernel.org/stable/c/f52c9be1779d70037ae300762d19b08fe3656237
Modified: 2025-11-19
CVE-2022-50198
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: Fix refcount leak in omap3xxx_prm_late_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1bf747824a8ca4008879fd7d2ce6b03d7b428858
- https://git.kernel.org/stable/c/942228fbf5d4901112178b93d41225be7c0dd9de
- https://git.kernel.org/stable/c/c4f92af7fc8cecb8eb426ad187e39c7bcc6679c7
- https://git.kernel.org/stable/c/c652e0f51665f3fa575449909bbd9d7b45dfab1c
- https://git.kernel.org/stable/c/c9ec7993d00250a394d367c8a19fcfe8211c258b
- https://git.kernel.org/stable/c/d294d60dc68550fee0fbbe8a638d798dcd40b2c5
- https://git.kernel.org/stable/c/e5ab8a4967d68a8e9f8f4559d144207d085a8c02
Modified: 2025-11-19
CVE-2022-50199
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: Fix refcount leak in omapdss_init_of omapdss_find_dss_of_node() calls of_find_compatible_node() to get device node. of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() in later error path and normal path.
- https://git.kernel.org/stable/c/14bac0c7035bf920e190a63c7e1b113c72eadbf4
- https://git.kernel.org/stable/c/230ad40a59c9a9ee8f3822b9a7bec09404102ebc
- https://git.kernel.org/stable/c/507159facf002d113c4878fec67f37d62f187887
- https://git.kernel.org/stable/c/935035cf97c8cd6794044b500fb0a44a6d30ffa1
- https://git.kernel.org/stable/c/9705db1eff38d6b9114121f9e253746199b759c9
- https://git.kernel.org/stable/c/a32dc6829e33c54e751346aa3e08ddb6d0e1a6a0
Modified: 2025-11-19
CVE-2022-50200
In the Linux kernel, the following vulnerability has been resolved: selinux: Add boundary check in put_entry() Just like next_entry(), boundary check is necessary to prevent memory out-of-bound access.
- https://git.kernel.org/stable/c/15ec76fb29be31df2bccb30fc09875274cba2776
- https://git.kernel.org/stable/c/2dabe6a872a5744865372eb30ea51e8ccd21305a
- https://git.kernel.org/stable/c/477722f31ad73aa779154d1d7e00825538389f76
- https://git.kernel.org/stable/c/7363a69d8ca8f0086f8e1196c8ddaf0e168614b1
- https://git.kernel.org/stable/c/90bdf50ae70c5571a277b5601e4f5df210831e0a
- https://git.kernel.org/stable/c/9605f50157cae00eb299e1189a6d708c84935ad8
- https://git.kernel.org/stable/c/adbfdaacde18faf6cd4e490764045375266b3fbd
- https://git.kernel.org/stable/c/dedd558d9765b72c66e5a53948e9f5abc3ece1f6
Modified: 2025-11-19
CVE-2022-50201
In the Linux kernel, the following vulnerability has been resolved: selinux: fix memleak in security_read_state_kernel() In this function, it directly returns the result of __security_read_policy without freeing the allocated memory in *data, cause memory leak issue, so free the memory if __security_read_policy failed. [PM: subject line tweak]
Modified: 2025-11-19
CVE-2022-50202
In the Linux kernel, the following vulnerability has been resolved: PM: hibernate: defer device probing when resuming from hibernation syzbot is reporting hung task at misc_open() [1], for there is a race window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When a device is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is decremented after the probe function completed. There are three cases that can prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e. broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason. (c) New device probe requests keeps coming in before existing device probe requests complete. The phenomenon syzbot is reporting is (b). A process which is holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface. This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g. mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface.
- https://git.kernel.org/stable/c/003a456ae6f70bb97e436e02fc5105be577c1570
- https://git.kernel.org/stable/c/2f0e18e0db42f4f8bc87d3d98333680065ceeff8
- https://git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50
- https://git.kernel.org/stable/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb
- https://git.kernel.org/stable/c/8386c414e27caba8501119948e9551e52b527f59
- https://git.kernel.org/stable/c/8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91
- https://git.kernel.org/stable/c/b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258
- https://git.kernel.org/stable/c/f7042cf9dd40733f387b7cac021e626c74b8856f
Modified: 2025-11-19
CVE-2022-50203
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: display: Fix refcount leak bug In omapdss_init_fbdev(), of_find_node_by_name() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0b4f96b47ff8dc2fa35d03c4116927248796d9af
- https://git.kernel.org/stable/c/2629d171f3d6451724549d8d10d14ac6da37a7be
- https://git.kernel.org/stable/c/3e505298a75f0bbdc96e923e76e5d45d6c8f64a7
- https://git.kernel.org/stable/c/496988a19d5c36fabf97c847db39167e42393c74
- https://git.kernel.org/stable/c/50b87a32a79bca6e275918a711fb8cc55e16d739
- https://git.kernel.org/stable/c/88d556029a78999b098d26a330bb6a7de166f426
- https://git.kernel.org/stable/c/a89a865dc9f0600fd146224e314775b9efc9d845
- https://git.kernel.org/stable/c/bdbdf69d5b78c5712c60c0004fa6aed12da36e26
Modified: 2025-11-19
CVE-2022-50204
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: pdata-quirks: Fix refcount leak bug In pdata_quirks_init_clocks(), the loop contains of_find_node_by_name() but without corresponding of_node_put().
Modified: 2025-11-19
CVE-2022-50205
In the Linux kernel, the following vulnerability has been resolved: ext2: Add more validity checks for inode counts Add checks verifying number of inodes stored in the superblock matches the number computed from number of inodes per group. Also verify we have at least one block worth of inodes per group. This prevents crashes on corrupted filesystems.
- https://git.kernel.org/stable/c/07303a9abe3a997d9864fb4315e34b5acfe8fc25
- https://git.kernel.org/stable/c/0bcdc31094a12b4baf59e241feabc9787cf635fa
- https://git.kernel.org/stable/c/5e63c5fe9123fa76ffaeff26c211308736ec3a07
- https://git.kernel.org/stable/c/7a48fdc88a3c35e046a6a0a38eba00f21c65b16e
- https://git.kernel.org/stable/c/96b18d3a1be0354ccce43f0ef61b5a3d7e432552
- https://git.kernel.org/stable/c/b3f423683818cfe15de14d5d9dff44148ff16bbf
- https://git.kernel.org/stable/c/d08bb199a406424a8ed0009efdf41710e6d849ee
- https://git.kernel.org/stable/c/fa78f336937240d1bc598db817d638086060e7e9
Modified: 2025-11-19
CVE-2022-50206
In the Linux kernel, the following vulnerability has been resolved: arm64: fix oops in concurrently setting insn_emulation sysctls emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200 To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing.
- https://git.kernel.org/stable/c/04549063d5701976034d8c2bfda3d3a8cbf0409f
- https://git.kernel.org/stable/c/07022e07017ee5540f5559b0aeb916e8383c1e1a
- https://git.kernel.org/stable/c/353b4673d01c512303c45cf2346f630cda73b5c9
- https://git.kernel.org/stable/c/6a2fd114678d7fc1b5a0f8865ae98f1c17787455
- https://git.kernel.org/stable/c/9d5fec6ba2e4117d196a8259ab54615ffe562460
- https://git.kernel.org/stable/c/af483947d472eccb79e42059276c4deed76f99a6
- https://git.kernel.org/stable/c/b51881b1da57fe9877125dfdd0aac5172958fcfd
- https://git.kernel.org/stable/c/cc69ef95988b9ef2fc730ec452a7441efb90ef5e
Modified: 2025-11-19
CVE-2022-50207
In the Linux kernel, the following vulnerability has been resolved: ARM: bcm: Fix refcount leak in bcm_kona_smc_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/02b658bfb26452f2c13e4577a13ab802f89a6642
- https://git.kernel.org/stable/c/5afe042c889437de83f38a9d73d145742fb4f65f
- https://git.kernel.org/stable/c/62d719d31ec667276d7375b64542b080cf187797
- https://git.kernel.org/stable/c/75866df2b1d673df5b7781e565ada753a7895f04
- https://git.kernel.org/stable/c/91e7f04f53e680bc72f0a9a5c682ab652100b9c8
- https://git.kernel.org/stable/c/bc7f487395f208fd9af69e9a807815e10435aba7
- https://git.kernel.org/stable/c/c6964cb9ac7a43bf78e7d60126e2722992de2ea1
- https://git.kernel.org/stable/c/cb23389a2458c2e4bfd6c86a513cbbe1c4d35e76
Modified: 2025-11-20
CVE-2022-50208
In the Linux kernel, the following vulnerability has been resolved: soc: amlogic: Fix refcount leak in meson-secure-pwrc.c In meson_secure_pwrc_probe(), there is a refcount leak in one fail path.
- https://git.kernel.org/stable/c/5509d07a9364b75b28055bf2d89289e4e5269929
- https://git.kernel.org/stable/c/80c469e63bfa9a5a8114952bffc6a7d241e7497e
- https://git.kernel.org/stable/c/d18529a4c12f66d83daac78045ea54063bd43257
- https://git.kernel.org/stable/c/d1fbbb5ded714b6610a16ec3d7e271a55291ccc4
- https://git.kernel.org/stable/c/f370fbbd3151c1c87d1e976c8964cb6cc46f2e00
Modified: 2025-11-19
CVE-2022-50209
In the Linux kernel, the following vulnerability has been resolved: meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/0c1757480a6a61b8c3164ed371c359edb3928f12
- https://git.kernel.org/stable/c/2691b8780f88e1b8b3578a5bc78a0011741bbd74
- https://git.kernel.org/stable/c/69a64c77aafcf3c772264a36214937514e31ad82
- https://git.kernel.org/stable/c/6b28bf3e044f12db0fc18c42f58ae7fc3fa0144a
- https://git.kernel.org/stable/c/8a4a33b3e898b13c750b1c0c9643516c7bf6473f
- https://git.kernel.org/stable/c/a2106f38077e78afcb4bf98fdda3e162118cfb3d
- https://git.kernel.org/stable/c/e21744c6a0d4116a2d6ebccd947620ca4c952e92
Modified: 2025-11-19
CVE-2022-50210
In the Linux kernel, the following vulnerability has been resolved: MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<980000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
- https://git.kernel.org/stable/c/274e44e2123417e0924c90d4b4531913b5f3aa2e
- https://git.kernel.org/stable/c/4cb392956ae392aec4aa06e661a0bb9146b0bace
- https://git.kernel.org/stable/c/7d305823e02217b29d41fca67e3cef87fd7bd688
- https://git.kernel.org/stable/c/807adf6ffa8c3beedcd63b20f5a59c7d061df7d2
- https://git.kernel.org/stable/c/8916ec149c79cb21f5454fa7840ad96f99cf51cf
- https://git.kernel.org/stable/c/98aaa511957667ba26d6dabe28dfa210a8f53a63
- https://git.kernel.org/stable/c/d3ac4e47510ec0753ebe1e418a334ad202784aa8
- https://git.kernel.org/stable/c/e1a534f5d074db45ae5cbac41d8912b98e96a006
- https://git.kernel.org/stable/c/e41db8a9ce696a3382a4f098878fd4d14bccd201
Modified: 2025-11-19
CVE-2022-50211
In the Linux kernel, the following vulnerability has been resolved:
md-raid10: fix KASAN warning
There's a KASAN warning in raid10_remove_disk when running the lvm
test lvconvert-raid-reshape.sh. We fix this warning by verifying that the
value "number" is valid.
BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]
Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682
CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/0f4d18cbea4a6e37a05fd8ee2887439f85211110
- https://git.kernel.org/stable/c/5f57843565131bb782388f9d993f9ee8f453dee1
- https://git.kernel.org/stable/c/5fd4ffa2372a41361d2bdd27ea5730e4e673240c
- https://git.kernel.org/stable/c/75fbd370a2cec9e92f48285bd90735ed0c837f52
- https://git.kernel.org/stable/c/7a6ccc8fa192fd357c2d5d4c6ce67c834a179e23
- https://git.kernel.org/stable/c/bcbdc26a44aba488d2f7122f2d66801bccb74733
- https://git.kernel.org/stable/c/bf30b9ba09b0ac2a10f04dce2b0835ec4d178aa6
- https://git.kernel.org/stable/c/ce839b9331c11780470f3d727b6fe3c2794a4620
- https://git.kernel.org/stable/c/d17f744e883b2f8d13cca252d71cfe8ace346f7d
Modified: 2025-11-19
CVE-2022-50212
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not allow CHAIN_ID to refer to another table When doing lookups for chains on the same batch by using its ID, a chain from a different table can be used. If a rule is added to a table but refers to a chain in a different table, it will be linked to the chain in table2, but would have expressions referring to objects in table1. Then, when table1 is removed, the rule will not be removed as its linked to a chain in table2. When expressions in the rule are processed or removed, that will lead to a use-after-free. When looking for chains by ID, use the table that was used for the lookup by name, and only return chains belonging to that same table.
- https://git.kernel.org/stable/c/0f49613a213d918af790c1276f79da741968de11
- https://git.kernel.org/stable/c/58e863f64ee3d0879297e5e53b646e4b91e59620
- https://git.kernel.org/stable/c/91501513016903077f91033fa5d2aa26cac399b2
- https://git.kernel.org/stable/c/95f466d22364a33d183509629d0879885b4f547e
- https://git.kernel.org/stable/c/9e7dcb88ec8e85e4a8ad0ea494ea2f90f32d2583
Modified: 2025-11-19
CVE-2022-50213
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not allow SET_ID to refer to another table When doing lookups for sets on the same batch by using its ID, a set from a different table can be used. Then, when the table is removed, a reference to the set may be kept after the set is freed, leading to a potential use-after-free. When looking for sets by ID, use the table that was used for the lookup by name, and only return sets belonging to that same table. This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.
- https://git.kernel.org/stable/c/0d07039397527361850c554c192e749cfc879ea9
- https://git.kernel.org/stable/c/1a4b18b1ff11ba26f9a852019d674fde9d1d1cff
- https://git.kernel.org/stable/c/470ee20e069a6d05ae549f7d0ef2bdbcee6a81b2
- https://git.kernel.org/stable/c/77d3b5038b7462318f5183e2ad704b01d57215a2
- https://git.kernel.org/stable/c/f4fa03410f7c5f5bd8f90e9c11e9a8c4b526ff6f
- https://git.kernel.org/stable/c/faafd9286f1355c76fe9ac3021c280297213330e
- https://git.kernel.org/stable/c/fab2f61cc3b0e441b1749f017cfee75f9bbaded7
Modified: 2025-11-19
CVE-2022-50214
In the Linux kernel, the following vulnerability has been resolved: coresight: Clear the connection field properly coresight devices track their connections (output connections) and hold a reference to the fwnode. When a device goes away, we walk through the devices on the coresight bus and make sure that the references are dropped. This happens both ways: a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data() b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match(). However, the coresight_remove_match() doesn't clear the fwnode field, after dropping the reference, this causes use-after-free and additional refcount drops on the fwnode. e.g., if we have two devices, A and B, with a connection, A -> B. If we remove B first, B would clear the reference on B, from A via coresight_remove_match(). But when A is removed, it still has a connection with fwnode still pointing to B. Thus it tries to drops the reference in coresight_release_platform_data(), raising the bells like : [ 91.990153] ------------[ cut here ]------------ [ 91.990163] refcount_t: addition on 0; use-after-free. [ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144 [ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug] [ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53 [ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 [ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 91.990454] pc : refcount_warn_saturate+0xa0/0x144 [ 91.990476] lr : refcount_warn_saturate+0xa0/0x144 [ 91.990496] sp : ffff80000c843640 [ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8 [ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8 [ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2 [ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40 [ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0 [ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375 [ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28 [ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572 [ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027 [ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00 [ 91.991000] Call trace: [ 91.991012] refcount_warn_saturate+0xa0/0x144 [ 91.991034] kobject_get+0xac/0xb0 [ 91.991055] of_node_get+0x2c/0x40 [ 91.991076] of_fwnode_get+0x40/0x60 [ 91.991094] fwnode_handle_get+0x3c/0x60 [ 91.991116] fwnode_get_nth_parent+0xf4/0x110 [ 91.991137] fwnode_full_name_string+0x48/0xc0 [ 91.991158] device_node_string+0x41c/0x530 [ 91.991178] pointer+0x320/0x3ec [ 91.991198] vsnprintf+0x23c/0x750 [ 91.991217] vprintk_store+0x104/0x4b0 [ 91.991238] vprintk_emit+0x8c/0x360 [ 91.991257] vprintk_default+0x44/0x50 [ 91.991276] vprintk+0xcc/0xf0 [ 91.991295] _printk+0x68/0x90 [ 91.991315] of_node_release+0x13c/0x14c [ 91.991334] kobject_put+0x98/0x114 [ 91.991354] of_node_put+0x24/0x34 [ 91.991372] of_fwnode_put+0x40/0x5c [ 91.991390] fwnode_handle_put+0x38/0x50 [ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight] [ 91.991472] coresight_unregister+0x64/0xcc [coresight] [ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x] [ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x] [ 91.991598] amba_remove+0x3c/0x19c ---truncated---
- https://git.kernel.org/stable/c/2af89ebacf299b7fba5f3087d35e8a286ec33706
- https://git.kernel.org/stable/c/847b9273dd61567fb77617eabc5fa002594db062
- https://git.kernel.org/stable/c/b49b29ee113a87997bcca0bb0585bb46582846c1
- https://git.kernel.org/stable/c/bc57850fcb7e4cb91b6321d0ce83357cefd55c54
- https://git.kernel.org/stable/c/d43e967963c4d1b2b49f894d2f1b12865f87b098
- https://git.kernel.org/stable/c/e9205d8dd1cafb7cff689ef9ddf06276a68f54a4
Modified: 2025-11-19
CVE-2022-50215
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Allow waiting for commands to complete on removed device When a SCSI device is removed while in active use, currently sg will immediately return -ENODEV on any attempt to wait for active commands that were sent before the removal. This is problematic for commands that use SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel when userspace frees or reuses it after getting ENODEV, leading to corrupted userspace memory (in the case of READ-type commands) or corrupted data being sent to the device (in the case of WRITE-type commands). This has been seen in practice when logging out of a iscsi_tcp session, where the iSCSI driver may still be processing commands after the device has been marked for removal. Change the policy to allow userspace to wait for active sg commands even when the device is being removed. Return -ENODEV only when there are no more responses to read.
- https://git.kernel.org/stable/c/03d8241112d5e3cccce1a01274a221099f07d2e1
- https://git.kernel.org/stable/c/3455607fd7be10b449f5135c00dc306b85dc0d21
- https://git.kernel.org/stable/c/35e60ec39e862159cb92923eefd5230d4a873cb9
- https://git.kernel.org/stable/c/408bfa1489a3cfe7150b81ab0b0df99b23dd5411
- https://git.kernel.org/stable/c/8c004b7dbb340c1e5889f5fb9e5baa6f6e5303e8
- https://git.kernel.org/stable/c/bbc118acf7baf9e93c5e1314d14f481301af4d0f
- https://git.kernel.org/stable/c/ed9afd967cbfe7da2dc0d5e52c62a778dfe9f16b
- https://git.kernel.org/stable/c/f135c65085eed869d10e4e7923ce1015288618da
- https://git.kernel.org/stable/c/f5e61d9b4a699dd16f32d5f39eb1cf98d84c92ed
Modified: 2025-11-19
CVE-2022-50217
In the Linux kernel, the following vulnerability has been resolved: fuse: write inode in fuse_release() A race between write(2) and close(2) allows pages to be dirtied after fuse_flush -> write_inode_now(). If these pages are not flushed from fuse_release(), then there might not be a writable open file later. So any remaining dirty pages must be written back before the file is released. This is a partial revert of the blamed commit.
Modified: 2025-11-19
CVE-2022-50218
In the Linux kernel, the following vulnerability has been resolved: iio: light: isl29028: Fix the warning in isl29028_remove() The driver use the non-managed form of the register function in isl29028_remove(). To keep the release order as mirroring the ordering in probe, the driver should use non-managed form in probe, too. The following log reveals it: [ 32.374955] isl29028 0-0010: remove [ 32.376861] general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI [ 32.377676] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.379432] RIP: 0010:kernfs_find_and_get_ns+0x28/0xe0 [ 32.385461] Call Trace: [ 32.385807] sysfs_unmerge_group+0x59/0x110 [ 32.386110] dpm_sysfs_remove+0x58/0xc0 [ 32.386391] device_del+0x296/0xe50 [ 32.386959] cdev_device_del+0x1d/0xd0 [ 32.387231] devm_iio_device_unreg+0x27/0xb0 [ 32.387542] devres_release_group+0x319/0x3d0 [ 32.388162] i2c_device_remove+0x93/0x1f0
- https://git.kernel.org/stable/c/06674fc7c003b9d0aa1d37fef7ab2c24802cc6ad
- https://git.kernel.org/stable/c/359f3b150eab30805fe0e4e9d616887d7257a625
- https://git.kernel.org/stable/c/4f0ebfb4b9bfad2326c0b2c3cc7e37f4b9ee9eba
- https://git.kernel.org/stable/c/a1135205b0affd255510775a27df571aca84ab4b
- https://git.kernel.org/stable/c/ca63d5abf404d2934e2ac03545350de7bb8c8e96
- https://git.kernel.org/stable/c/ed43fb20d3d1fca9d79db0d5faf4321a4dd58c23
- https://git.kernel.org/stable/c/fac589fb764699a4bcd288f6656b8cd0408ea968
- https://git.kernel.org/stable/c/fb1888205c0782f287e5dd4ffff1f665332e868c
Modified: 2025-11-19
CVE-2022-50219
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix KASAN use-after-free Read in compute_effective_progs Syzbot found a Use After Free bug in compute_effective_progs(). The reproducer creates a number of BPF links, and causes a fault injected alloc to fail, while calling bpf_link_detach on them. Link detach triggers the link to be freed by bpf_link_free(), which calls __cgroup_bpf_detach() and update_effective_progs(). If the memory allocation in this function fails, the function restores the pointer to the bpf_cgroup_link on the cgroup list, but the memory gets freed just after it returns. After this, every subsequent call to update_effective_progs() causes this already deallocated pointer to be dereferenced in prog_list_length(), and triggers KASAN UAF error. To fix this issue don't preserve the pointer to the prog or link in the list, but remove it and replace it with a dummy prog without shrinking the table. The subsequent call to __cgroup_bpf_detach() or __cgroup_bpf_detach() will correct it.
- https://git.kernel.org/stable/c/1f8ca9c40e6222ce431e9ba5dae3cccce8ef9443
- https://git.kernel.org/stable/c/3527e3cbb84d8868c4d4e91ba55915f96d39ec3d
- https://git.kernel.org/stable/c/4c46091ee985ae84c60c5e95055d779fcd291d87
- https://git.kernel.org/stable/c/6336388715afa419cc97d0255bda3bba1b96b7ca
- https://git.kernel.org/stable/c/be001f9da71eaa3b61e186fb88bde3279728bdca
Modified: 2025-11-19
CVE-2022-50220
In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix linkwatch use-after-free on disconnect usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock": https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all* work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). * usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010, usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf ("drivers/net: don't use flush_scheduled_work()"). Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last.
- https://git.kernel.org/stable/c/135199a2edd459d2b123144efcd7f9bcd95128e4
- https://git.kernel.org/stable/c/635fd8953e4309b54ca6a81bed1d4a87668694f4
- https://git.kernel.org/stable/c/7f77dcbc030c2faa6d8e8a594985eeb34018409e
- https://git.kernel.org/stable/c/8b4588b8b00b299be16a35be67b331d8fdba03f3
- https://git.kernel.org/stable/c/a69e617e533edddf3fa3123149900f36e0a6dc74
- https://git.kernel.org/stable/c/d2d6b530d89b0a912148018027386aa049f0a309
- https://git.kernel.org/stable/c/d49bb8cf9bfaa06aa527eb30f1a52a071da2e32f
- https://git.kernel.org/stable/c/db3b738ae5f726204876f4303c49cfdf4311403f
- https://git.kernel.org/stable/c/e2a521a7dcc463c5017b4426ca0804e151faeff7
Modified: 2025-11-19
CVE-2022-50221
In the Linux kernel, the following vulnerability has been resolved: drm/fb-helper: Fix out-of-bounds access Clip memory range to screen-buffer size to avoid out-of-bounds access in fbdev deferred I/O's damage handling. Fbdev's deferred I/O can only track pages. From the range of pages, the damage handler computes the clipping rectangle for the display update. If the fbdev screen buffer ends near the beginning of a page, that page could contain more scanlines. The damage handler would then track these non-existing scanlines as dirty and provoke an out-of-bounds access during the screen update. Hence, clip the maximum memory range to the size of the screen buffer. While at it, rename the variables min/max to min_off/max_off in drm_fb_helper_deferred_io(). This avoids confusion with the macros of the same name.
Modified: 2025-11-19
CVE-2022-50222
In the Linux kernel, the following vulnerability has been resolved:
tty: vt: initialize unicode screen buffer
syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read
immediately after resize operation. Initialize buffer using kzalloc().
----------
#include
- https://git.kernel.org/stable/c/446f123aa6021e5f75a20789f05ff3f7ae51a42f
- https://git.kernel.org/stable/c/5c6c65681f39bf71bc72ed589dec3b8b20e75cac
- https://git.kernel.org/stable/c/777a462e1ae50a01fc4a871efa8e34d596a1e17d
- https://git.kernel.org/stable/c/af77c56aa35325daa2bc2bed5c2ebf169be61b86
- https://git.kernel.org/stable/c/cc9e874dace0c89ae535230c7da19b764746811e
- https://git.kernel.org/stable/c/e02fa87e572bb7d90dcdbce9c0f519f1eb992e96
- https://git.kernel.org/stable/c/e0ef23e9b0ad18b9fd3741b0f1ad2282e4a18def
Modified: 2025-11-19
CVE-2022-50224
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT
Treat the NX bit as valid when using NPT, as KVM will set the NX bit when
the NX huge page mitigation is enabled (mindblowing) and trigger the WARN
that fires on reserved SPTE bits being set.
KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:
Refuse to load kvm_amd if NX support is not available") for exactly this
reason, but apparently it never occurred to anyone to actually test NPT
with the mitigation enabled.
------------[ cut here ]------------
spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000
WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm]
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022
RIP: 0010:make_spte+0x327/0x340 [kvm]
Call Trace:
Modified: 2025-11-19
CVE-2022-50225
In the Linux kernel, the following vulnerability has been resolved:
riscv:uprobe fix SR_SPIE set/clear handling
In riscv the process of uprobe going to clear spie before exec
the origin insn,and set spie after that.But When access the page
which origin insn has been placed a page fault may happen and
irq was disabled in arch_uprobe_pre_xol function,It cause a WARN
as follows.
There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.
We can just remove it.
[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488
[ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work
[ 31.684929] preempt_count: 0, expected: 0
[ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G
[ 31.686542] Hardware name: riscv-virtio,qemu (DT)
[ 31.686797] Call Trace:
[ 31.687053] [
Modified: 2025-11-19
CVE-2022-50226
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak For some sev ioctl interfaces, input may be passed that is less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the buffer, the sev ioctl interfaces with the issue may return uninitialized slab memory. Currently, all of the ioctl interfaces in the ccp driver are safe, but to prevent future problems, change all ioctl interfaces that allocate memory with kmalloc to use kzalloc and memset the data buffer to zero in sev_ioctl_do_platform_status.
- https://git.kernel.org/stable/c/13dc15a3f5fd7f884e4bfa8c011a0ae868df12ae
- https://git.kernel.org/stable/c/4c5300f6f5e18b11c02a92f136e69b98fddba15e
- https://git.kernel.org/stable/c/caa395aa16e7c9193fd7fa6cde462dd8229d4953
- https://git.kernel.org/stable/c/e11fb0a3a39bb42da35fa662c46ce7391f277436
- https://git.kernel.org/stable/c/f2a920daa780956b987c14b9f23de7c3c8915bf2
Modified: 2025-11-19
CVE-2022-50228
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0
Don't BUG/WARN on interrupt injection due to GIF being cleared,
since it's trivial for userspace to force the situation via
KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct
for KVM internally generated injections).
kernel BUG at arch/x86/kvm/svm/svm.c:3386!
invalid opcode: 0000 [#1] SMP
CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd]
Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53
RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006
RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0
RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000
FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0
Call Trace:
- https://git.kernel.org/stable/c/2c49adeb020995236e63722ef6d0bee14372f471
- https://git.kernel.org/stable/c/2eee1dba70f57148fc7f8252613bfae6bd4b04e3
- https://git.kernel.org/stable/c/3d4e2d884da6312df7c9b85fbf671de49204ead6
- https://git.kernel.org/stable/c/68e1313bb8809e8addcd9431f2bfea0e8ddbca80
- https://git.kernel.org/stable/c/6afe88fbb40eac3291a8728688d61fdc745d8008
- https://git.kernel.org/stable/c/6fcbab82ccbcde915644085f73d3487938bda42d
- https://git.kernel.org/stable/c/8bb683490278005b4caf61e22b0828a04d282e86
- https://git.kernel.org/stable/c/c3396c1c8b87510f2ac2a674948156577559d42d
- https://git.kernel.org/stable/c/f17c31c48e5cde9895a491d91c424eeeada3e134
Modified: 2025-11-19
CVE-2022-50229
In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: Fix a UAF bug on the error path of probing When the driver fails in snd_card_register() at probe time, it will free the 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug. The following log can reveal it: [ 50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] [ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0 [ 50.729530] Call Trace: [ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] Fix this by adding usb_kill_urb() before usb_free_urb().
- https://git.kernel.org/stable/c/05e0bb8c3c4dde3e21b9c1cf9395afb04e8b24db
- https://git.kernel.org/stable/c/1d6a246cf97c380f2da76591f03019dd9c9599c3
- https://git.kernel.org/stable/c/348620464a5c127399ac09b266f494f393661952
- https://git.kernel.org/stable/c/4fc41f7ebb7efca282f1740ea934d16f33c1d109
- https://git.kernel.org/stable/c/5e7338f4dd92b2f8915a82abfa1dd3ad3464bea0
- https://git.kernel.org/stable/c/64ca7f50ad96c2c65ae390b954925a36eabe04aa
- https://git.kernel.org/stable/c/a718eba7e458e2f40531be3c6b6a0028ca7fcace
- https://git.kernel.org/stable/c/b0d4af0a4763ddc02344789ef2a281c494bc330d
- https://git.kernel.org/stable/c/ffb2759df7efbc00187bfd9d1072434a13a54139
Modified: 2025-11-19
CVE-2022-50230
In the Linux kernel, the following vulnerability has been resolved: arm64: set UXN on swapper page tables [ This issue was fixed upstream by accident in c3cee924bd85 ("arm64: head: cover entire kernel image in initial ID map") as part of a large refactoring of the arm64 boot flow. This simple fix is therefore preferred for -stable backporting ] On a system that implements FEAT_EPAN, read/write access to the idmap is denied because UXN is not set on the swapper PTEs. As a result, idmap_kpti_install_ng_mappings panics the kernel when accessing __idmap_kpti_flag. Fix it by setting UXN on these PTEs.
Modified: 2025-11-19
CVE-2022-50231
In the Linux kernel, the following vulnerability has been resolved:
crypto: arm64/poly1305 - fix a read out-of-bound
A kasan error was reported during fuzzing:
BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715
CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019
Call trace:
dump_backtrace+0x0/0x394
show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x158/0x1e4 lib/dump_stack.c:118
print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387
__kasan_report+0xe0/0x140 mm/kasan/report.c:547
kasan_report+0x44/0xe0 mm/kasan/report.c:564
check_memory_region_inline mm/kasan/generic.c:187 [inline]
__asan_load4+0x94/0xd0 mm/kasan/generic.c:252
neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]
neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]
crypto_shash_update crypto/shash.c:131 [inline]
shash_finup_unaligned+0x84/0x15c crypto/shash.c:179
crypto_shash_finup+0x8c/0x140 crypto/shash.c:193
shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201
crypto_shash_digest+0xa4/0xfc crypto/shash.c:217
crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229
essiv_skcipher_setkey+0x164/0x200 [essiv]
crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612
skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305
alg_setkey+0x114/0x2a0 crypto/af_alg.c:220
alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253
__sys_setsockopt+0x190/0x2e0 net/socket.c:2123
__do_sys_setsockopt net/socket.c:2134 [inline]
__se_sys_setsockopt net/socket.c:2131 [inline]
__arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48
el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155
do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217
el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353
el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369
el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683
This error can be reproduced by the following code compiled as ko on a
system with kasan enabled:
#include
- https://git.kernel.org/stable/c/3c77292d52b341831cb09c24ca4112a1e4f9e91f
- https://git.kernel.org/stable/c/3d4c28475ee352c440b83484b72b1320ff76364a
- https://git.kernel.org/stable/c/7ae19d422c7da84b5f13bc08b98bd737a08d3a53
- https://git.kernel.org/stable/c/8d25a08599df7ca3093eb7ca731c7cd41cbfbb51
- https://git.kernel.org/stable/c/d069dcffef849b8fd10030fd73007a79612803e6
Modified: 2025-11-19
CVE-2022-50232
In the Linux kernel, the following vulnerability has been resolved: arm64: set UXN on swapper page tables [ This issue was fixed upstream by accident in c3cee924bd85 ("arm64: head: cover entire kernel image in initial ID map") as part of a large refactoring of the arm64 boot flow. This simple fix is therefore preferred for -stable backporting ] On a system that implements FEAT_EPAN, read/write access to the idmap is denied because UXN is not set on the swapper PTEs. As a result, idmap_kpti_install_ng_mappings panics the kernel when accessing __idmap_kpti_flag. Fix it by setting UXN on these PTEs.
Modified: 2025-11-19
CVE-2022-50233
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix using strlen with hdev->{dev_name,short_name} Both dev_name and short_name are not guaranteed to be NULL terminated so this instead use strnlen and then attempt to determine if the resulting string needs to be truncated or not.
Modified: 2025-11-24
CVE-2022-50240
In the Linux kernel, the following vulnerability has been resolved: android: binder: stop saving a pointer to the VMA Do not record a pointer to a VMA outside of the mmap_lock for later use. This is unsafe and there are a number of failure paths *after* the recorded VMA pointer may be freed during setup. There is no callback to the driver to clear the saved pointer from generic mm code. Furthermore, the VMA pointer may become stale if any number of VMA operations end up freeing the VMA so saving it was fragile to being with. Instead, change the binder_alloc struct to record the start address of the VMA and use vma_lookup() to get the vma when needed. Add lockdep mmap_lock checks on updates to the vma pointer to ensure the lock is held and depend on that lock for synchronization of readers and writers - which was already the case anyways, so the smp_wmb()/smp_rmb() was not necessary. [akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c]
- https://git.kernel.org/stable/c/015ac18be7de25d17d6e5f1643cb3b60bfbe859e
- https://git.kernel.org/stable/c/1ec3f76a436d750fd5023caec5da0494fc2870d2
- https://git.kernel.org/stable/c/27a594bc7a7c8238d239e3cdbcf2edfa3bbe9a1b
- https://git.kernel.org/stable/c/622ef885a89ad04cfb76ee478fb44f051125d1f1
- https://git.kernel.org/stable/c/925e6b6f82c9c80ab3c17acbde8d16f349da7d26
- https://git.kernel.org/stable/c/a43cfc87caaf46710c8027a8c23b8a55f1078f19
Modified: 2026-01-14
CVE-2022-50367
In the Linux kernel, the following vulnerability has been resolved: fs: fix UAF/GPF bug in nilfs_mdt_destroy In alloc_inode, inode_init_always() could return -ENOMEM if security_inode_alloc() fails, which causes inode->i_private uninitialized. Then nilfs_is_metadata_file_inode() returns true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(), which frees the uninitialized inode->i_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes)
- https://git.kernel.org/stable/c/1e555c3ed1fce4b278aaebe18a64a934cece57d8
- https://git.kernel.org/stable/c/2a96b532098284ecf8e4849b8b9e5fc7a28bdee9
- https://git.kernel.org/stable/c/2e488f13755ffbb60f307e991b27024716a33b29
- https://git.kernel.org/stable/c/64b79e632869ad3ef6c098a4731d559381da1115
- https://git.kernel.org/stable/c/70e4f70d54e0225f91814e8610477d65f33cefe4
- https://git.kernel.org/stable/c/81de80330fa6907aec32eb54c5619059e6e36452
- https://git.kernel.org/stable/c/c0aa76b0f17f59dd9c9d3463550a2986a1d592e4
- https://git.kernel.org/stable/c/d1ff475d7c83289d0a7faef346ea3bbf90818bad
- https://git.kernel.org/stable/c/ec2aab115eb38ac4992ea2fcc2a02fbe7af5cf48
Modified: 2026-03-17
CVE-2022-50519
In the Linux kernel, the following vulnerability has been resolved: nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure If creation or finalization of a checkpoint fails due to anomalies in the checkpoint metadata on disk, a kernel warning is generated. This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted with panic_on_warn, does not panic. A nilfs_error is appropriate here to handle the abnormal filesystem condition. This also replaces the detected error codes with an I/O error so that neither of the internal error codes is returned to callers.
- https://git.kernel.org/stable/c/090fcfb6edeb9367a915b2749e2bd1f8b48d8898
- https://git.kernel.org/stable/c/259c0f68168ac6a598db3486597b10e74d625db0
- https://git.kernel.org/stable/c/5c0776b5bc31de7cd28afb558fae37a20f33602e
- https://git.kernel.org/stable/c/723ac751208f6d6540191689cfbf6c77135a7a1b
- https://git.kernel.org/stable/c/8a18fdc5ae8e6d7ac33c6ee0a2e5f9f1414ef412
- https://git.kernel.org/stable/c/ae16440c44ae2acda6d72aff9d74eccf8967dae5
- https://git.kernel.org/stable/c/b63026b5e13040cd5afa11769dd0d9e1504b031a
- https://git.kernel.org/stable/c/bf98be80cbe3b4e6c86c36ed00457389aca3eb15
- https://git.kernel.org/stable/c/c0c3d3d3ea41cb5228ee90568bb953f9a56c3227
Modified: 2025-03-18
CVE-2023-1095
In nf_tables_updtable, if nf_tables_table_enable returns an error, nft_trans_destroy is called to free the transaction object. nft_trans_destroy() calls list_del(), but the transaction was never placed on a list -- the list head is all zeroes, this results in a NULL pointer dereference.
Modified: 2024-11-21
CVE-2023-2007
The specific flaw exists within the DPT I2O Controller driver. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the kernel.
- https://github.com/torvalds/linux/commit/b04e75a4a8a81887386a0d2dbf605a48e779d2a0
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20240119-0011/
- https://www.debian.org/security/2023/dsa-5480
- https://github.com/torvalds/linux/commit/b04e75a4a8a81887386a0d2dbf605a48e779d2a0
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20240119-0011/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2025-05-05
CVE-2023-2008
A flaw was found in the Linux kernel's udmabuf device driver. The specific flaw exists within a fault handler. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an array. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the kernel.
- https://bugzilla.redhat.com/show_bug.cgi?id=2186862
- https://github.com/torvalds/linux/commit/05b252cccb2e5c3f56119d25de684b4f810ba4
- https://security.netapp.com/advisory/ntap-20230517-0007/
- https://www.zerodayinitiative.com/advisories/ZDI-23-441/
- https://bugzilla.redhat.com/show_bug.cgi?id=2186862
- https://github.com/torvalds/linux/commit/05b252cccb2e5c3f56119d25de684b4f810ba4
- https://security.netapp.com/advisory/ntap-20230517-0007/
- https://www.zerodayinitiative.com/advisories/ZDI-23-441/
Modified: 2025-03-18
CVE-2023-2019
A flaw was found in the Linux kernel's netdevsim device driver, within the scheduling of events. This issue results from the improper management of a reference count. This may allow an attacker to create a denial of service condition on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2189137
- https://github.com/torvalds/linux/commit/180a6a3ee60a
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-17811/
- https://bugzilla.redhat.com/show_bug.cgi?id=2189137
- https://github.com/torvalds/linux/commit/180a6a3ee60a
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-17811/
Modified: 2025-03-18
CVE-2023-2177
A null pointer dereference issue was found in the sctp network protocol in net/sctp/stream_sched.c in Linux Kernel. If stream_in allocation is failed, stream_out is freed which would further be accessed. A local user could use this flaw to crash the system or potentially cause a denial of service.
Modified: 2025-03-19
CVE-2023-23004
In the Linux kernel before 5.19, drivers/gpu/drm/arm/malidp_planes.c misinterprets the get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer).
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://github.com/torvalds/linux/commit/15342f930ebebcfe36f2415049736a77d7d2e045
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19
- https://github.com/torvalds/linux/commit/15342f930ebebcfe36f2415049736a77d7d2e045
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
Modified: 2025-04-23
CVE-2023-2513
A use-after-free vulnerability was found in the Linux kernel's ext4 filesystem in the way it handled the extra inode size for extended attributes. This flaw could allow a privileged local user to cause a system crash or other undefined behaviors.
- https://bugzilla.redhat.com/show_bug.cgi?id=2193097
- https://github.com/torvalds/linux/commit/67d7d8ad99be
- https://lore.kernel.org/all/20220616021358.2504451-1-libaokun1%40huawei.com/
- https://bugzilla.redhat.com/show_bug.cgi?id=2193097
- https://github.com/torvalds/linux/commit/67d7d8ad99be
- https://lore.kernel.org/all/20220616021358.2504451-1-libaokun1%40huawei.com/
Modified: 2025-03-19
CVE-2023-28327
A NULL pointer dereference flaw was found in the UNIX protocol in net/unix/diag.c In unix_diag_get_exact in the Linux Kernel. The newly allocated skb does not have sk, leading to a NULL pointer. This flaw allows a local user to crash or potentially cause a denial of service.
Modified: 2024-11-21
CVE-2023-2860
An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel.
- https://access.redhat.com/security/cve/CVE-2023-2860
- https://bugzilla.redhat.com/show_bug.cgi?id=2218122
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-18511
- https://access.redhat.com/security/cve/CVE-2023-2860
- https://bugzilla.redhat.com/show_bug.cgi?id=2218122
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-18511
Modified: 2025-04-23
CVE-2023-3111
A use after free vulnerability was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag().
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://patchwork.kernel.org/project/linux-btrfs/patch/20220721074829.2905233-1-r33s3n6%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230703-0007/
- https://www.debian.org/security/2023/dsa-5480
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://patchwork.kernel.org/project/linux-btrfs/patch/20220721074829.2905233-1-r33s3n6%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230703-0007/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2024-11-21
CVE-2023-4385
A NULL pointer dereference flaw was found in dbFree in fs/jfs/jfs_dmap.c in the journaling file system (JFS) in the Linux Kernel. This issue may allow a local attacker to crash the system due to a missing sanity check.
- https://access.redhat.com/security/cve/CVE-2023-4385
- https://bugzilla.redhat.com/show_bug.cgi?id=2219272
- https://github.com/torvalds/linux/commit/0d4837fdb796f99369cf7691d33de1b856bcaf1f
- https://access.redhat.com/security/cve/CVE-2023-4385
- https://bugzilla.redhat.com/show_bug.cgi?id=2219272
- https://github.com/torvalds/linux/commit/0d4837fdb796f99369cf7691d33de1b856bcaf1f
Modified: 2024-11-21
CVE-2023-4394
A use-after-free flaw was found in btrfs_get_dev_args_from_path in fs/btrfs/volumes.c in btrfs file-system in the Linux Kernel. This flaw allows a local attacker with special privileges to cause a system crash or leak internal kernel information
- https://access.redhat.com/security/cve/CVE-2023-4394
- https://bugzilla.redhat.com/show_bug.cgi?id=2219263
- https://patchwork.kernel.org/project/linux-btrfs/patch/20220815151606.3479183-1-r33s3n6@gmail.com/
- https://access.redhat.com/security/cve/CVE-2023-4394
- https://bugzilla.redhat.com/show_bug.cgi?id=2219263
- https://patchwork.kernel.org/project/linux-btrfs/patch/20220815151606.3479183-1-r33s3n6@gmail.com/
Modified: 2024-11-21
CVE-2024-0562
A use-after-free flaw was found in the Linux Kernel. When a disk is removed, bdi_unregister is called to stop further write-back and waits for associated delayed work to complete. However, wb_inode_writeback_end() may schedule bandwidth estimation work after this has completed, which can result in the timer attempting to access the recently freed bdi_writeback.
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/security/cve/CVE-2024-0562
- https://bugzilla.redhat.com/show_bug.cgi?id=2258475
- https://patchwork.kernel.org/project/linux-mm/patch/20220801155034.3772543-1-khazhy@google.com/
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/security/cve/CVE-2024-0562
- https://bugzilla.redhat.com/show_bug.cgi?id=2258475
- https://patchwork.kernel.org/project/linux-mm/patch/20220801155034.3772543-1-khazhy@google.com/
Modified: 2025-11-03
CVE-2024-46794
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix data leak in mmio_read() The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an address from the VMM. Sean noticed that mmio_read() unintentionally exposes the value of an initialized variable (val) on the stack to the VMM. This variable is only needed as an output value. It did not need to be passed to the VMM in the first place. Do not send the original value of *val to the VMM. [ dhansen: clarify what 'val' is used for. ]
- https://git.kernel.org/stable/c/26c6af49d26ffc377e392e30d4086db19eed0ef7
- https://git.kernel.org/stable/c/b55ce742afcb8e8189d82f2f1e635ba1b5a461fa
- https://git.kernel.org/stable/c/b6fb565a2d15277896583d471b21bc14a0c99661
- https://git.kernel.org/stable/c/ef00818c50cf55a3a56bd9a9fae867c92dfb84e7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
