ALT-BU-2022-4650-16
Branch sisyphus update bulletin.
Closed vulnerabilities
Modified: 2025-11-19
BDU:2022-02658
Уязвимость функции fribidi_remove_bidi_marks() библиотеки GNU FriBidi, позволяющая нарушителю выполнить произвольный код
Modified: 2025-11-19
BDU:2022-02659
Уязвимость библиотеки GNU FriBidi, вызванная переполнением буфера на стеке, позволяющая нарушителю выполнить произвольный код
Modified: 2025-11-19
BDU:2022-02660
Уязвимость функции fribidi_cap_rtl_to_unicode библиотеки GNU FriBidi, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-21
CVE-2022-25308
A stack-based buffer overflow flaw was found in the Fribidi package. This flaw allows an attacker to pass a specially crafted file to the Fribidi application, which leads to a possible memory leak or a denial of service.
- https://access.redhat.com/security/cve/CVE-2022-25308
- https://bugzilla.redhat.com/show_bug.cgi?id=2047890
- https://github.com/fribidi/fribidi/issues/181
- https://github.com/fribidi/fribidi/pull/184
- https://access.redhat.com/security/cve/CVE-2022-25308
- https://bugzilla.redhat.com/show_bug.cgi?id=2047890
- https://github.com/fribidi/fribidi/issues/181
- https://github.com/fribidi/fribidi/pull/184
Modified: 2024-11-21
CVE-2022-25309
A heap-based buffer overflow flaw was found in the Fribidi package and affects the fribidi_cap_rtl_to_unicode() function of the fribidi-char-sets-cap-rtl.c file. This flaw allows an attacker to pass a specially crafted file to the Fribidi application with the '--caprtl' option, leading to a crash and causing a denial of service.
- https://access.redhat.com/security/cve/CVE-2022-25309
- https://bugzilla.redhat.com/show_bug.cgi?id=2047896
- https://github.com/fribidi/fribidi/commit/f22593b82b5d1668d1997dbccd10a9c31ffea3b3
- https://github.com/fribidi/fribidi/issues/182
- https://access.redhat.com/security/cve/CVE-2022-25309
- https://bugzilla.redhat.com/show_bug.cgi?id=2047896
- https://github.com/fribidi/fribidi/commit/f22593b82b5d1668d1997dbccd10a9c31ffea3b3
- https://github.com/fribidi/fribidi/issues/182
Modified: 2024-11-21
CVE-2022-25310
A segmentation fault (SEGV) flaw was found in the Fribidi package and affects the fribidi_remove_bidi_marks() function of the lib/fribidi.c file. This flaw allows an attacker to pass a specially crafted file to Fribidi, leading to a crash and causing a denial of service.
- https://access.redhat.com/security/cve/CVE-2022-25310
- https://bugzilla.redhat.com/show_bug.cgi?id=2047923
- https://github.com/fribidi/fribidi/issues/183
- https://github.com/fribidi/fribidi/pull/186
- https://access.redhat.com/security/cve/CVE-2022-25310
- https://bugzilla.redhat.com/show_bug.cgi?id=2047923
- https://github.com/fribidi/fribidi/issues/183
- https://github.com/fribidi/fribidi/pull/186
Package qt5-webengine updated to version 5.15.9-alt1 for branch sisyphus in task 298723.
Closed vulnerabilities
Modified: 2023-11-13
BDU:2022-00893
Уязвимость пакета qt/qtbase библиотеки Qt, позволяющая нарушителю выполнить произвольный код
BDU:2023-05109
Уязвимость функции LoadLibrary кроссплатформенного фреймворка для разработки программного обеспечения Qt, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2024-11-21
CVE-2022-25255
In Qt 5.9.x through 5.15.x before 5.15.9 and 6.x before 6.2.4 on Linux and UNIX, QProcess could execute a binary from the current working directory when not found in the PATH.
- https://codereview.qt-project.org/c/qt/qtbase/+/393113
- https://codereview.qt-project.org/c/qt/qtbase/+/394914
- https://codereview.qt-project.org/c/qt/qtbase/+/396020
- https://download.qt.io/official_releases/qt/5.15/qprocess5-15.diff
- https://download.qt.io/official_releases/qt/6.2/qprocess6-2.diff
- https://codereview.qt-project.org/c/qt/qtbase/+/393113
- https://codereview.qt-project.org/c/qt/qtbase/+/394914
- https://codereview.qt-project.org/c/qt/qtbase/+/396020
- https://download.qt.io/official_releases/qt/5.15/qprocess5-15.diff
- https://download.qt.io/official_releases/qt/6.2/qprocess6-2.diff
Modified: 2024-11-21
CVE-2022-25634
Qt through 5.15.8 and 6.x through 6.2.3 can load system library files from an unintended working directory.
- https://codereview.qt-project.org/c/qt/qtbase/+/396440
- https://codereview.qt-project.org/c/qt/qtbase/+/396689
- https://codereview.qt-project.org/c/qt/tqtc-qtbase/+/396690
- https://download.qt.io/official_releases/qt/5.15/CVE-2022-25643-5.15.diff
- https://download.qt.io/official_releases/qt/6.2/CVE-2022-25643-6.2.diff
- https://codereview.qt-project.org/c/qt/qtbase/+/396440
- https://codereview.qt-project.org/c/qt/qtbase/+/396689
- https://codereview.qt-project.org/c/qt/tqtc-qtbase/+/396690
- https://download.qt.io/official_releases/qt/5.15/CVE-2022-25643-5.15.diff
- https://download.qt.io/official_releases/qt/6.2/CVE-2022-25643-6.2.diff
Package kernel-image-mp updated to version 5.17.4-alt1 for branch sisyphus in task 298754.
Closed vulnerabilities
Modified: 2024-06-19
BDU:2022-00869
Уязвимость функции kvm_s390_guest_sida_op() подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-13
BDU:2022-00889
Уязвимость подсистемы UDF ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2022-01567
Уязвимость модулей esp4 и esp6 ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-13
BDU:2022-01629
Уязвимость модуля nf_tables подсистемы netfilter ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-13
BDU:2022-01630
Уязвимость модуля nf_tables подсистемы netfilter ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-13
BDU:2022-01644
Уязвимость реализации функции tc_new_tfilter() ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-01-29
BDU:2022-02112
Уязвимость реализации функции xs_xprt_free() системы удаленного вызова процедур Sun RPC (Open Network Computing Remote Procedure Call) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-02672
Уязвимость функции ems_usb_start_xmit ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2022-02681
Уязвимость функции mcba_usb_start_xmit ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-07
BDU:2022-02816
Уязвимость функции pfkey_register ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-09-13
BDU:2022-02886
Уязвимость файла fs/io_uring.c подсистемы io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-11-07
BDU:2022-03004
Уязвимость системного вызова PTRACE_SEIZE безопасного режима вычислений seccomp ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-01-29
BDU:2022-03034
Уязвимость реализации функции get_user_pages_fast() подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-09-30
BDU:2022-03400
Уязвимость функции scsi_ioctl ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-09-30
BDU:2022-03409
Уязвимость компонента net/llc/af_llc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-19
BDU:2022-03903
Уязвимость реализации функций preparse_server_key(), free_preparse_server_key() и destroy_server_key() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-19
BDU:2022-03904
Уязвимость реализации функции acrn_dev_ioctl() модуля службы гипервизора ACRN (HSM) ядра операционных систем Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2022-05411
Уязвимость функции usb_8dev_start_xmit ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-30
BDU:2022-05717
Уязвимость звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-05723
Уязвимость файловой системы FUSE ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2022-05777
Уязвимость ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2024-03-01
BDU:2022-05794
Уязвимость функций Signalfd_poll() и binder_poll() ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-05844
Уязвимость функции diFree (fs/jfs/inode.c) журналируемой файловой системы (JFS) ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2022-05852
Уязвимость реализации прокси-виртуализированных TPM-устройств ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-09-30
BDU:2022-05855
Уязвимость функции em28xx_usb_probe драйвера video4linux ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-06-10
BDU:2022-05890
Уязвимость драйвера GPU i915 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-06397
Уязвимость драйвера drivers/net/hamradio/6pack.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-06399
Уязвимость реализации протокола Amateur Radio AX.25 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-06400
Уязвимость реализации протокола Amateur Radio AX.25 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-00629
Уязвимость функции sl_tx_timeout() в модуле drivers/net/slip.c драйвера SLIP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2023-01191
Уязвимость драйвера Qualcomm USB 3.0 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-02-24
BDU:2023-01208
Уязвимость функции qmp_get() (drivers/soc/qcom/qcom_aoss.c) драйвера Qualcomm AOSS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-02-24
BDU:2023-01211
Уязвимость функции tegra_xusb_find_port_node() (drivers/phy/tegra/xusb.c) драйвера NVIDIA Tegra XUSB Pad ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-01-20
BDU:2023-01298
Уязвимость подсистемы OverlayFS ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-30
BDU:2023-02164
Уязвимость функции io_file_get_fixed() модуля io_uring/io_uring.c ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-04-27
BDU:2023-03668
Уязвимость функции mctp_unregister() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-01-09
BDU:2023-04899
Уязвимость функции btrfs_get_root_ref() в модуле fs/btrfs/disk-io.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или получить доступ к защищаемой информации
Modified: 2024-08-26
BDU:2024-04151
Уязвимость функции macvlan_handle_frame() в модуле drivers/net/macvlan.c сетевой компоненты ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06066
Уязвимость функции vm_area_alloc_pages() менеджера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-06528
Уязвимость функции iavf_shutdown() в компоненте iavf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-06529
Уязвимость функции blkcg_init_queue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-04
BDU:2024-06684
Уязвимость функции ice_update_vsi_tx_ring_stats() в компоненте ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-04
BDU:2024-06686
Уязвимость компонента mpt3sas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-04
BDU:2024-06687
Уязвимость функции rndis_set_response() в компоненте rndis ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-11
BDU:2024-06688
Уязвимость компонента gadget ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-04
BDU:2024-06689
Уязвимость компонента net/packet ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07586
Уязвимость компонента usbtmc ядра операционной системы Linux, позволяющая нарушению оказать влияние на конфидециальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-07635
Уязвимость функции usb_submit_urb() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-18
BDU:2024-08412
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации
Modified: 2025-05-06
BDU:2025-01035
Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2025-03057
Уязвимость функции bprm_stack_limits() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-04343
Уязвимость функции ice_free_cpu_rx_rmap() модуля drivers/net/ethernet/intel/ice/ice_arfs.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04344
Уязвимость функции ep93xx_clk_register_gate() модуля arch/arm/mach-ep93xx/clock.c поддержки процессоров серии Cirrus EP93xx ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04345
Уязвимость функции vpif_probe() модуля drivers/media/platform/davinci/vpif.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04346
Уязвимость функции kvm_tdp_mmu_put_root() модуля arch/x86/kvm/mmu/tdp_mmu.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04429
Уязвимость функции hfi1_mmu_rb_unregister() модуля drivers/infiniband/hw/hfi1/mmu_rb.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-04430
Уязвимость функции nci_close_device() модуля net/nfc/nci/core.c поддержки реализации NFC NCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04431
Уязвимость функции tcmu_try_get_block_page() модуля drivers/target/target_core_user.c - драйвера поддержки TCM ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04432
Уязвимость функции jffs2_do_fill_super() модуля fs/jffs2/fs.c поддержки файловой системы jffs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04433
Уязвимость функции bfq_setup_merge() модуля block/bfq-iosched.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-06011
Уязвимость функции null_timeout_rq() модуля drivers/block/null_blk/main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06012
Уязвимость функции smc_pnet_find_ib() модуля net/smc/smc_pnet.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06013
Уязвимость функции altr_tse_pcs() ядр ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06015
Уязвимость функции veth_xmit() модуля drivers/net/veth.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06036
Уязвимость функции parse_mf_symlink() модуля fs/cifs/link.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06038
Уязвимость модуля include/trace/events/sunrpc.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06039
Уязвимость функции virt_addr_valid() модуля arch/powerpc/include/asm/page.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06040
Уязвимость функции btrfs_get_blocks_direct_write() файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06042
Уязвимость функции ili9341_dbi_probe() модуля drivers/gpu/drm/panel/panel-ilitek-ili9341.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06043
Уязвимость функций gpiochip_to_irq() и gpiochip_add_irqchip() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06044
Уязвимость функции SATA_DWC_QCMD_MAX() модуля drivers/ata/sata_dwc_460ex.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06045
Уязвимость функций gic_dist_base() и gic_do_wait_for_rwp() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06049
Уязвимость модуля fs/btrfs/extent_io.h файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
BDU:2025-06051
Уязвимость модуля mm/mremap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06053
Уязвимость функций __kmap_local_sched_out() и __kmap_local_sched_in() модуля mm/highmem.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06058
Уязвимость функции qede_build_skb() модуля drivers/net/ethernet/qlogic/qede/qede_fp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06059
Уязвимость функций dpaa2_ptp_probe() и fsl_mc_free_irqs() модуля drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06060
Уязвимость функции spin_lock_irqsave() модуля drivers/infiniband/sw/rdmavt/qp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06061
Уязвимость функции secondary_start_kernel() модуля arch/arm64/kernel/smp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06062
Уязвимость функции omap_iommu_probe_device() модуля drivers/iommu/omap-iommu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06063
Уязвимость функции kmem_cache_alloc() модуля mm/mempolicy.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06065
Уязвимость функций nla_alloc_flow_actions() и ovs_nla_free_set_action() модуля net/openvswitch/flow_netlink.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06551
Уязвимость функции _scsih_expander_node_remove() модуля drivers/scsi/mpt3sas/mpt3sas_scsih.c - драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-06552
Уязвимость функции rxrpc_exit_net() модуля net/rxrpc/net_ns.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-06553
Уязвимость функции LZ4_decompress_generic() модуля lib/lz4/lz4_decompress.c поддержки сжатия lz4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-06573
Уязвимость функции nla_put_notification_header() модуля drivers/block/drbd/drbd_nl.c - драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10247
Уязвимость ядра операционной системы Linux, связанная с ошибкой повторного освобождения памяти, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность
Modified: 2026-01-20
BDU:2025-10262
Уязвимость функции hci_disconn_phylink_complete_evt() модуля net/bluetooth/hci_event.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-02-17
BDU:2025-10263
Уязвимость функции btrfs_repair_one_sector() модуля fs/btrfs/extent_io.c поддержки файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10264
Уязвимость функции tpm_dev_release() модуля drivers/char/tpm/tpm-chip.c - драйвера поддержки алфавитно-цифровых устройств с TPM ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10267
Уязвимость функции snd_pcm_lib_preallocate_proc_write() модуля sound/core/pcm_memory.c поддержки аудио карт ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10268
Уязвимость функции snd_pcm_attach_substream() модуля sound/core/pcm.c поддержки аудио карт ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-10565
Уязвимость функции dev_attribute_show() модуля drivers/mtd/ubi/build.c - драйвера поддержки памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-10582
Уязвимость функции cleanup_mapped_device() модуля drivers/md/dm.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10583
Уязвимость функции cc_cipher_exit() модуля drivers/crypto/ccree/cc_cipher.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10585
Уязвимость функции btf_id_set_contains() модуля kernel/bpf/btf.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10586
Уязвимость функции cxl_decoder_release() модуля drivers/cxl/core/bus.c - драйвера поддержки устройств CXL (Compute Express Link) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10587
Уязвимость функции bfq_bfqq_move() модуля block/bfq-cgroup.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10588
Уязвимость функции bfq_dispatch_request() модуля block/bfq-iosched.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10590
Уязвимость функции mt7921_stop() модуля drivers/net/wireless/mediatek/mt76/mt7921/main.c - драйвера поддержки адаптеров беспроводной связи Mediatek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10592
Уязвимость функции skb_try_coalesce() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-14262
Уязвимость функции btrfs_put_block_group() модуля fs/btrfs/block-group.c поддержки файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01253
Уязвимость функций init() и fini() модуля drivers/char/virtio_console.c драйвера поддержки алфавитноцифровых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01254
Уязвимость функции _nfs42_proc_copy_notify() модуля fs/nfs/nfs42proc.c поддержки клиентов NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01255
Уязвимость функции gc_worker_can_early_drop() модуля net/netfilter/nf_conntrack_core.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01256
Уязвимость функции ill_acc_of_setup() модуля arch/mips/ralink/ill_acc.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01257
Уязвимость функции interrupt_preinit_v3_hw() модуля drivers/scsi/hisi_sas/hisi_sas_v3_hw.c драйвера поддержки устройств SCSI HiSilicon SAS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01258
Уязвимость функции pm8001_chip_fw_flash_update_req() модуля drivers/scsi/pm8001/pm8001_hwi.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01260
Уязвимость функции hci_conn_complete_evt() модуля net/bluetooth/hci_event.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01263
Уязвимость функции vmbus_bus_init() модуля drivers/hv/vmbus_drv.c драйвера поддержки гостевого режима Microsoft HyperV ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01264
Уязвимость функции alloc_event_waiters() модуля drivers/gpu/drm/amd/amdkfd/kfd_events.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01265
Уязвимость функции nfs_set_pgio_error() модуля fs/nfs/pagelist.c поддержки клиентов NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01395
Уязвимость функции tpm2_init_space() модуля drivers/char/tpm/tpm2-space.c драйвера поддержки алфавитноцифровых устройств с TPM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01463
Уязвимость функции nwl_dsi_bridge_mode_set() модуля drivers/gpu/drm/bridge/nwl-dsi.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01464
Уязвимость функции __mcheck_cpu_apply_quirks() модуля arch/x86/kernel/cpu/mce/core.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01465
Уязвимость функции lookup_ioctl() модуля drivers/md/dm-ioctl.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01491
Уязвимость функции fc_exch_abts_resp() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01493
Уязвимость функции sanity_check_curseg() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01501
Уязвимость функции snd_pcm_oss_period_size() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01532
Уязвимость функции qla2x00_bsg_job_done() модуля drivers/scsi/qla2xxx/qla_bsg.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01533
Уязвимость функции mt8183_da7219_max98357_dev_probe() модуля sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01534
Уязвимость функции smtcfb_write() модуля drivers/video/fbdev/sm712fb.c драйвера поддержки устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01535
Уязвимость функции ntfs_read_inode_mount() модуля fs/ntfs/inode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01536
Уязвимость функций ext4_writepage(), mpage_prepare_extent_to_map() модуля fs/ext4/inode.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01538
Уязвимость функции kfd_process_notifier_release() модуля drivers/gpu/drm/amd/amdkfd/kfd_process.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01539
Уязвимость функции mlxsw_sp_pude_event_func() модуля drivers/net/ethernet/mellanox/mlxsw/spectrum.c драйвера поддержки сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01540
Уязвимость функции dp_link_settings_read() модуля drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01541
Уязвимость функции hci_sync_conn_complete_evt() модуля net/bluetooth/hci_event.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01542
Уязвимость функции avic_pi_update_irte() модуля arch/x86/kvm/svm/avic.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01543
Уязвимость функции qla2xxx_create_qpair() модуля drivers/scsi/qla2xxx/qla_init.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01544
Уязвимость функции qla24xx_handle_plogi_done_event() модуля drivers/scsi/qla2xxx/qla_init.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01545
Уязвимость функций qla2x00_async_login_sp_done(), qla2x00_async_adisc_sp_done(), qla2x00_async_prli_sp_done() модуля drivers/scsi/qla2xxx/qla_init.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01547
Уязвимость функции pm8001_send_abort_all() модуля drivers/scsi/pm8001/pm8001_hwi.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01548
Уязвимость функции pm8001_chip_reg_dev_req() модуля drivers/scsi/pm8001/pm8001_hwi.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02208
Уязвимость функции ext4_mb_mark_bb() в модуле fs/ext4/mballoc.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02209
Уязвимость функции device_pm_check_callbacks() в модуле drivers/base/power/main.c драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02210
Уязвимость функции cifs_kill_sb() модуля fs/cifs/cifsfs.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02249
Уязвимость функции flush_cache_range() в модуле arch/parisc/kernel/cache.c поддержки архитектуры PARISC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02250
Уязвимость функции ath5k_eeprom_convert_pcal_info_5111() модуля drivers/net/wireless/ath/ath5k/eeprom.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02594
Уязвимость функции xdr_stream_decode_uint32_array() модуля include/linux/sunrpc/xdr.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02595
Уязвимость функции nfsd_proc_write() модуля fs/nfsd/nfsproc.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03102
Уязвимость функции format_show() модуля arch/powerpc/kernel/secvar-sysfs.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03104
Уязвимость функции blkcg_iolatency_done_bio() модуля block/blk-iolatency.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03105
Уязвимость функции btrfs_submit_compressed_read() модуля fs/btrfs/compression.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03241
Уязвимость функции venus_helper_alloc_dpb_bufs() модуля drivers/media/platform/qcom/venus/helpers.c драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03289
Уязвимость функции __mptcp_alloc_tx_skb() модуля net/mptcp/protocol.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03371
Уязвимость функции f2fs_build_stats() модуля fs/f2fs/debug.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03372
Уязвимость функции dcn31_validate_bandwidth() модуля drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03489
Уязвимость функции smb2_ioctl_query_info() модуля fs/cifs/smb2ops.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03490
Уязвимость функции ocfs2_unlock_global_qf() модуля fs/ocfs2/quota_global.c файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03491
Уязвимость функции sysfb_create_simplefb() модуля drivers/firmware/sysfb_simplefb.c драйвера поддержки прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03492
Уязвимость функции mma8452_show_scale_avail() модуля drivers/iio/accel/mma8452.c драйвера поддержки различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03512
Уязвимость функции cpt_register_algs() модуля drivers/crypto/marvell/octeontx2/otx2_cptvf_algs.c драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03530
Уязвимость функции s2250_probe() модуля drivers/media/usb/go7007/s2250-board.c драйвера поддержки мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03535
Уязвимость функции rxrpc_propose_ACK() модуля net/rxrpc/ar-internal.h поддержки сокетов сеанса RxRPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03551
Уязвимость функции netlink_group_mask() модуля net/netlink/af_netlink.c поддержки интерфейса мониторинга сокетов NETLINK ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03552
Уязвимость функции mxc_jpeg_device_run() модуля drivers/media/platform/imx-jpeg/mxc-jpeg.c драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03553
Уязвимость функции __tm_recheckpoint модуля arch/powerpc/kernel/tm.S поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03554
Уязвимость функции qla24xx_free_purex_list() модуля drivers/scsi/qla2xxx/qla_os.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03555
Уязвимость функций ath11k_pci_pm_suspend() и ath11k_pci_pm_resume() модуля drivers/net/wireless/ath/ath11k/pci.c драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03648
Уязвимость функции nvidia_setup_i2c_bus() модуля drivers/video/fbdev/nvidia/nv_i2c.c драйвера поддержки устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03649
Уязвимость функции snd_soc_new_compress() модуля sound/soc/soc-compress.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03650
Уязвимость функции smu_v12_0_fini_smc_tables() модуля drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03651
Уязвимость функции dm_integrity_ctr() модуля drivers/md/dm-integrity.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03652
Уязвимость функции rpcif_probe() модуля drivers/memory/renesas-rpc-if.c драйвера контроллера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03653
Уязвимость функции aqc111_rx_fixup() модуля drivers/net/usb/aqc111.c драйвера поддержки сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03654
Уязвимость функции imx_pd_connector_get_modes() модуля drivers/gpu/drm/imx/parallel-display.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03655
Уязвимость функции zorro7xx_remove_one() модуля drivers/scsi/zorro7xx.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03656
Уязвимость функции acpi_cppc_processor_probe() модуля drivers/acpi/cppc_acpi.c драйвера поддержки ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03657
Уязвимость функции cpsw_ethtool_op_begin() модуля drivers/net/ethernet/ti/cpsw_ethtool.c драйвера поддержки сетевых адаптеров Ethernet Texas Instruments ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03658
Уязвимость функций bcmgenet_writel(), bcmgenet_readl() модуля drivers/net/ethernet/broadcom/genet/bcmgenet.c драйвера сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03659
Уязвимость функции nldev_stat_set_counter_dynamic_doit() модуля drivers/infiniband/core/nldev.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03660
Уязвимость функции pm8001_send_abort_all() модуля drivers/scsi/pm8001/pm8001_hwi.c - драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03661
Уязвимость функции dax_fs_init() модуля drivers/dax/super.c драйвера поддержки устройств DAX (direct access mapping device) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03662
Уязвимость функции asix_read_cmd() модуля drivers/net/usb/asix_common.c драйвера поддержки сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03663
Уязвимость функции at91sam9g20ek_audio_probe() модуля sound/soc/atmel/sam9g20_wm8731.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03664
Уязвимость функции stk1160_disconnect() модуля drivers/media/usb/stk1160/stk1160-core.c драйвера поддержки мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03665
Уязвимость функций wcd938x_tx_mode_get(), wcd938x_rx_hph_mode_get() модуля sound/soc/codecs/wcd938x.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03666
Уязвимость функции rx_macro_load_compander_coeff() модуля sound/soc/codecs/lpass-rx-macro.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03667
Уязвимость функции rx_macro_get_hph_pwr_mode() модуля sound/soc/codecs/lpass-rx-macro.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03668
Уязвимость функции f2fs_handle_failed_inode() модуля fs/f2fs/inode.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03669
Уязвимость функции sec_aead_soft_crypto() модуля drivers/crypto/hisilicon/sec2/sec_crypto.c драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03670
Уязвимость функции nft_do_chain() модуля net/netfilter/nf_tables_core.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03811
Уязвимость функции skb_unclone_keeptruesize() модуля net/core/skbuff.h поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03821
Уязвимость функции secretmem_file_create() модуля mm/secretmem.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03822
Уязвимость функции __skb_pull() модуля include/linux/skbuff.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03833
Уязвимость функции swap_readpage() модуля mm/page_io.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03844
Уязвимость функции vmbus_exit() модуля drivers/hv/vmbus_drv.c драйвера поддержки гостевого режима Microsoft HyperV ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03860
Уязвимость функции dsa_switch_bridge_leave() модуля net/dsa/switch.c поддержки коммутаторов с распределенной архитектурой ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03871
Уязвимость функции rproc_coredump_write() модуля drivers/remoteproc/remoteproc_debugfs.c драйвера поддержки подсистемы удаленного процессора ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03885
Уязвимость функции ice_misc_intr() модуля drivers/net/ethernet/intel/ice/ice_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03892
Уязвимость функции irtoy_probe() модуля drivers/media/rc/ir_toy.c драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03927
Уязвимость функции clk_core_get_parent_by_index() модуля drivers/clk/clk.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03928
Уязвимость функции ubifs_write_end() модуля fs/ubifs/file.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03930
Уязвимость функции user_addr_max() модуля arch/csky/include/asm/uaccess.h ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03931
Уязвимость функций va_macro_dec_mode_get(), va_macro_dec_mode_put() модуля sound/soc/codecs/lpass-va-macro.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03932
Уязвимость функции mxc_jpeg_device_run() модуля drivers/media/platform/imx-jpeg/mxc-jpeg.c драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03933
Уязвимость функции decrypt_internal() модуля net/tls/tls_sw.c реализации протокола TLS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03935
Уязвимость функции tcp_bpf_sendmsg_redir() модуля net/ipv4/tcp_bpf.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03936
Уязвимость функции vm_access() модуля drivers/gpu/drm/i915/gem/i915_gem_mman.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04040
Уязвимость функции isotp_bind() модуля net/can/isotp.c подсистемы шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04041
Уязвимость функции genpd_remove() модуля drivers/base/power/domain.c драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04042
Уязвимость функции blk_unregister_queue() модуля block/blk-sysfs.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04043
Уязвимость функции ptp_clock_register() модуля drivers/ptp/ptp_clock.c драйвера поддержки часов PTP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04044
Уязвимость функции igc_setup_rx_resources() модуля drivers/net/ethernet/intel/igc/igc_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04062
Уязвимость функции fib_nh_match() модуля net/ipv4/fib_semantics.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04070
Уязвимость функции virtio_device_restore() модуля drivers/virtio/virtio.c поддержки шины virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04072
Уязвимость функции btrfs_can_activate_zone() модуля fs/btrfs/zoned.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04073
Уязвимость функции ip6_forward() модуля net/ipv6/ip6_output.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04074
Уязвимость функции udmabuf_create() модуля drivers/dma-buf/udmabuf.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04309
Уязвимость функции cl_stream_prepare() модуля sound/soc/sof/intel/hda-loader.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04312
Уязвимость функции watch_queue_set_size() модуля kernel/watch_queue.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04313
Уязвимость функции free_watch() модуля kernel/watch_queue.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04314
Уязвимость функции cal_ctx_v4l2_init_formats() модуля drivers/media/platform/ti-vpe/cal-video.c драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04315
Уязвимость функции fcp_avc_transaction() модуля sound/firewire/fcp.c звуковой подсистнмы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04316
Уязвимость функции snd_proto_probe() модуля sound/soc/atmel/mikroe-proto.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04317
Уязвимость функции rockchip_i2s_tdm_resume() модуля sound/soc/rockchip/rockchip_i2s_tdm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04318
Уязвимость функции dsa_switch_shutdown() модуля net/dsa/dsa2.c поддержки коммутаторов с распределенной архитектурой ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04319
Уязвимость функции mxser_activate() модуля drivers/tty/mxser.c драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04320
Уязвимость функции q6v5_alloc_memory_region() модуля drivers/remoteproc/qcom_q6v5_mss.c драйвера поддержки подсистемы удаленного процессора ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04321
Уязвимость функции mt8192_mt6359_dev_probe() модуля sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04322
Уязвимость функции btf_check_all_types() модуля kernel/bpf/btf.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04323
Уязвимость функции segments_edid_read() модуля drivers/gpu/drm/bridge/analogix/anx7625.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04324
Уязвимость функции __bad_page_fault() модуля arch/powerpc/mm/fault.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04325
Уязвимость функции h5_enqueue() модуля drivers/bluetooth/hci_h5.c драйвера поддержки устройств Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04326
Уязвимость функции btmtksdio_probe() модуля drivers/bluetooth/btmtksdio.c драйвера поддержки устройств Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04478
Уязвимость функции to_zoran() модуля drivers/staging/media/zoran/zoran.h драйвера поддержки подготовки медиа-данных ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04666
Уязвимость функции mspro_block_bd_open() в модуле drivers/memstick/core/mspro_block.c драйвера поддержки карт Sony MemoryStick ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04902
Уязвимость функции fsi_spi_transfer_data() модуля drivers/spi/spi-fsi.c драйвера поддержки устройств SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2020-35501
A flaw was found in the Linux kernels implementation of audit rules, where a syscall can unexpectedly not be correctly not be logged by the audit subsystem
Modified: 2024-11-21
CVE-2021-3743
An out-of-bounds (OOB) memory read flaw was found in the Qualcomm IPC router protocol in the Linux kernel. A missing sanity check allows a local attacker to gain access to out-of-bounds memory, leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.
- https://bugzilla.redhat.com/show_bug.cgi?id=1997961
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e78c597c3eb
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e78c597c3ebfd0cb329aa09a838734147e4f117
- https://github.com/torvalds/linux/commit/7e78c597c3ebfd0cb329aa09a838734147e4f117
- https://lists.openwall.net/netdev/2021/08/17/124
- https://security.netapp.com/advisory/ntap-20220407-0007/
- https://www.openwall.com/lists/oss-security/2021/08/27/2
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=1997961
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e78c597c3eb
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e78c597c3ebfd0cb329aa09a838734147e4f117
- https://github.com/torvalds/linux/commit/7e78c597c3ebfd0cb329aa09a838734147e4f117
- https://lists.openwall.net/netdev/2021/08/17/124
- https://security.netapp.com/advisory/ntap-20220407-0007/
- https://www.openwall.com/lists/oss-security/2021/08/27/2
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2021-3847
An unauthorized access to the execution of the setuid file with capabilities flaw in the Linux kernel OverlayFS subsystem was found in the way user copying a capable file from a nosuid mount into another mount. A local user could use this flaw to escalate their privileges on the system.
Modified: 2025-10-01
CVE-2021-47631
In the Linux kernel, the following vulnerability has been resolved: ARM: davinci: da850-evm: Avoid NULL pointer dereference With newer versions of GCC, there is a panic in da850_evm_config_emac() when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine: Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1 Hardware name: Generic DT based system PC is at da850_evm_config_emac+0x1c/0x120 LR is at do_one_initcall+0x50/0x1e0 The emac_pdata pointer in soc_info is NULL because davinci_soc_info only gets populated on davinci machines but da850_evm_config_emac() is called on all machines via device_initcall(). Move the rmii_en assignment below the machine check so that it is only dereferenced when running on a supported SoC.
- https://git.kernel.org/stable/c/0940795c6834fbe7705acc5c3d4b2f7a5f67527a
- https://git.kernel.org/stable/c/0a312ec66a03133d28570f07bc52749ccfef54da
- https://git.kernel.org/stable/c/83a1cde5c74bfb44b49cb2a940d044bb2380f4ea
- https://git.kernel.org/stable/c/89931d4762572aaee6edbe5673d41f8082de110f
- https://git.kernel.org/stable/c/a12b356d45cbb6e8a1b718d1436b3d6239a862f3
- https://git.kernel.org/stable/c/c06f476e5b74bcabb8c4a2fba55864a37e62843b
- https://git.kernel.org/stable/c/c5628533a3ece64235d04fe11ec44d2be99e423d
- https://git.kernel.org/stable/c/c64e2ed5cc376e137e572babfd2edc38b2cfb61b
Modified: 2025-10-01
CVE-2021-47632
In the Linux kernel, the following vulnerability has been resolved: powerpc/set_memory: Avoid spinlock recursion in change_page_attr() Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines") included a spin_lock() to change_page_attr() in order to safely perform the three step operations. But then commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against concurrent accesses") modify it to use pte_update() and do the operation safely against concurrent access. In the meantime, Maxime reported some spinlock recursion. [ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217 [ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0 [ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523 [ 15.373350] Workqueue: events do_free_init [ 15.377615] Call Trace: [ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable) [ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4 [ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0 [ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8 [ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94 [ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134 [ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8 [ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c [ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8 [ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94 [ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8 [ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8 [ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210 [ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c Remove the read / modify / write sequence to make the operation atomic and remove the spin_lock() in change_page_attr(). To do the operation atomically, we can't use pte modification helpers anymore. Because all platforms have different combination of bits, it is not easy to use those bits directly. But all have the _PAGE_KERNEL_{RO/ROX/RW/RWX} set of flags. All we need it to compare two sets to know which bits are set or cleared. For instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you know which bit gets cleared and which bit get set when changing exec permission.
Modified: 2025-09-23
CVE-2021-47633
In the Linux kernel, the following vulnerability has been resolved: ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111 The bug was found during fuzzing. Stacktrace locates it in ath5k_eeprom_convert_pcal_info_5111. When none of the curve is selected in the loop, idx can go up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound. pd = &chinfo[pier].pd_curves[idx]; There are many OOB writes using pd later in the code. So I added a sanity check for idx. Checks for other loops involving AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not used outside the loops. The patch is NOT tested with real device. The following is the fuzzing report BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] Write of size 1 at addr ffff8880174a4d60 by task modprobe/214 CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 really_probe+0x209/0x5d0
- https://git.kernel.org/stable/c/25efc5d03455c3839249bc77fce5e29ecb54677e
- https://git.kernel.org/stable/c/564d4eceb97eaf381dd6ef6470b06377bb50c95a
- https://git.kernel.org/stable/c/9d7d83d0399e23d66fd431b553842a84ac10398f
- https://git.kernel.org/stable/c/be2f81024e7981565d90a4c9ca3067d11b6bca7f
- https://git.kernel.org/stable/c/c4e2f577271e158d87a916afb4e87415a88ce856
- https://git.kernel.org/stable/c/cbd96d6cad6625feba9c8d101ed4977d53e82f8e
- https://git.kernel.org/stable/c/ed3dfdaa8b5f0579eabfc1c5818eed30cfe1fe84
- https://git.kernel.org/stable/c/f4de974019a0adf34d0e7de6b86252f1bd266b06
- https://git.kernel.org/stable/c/fc8f7752a82f4accb99c0f1a868906ba1eb7b86f
Modified: 2025-03-24
CVE-2021-47634
In the Linux kernel, the following vulnerability has been resolved: ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl Hulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ================================================================== The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held by ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can be concurrent. ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach. ubi_detach is bug-free because it uses reference counting to prevent concurrency. However, uif_init and uif_close in ubi_attach may race with ubi_cdev_ioctl. uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_del And uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double free The cause of this problem is that commit 714fb87e8bc0 make device "available" before it becomes accessible via sysfs. Therefore, we roll back the modification. We will fix the race condition between ubi device creation and udev by removing ubi_get_device in vol_attribute_show and dev_attribute_show.This avoids accessing uninitialized ubi_devices[ubi_num]. ubi_get_device is used to prevent devices from being deleted during sysfs execution. However, now kernfs ensures that devices will not be deleted before all reference counting are released. The key process is shown in the following stack. device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain
- https://git.kernel.org/stable/c/1a3f1cf87054833242fcd0218de0481cf855f888
- https://git.kernel.org/stable/c/3cbf0e392f173ba0ce425968c8374a6aa3e90f2e
- https://git.kernel.org/stable/c/432b057f8e847ae5a2306515606f8d2defaca178
- https://git.kernel.org/stable/c/5f9e9c223e48c264241d2f34d0bfc29e5fcb5c1b
- https://git.kernel.org/stable/c/a8ecee49259f8f78d91ddb329ab2be7e6fd01974
- https://git.kernel.org/stable/c/c32fe764191b8ae8b128588beb96e3718d9179d8
- https://git.kernel.org/stable/c/d727fd32cbd1abf3465f607021bc9c746f17b5a8
- https://git.kernel.org/stable/c/f149b1bd213820363731aa119e5011ca892a2aac
Modified: 2025-09-23
CVE-2021-47635
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix to add refcount once page is set private MM defined the rule [1] very clearly that once page was set with PG_private flag, we should increment the refcount in that page, also main flows like pageout(), migrate_page() will assume there is one additional page reference count if page_has_private() returns true. Otherwise, we may get a BUG in page migration: page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e" flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cut here ]------------ kernel BUG at include/linux/page_ref.h:184! invalid opcode: 0000 [#1] SMP CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Call Trace: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Before the time, we should make clean a concept, what does refcount means in page gotten from grab_cache_page_write_begin(). There are 2 situations: Situation 1: refcount is 3, page is created by __page_cache_alloc. TYPE_A - the write process is using this page TYPE_B - page is assigned to one certain mapping by calling __add_to_page_cache_locked() TYPE_C - page is added into pagevec list corresponding current cpu by calling lru_cache_add() Situation 2: refcount is 2, page is gotten from the mapping's tree TYPE_B - page has been assigned to one certain mapping TYPE_A - the write process is using this page (by calling page_cache_get_speculative()) Filesystem releases one refcount by calling put_page() in xxx_write_end(), the released refcount corresponds to TYPE_A (write task is using it). If there are any processes using a page, page migration process will skip the page by judging whether expected_page_refs() equals to page refcount. The BUG is caused by following process: PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // put page into cpu 0's pagevec (refcnf = 3, for page creation process) ubifs_write_end SetPagePrivate(page_a) // doesn't increase page count ! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS doesn't increase the page refcount after setting private flag, which leads to page migration task believes the page is not used by any other processes, so the page is migrated. This causes concurrent accessing on page refcount between put_page() called by other process(eg. read process calls lru_cache_add) and page_ref_unfreeze() called by mi ---truncated---
- https://git.kernel.org/stable/c/3b67db8a6ca83e6ff90b756d3da0c966f61cd37b
- https://git.kernel.org/stable/c/4f75bab98565afd4f905059c56ec4caba88a7eec
- https://git.kernel.org/stable/c/5aaa2c0f0052b02c4a982993d4c5bb68fb7cbe22
- https://git.kernel.org/stable/c/c34ae24a2590fee96a3a7735ba2fa6cc52306221
- https://git.kernel.org/stable/c/fbeb2139eed65e929ce806c6468e6601ade01b1b
Modified: 2025-10-01
CVE-2021-47636
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock() Function ubifs_wbuf_write_nolock() may access buf out of bounds in following process: ubifs_wbuf_write_nolock(): aligned_len = ALIGN(len, 8); // Assume len = 4089, aligned_len = 4096 if (aligned_len <= wbuf->avail) ... // Not satisfy if (wbuf->used) { ubifs_leb_write() // Fill some data in avail wbuf len -= wbuf->avail; // len is still not 8-bytes aligned aligned_len -= wbuf->avail; } n = aligned_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + written, wbuf->offs, n); // n > len, read out of bounds less than 8(n-len) bytes } , which can be catched by KASAN: ========================================================= BUG: KASAN: slab-out-of-bounds in ecc_sw_hamming_calculate+0x1dc/0x7d0 Read of size 4 at addr ffff888105594ff8 by task kworker/u8:4/128 Workqueue: writeback wb_workfn (flush-ubifs_0_0) Call Trace: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 Function ubifs_wbuf_write_nolock() accepts that parameter 'len' is not 8 bytes aligned, the 'len' represents the true length of buf (which is allocated in 'ubifs_jnl_xxx', eg. ubifs_jnl_write_inode), so ubifs_wbuf_write_nolock() must handle the length read from 'buf' carefully to write leb safely. Fetch a reproducer in [Link].
- https://git.kernel.org/stable/c/07a209fadee7b53b46858538e1177597273862e4
- https://git.kernel.org/stable/c/3b7fb89135a20587d57f8877c02e25003e9edbdf
- https://git.kernel.org/stable/c/4f2262a334641e05f645364d5ade1f565c85f20b
- https://git.kernel.org/stable/c/5343575aa11c5d7044107d59d43f84aec01312b0
- https://git.kernel.org/stable/c/a7054aaf1909cf40489c0ec1b728fdcf79c751a6
- https://git.kernel.org/stable/c/b80ccbec0e4804436c382d7dd60e943c386ed83a
- https://git.kernel.org/stable/c/e09fa5318d51f522e1af4fbaf8f74999355980c8
Modified: 2025-10-01
CVE-2021-47637
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix deadlock in concurrent rename whiteout and inode writeback Following hung tasks: [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132 [ 77.028820] Call Trace: [ 77.029027] schedule+0x8c/0x1b0 [ 77.029067] mutex_lock+0x50/0x60 [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs] [ 77.029117] __writeback_single_inode+0x43c/0x570 [ 77.029128] writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0 [ 92.390442] task:aa state:D stack: 0 pid: 1506 [ 92.390448] Call Trace: [ 92.390458] schedule+0x8c/0x1b0 [ 92.390461] wb_wait_for_completion+0x82/0xd0 [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110 [ 92.390472] writeback_inodes_sb_nr+0x14/0x20 [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs] [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs] [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs] [ 92.390571] vfs_rename+0xdb2/0x1170 [ 92.390580] do_renameat2+0x554/0x770 , are caused by concurrent rename whiteout and inode writeback processes: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_rename do_rename lock_4_inodes (Hold ui_mutex) ubifs_budget_space make_free_space shrink_liability __writeback_inodes_sb_nr bdi_split_work_to_wbs (Queue new wb work) wb_do_writeback(wb work) __writeback_single_inode ubifs_write_inode LOCK(ui_mutex) ↑ wb_wait_for_completion (Wait wb work) <-- deadlock! Reproducer (Detail program in [Link]): 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT) 2. Consume out of space before kernel(mdelay) doing budget for whiteout Fix it by doing whiteout space budget before locking ubifs inodes. BTW, it also fixes wrong goto tag 'out_release' in whiteout budget error handling path(It should at least recover dir i_size and unlock 4 ubifs inodes).
- https://git.kernel.org/stable/c/37bdf1ad592555ecda1d55b89f6e393e4c0589d1
- https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9
- https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787
- https://git.kernel.org/stable/c/8b278c8dcfb565cb65eceb62a38cbf7a7c326db5
- https://git.kernel.org/stable/c/9dddc8211430fb851ddf0b168e3a00c6f66cc185
- https://git.kernel.org/stable/c/afd427048047e8efdedab30e8888044e2be5aa9c
- https://git.kernel.org/stable/c/c58af8564a7b08757173009030b74baf4b2b762b
Modified: 2025-10-01
CVE-2021-47638
In the Linux kernel, the following vulnerability has been resolved: ubifs: rename_whiteout: Fix double free for whiteout_ui->data 'whiteout_ui->data' will be freed twice if space budget fail for rename whiteout operation as following process: rename_whiteout dev = kmalloc whiteout_ui->data = dev kfree(whiteout_ui->data) // Free first time iput(whiteout) ubifs_free_inode kfree(ui->data) // Double free! KASAN reports: ================================================================== BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70 Call Trace: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Allocated by task 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Freed by task 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 The buggy address belongs to the object at ffff88810238bed8 which belongs to the cache kmalloc-8 of size 8 ================================================================== Let ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused assignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode() -> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it (because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release', and the nlink of whiteout inode is 0).
- https://git.kernel.org/stable/c/14276d38c89a170363e90b6ac0a53c3cf61b87fc
- https://git.kernel.org/stable/c/2ad07009c459e56ebdcc089d850d664660fdb742
- https://git.kernel.org/stable/c/2b3236ecf96db7af5836e1366ce39ace8ce832fa
- https://git.kernel.org/stable/c/40a8f0d5e7b3999f096570edab71c345da812e3e
- https://git.kernel.org/stable/c/6d7a158a7363c1f6604aa47ae1a280a5c65123dd
- https://git.kernel.org/stable/c/8b3c7be16f3f4dfd6e15ac651484e59d3fa36274
- https://git.kernel.org/stable/c/a90e2dbe66d2647ff95a0442ad2e86482d977fd8
- https://git.kernel.org/stable/c/b9a937f096e608b3368c1abc920d4d640ba2c94f
Modified: 2025-03-24
CVE-2021-47639
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU
Zap both valid and invalid roots when zapping/unmapping a gfn range, as
KVM must ensure it holds no references to the freed page after returning
from the unmap operation. Most notably, the TDP MMU doesn't zap invalid
roots in mmu_notifier callbacks. This leads to use-after-free and other
issues if the mmu_notifier runs to completion while an invalid root
zapper yields as KVM fails to honor the requirement that there must be
_no_ references to the page after the mmu_notifier returns.
The bug is most easily reproduced by hacking KVM to cause a collision
between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug
exists between kvm_mmu_notifier_invalidate_range_start() and memslot
updates as well. Invalidating a root ensures pages aren't accessible by
the guest, and KVM won't read or write page data itself, but KVM will
trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing
a zap of an invalid root _after_ the mmu_notifier returns is fatal.
WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm]
RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm]
Call Trace:
Modified: 2025-10-01
CVE-2021-47640
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix early region not updated correctly The shadow's page table is not updated when PTE_RPN_SHIFT is 24 and PAGE_SHIFT is 12. It not only causes false positives but also false negative as shown the following text. Fix it by bringing the logic of kasan_early_shadow_page_entry here. 1. False Positive: ================================================================== BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50 Write of size 16 at addr f57f3be0 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1 Call Trace: [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable) [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300 [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200 [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0 [c80d1cc0] [c03018a4] memset+0x34/0x90 [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50 [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570 [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0 [c80d1db0] [c2036580] init_sd+0xc4/0x1d0 [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384 [c80d1ef0] [c0004b14] kernel_init+0x24/0x170 [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64 Memory state around the buggy address: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== 2. False Negative (with KASAN tests): ================================================================== Before fix: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039 KASAN failure expected in "((volatile char *)area)[3100]", but none occurred not ok 46 - vmalloc_oob not ok 1 - kasan ================================================================== After fix: ok 1 - kasan
- https://git.kernel.org/stable/c/5a3d8f3192a409893c57808cc935e16484df1068
- https://git.kernel.org/stable/c/7f19245c3647afea8c7c41f795506ef70f64b9f2
- https://git.kernel.org/stable/c/dd75080aa8409ce10d50fb58981c6b59bf8707d3
- https://git.kernel.org/stable/c/de56beace6648065d404cd9835aa7d30e3df519d
- https://git.kernel.org/stable/c/e3d157a4b4f4e0268c98be5b7013bf4b31234bb6
- https://git.kernel.org/stable/c/f39a3309393a4a484532f6ba745c6acbcfe06115
Modified: 2025-10-01
CVE-2021-47641
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: cirrusfb: check pixclock to avoid divide by zero Do a sanity check on pixclock value to avoid divide by zero. If the pixclock value is zero, the cirrusfb driver will round up pixclock to get the derived frequency as close to maxclock as possible. Syzkaller reported a divide error in cirrusfb_check_pixclock. divide error: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260 Call Trace: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
- https://git.kernel.org/stable/c/1d3fb46439ad4e8f0c5739eb33d1875ac9e0f135
- https://git.kernel.org/stable/c/40b13e3d85744210db13457785646634e2d056bd
- https://git.kernel.org/stable/c/45800c42ef000f417270bcfc08630e42486fca99
- https://git.kernel.org/stable/c/53a2088a396cfa1da92690a1da289634cd73bf0d
- https://git.kernel.org/stable/c/5c6f402bdcf9e7239c6bc7087eda71ac99b31379
- https://git.kernel.org/stable/c/6fe23ff94e7840097202e85c148688940b37c9b1
- https://git.kernel.org/stable/c/8c7e2141fb89c620ab4e41512e262fbf25b8260d
- https://git.kernel.org/stable/c/c656d04247a2654ede5cead2ecbf83431dad5261
- https://git.kernel.org/stable/c/e498b504f8c81b07efab9febf8503448de4dc9cf
Modified: 2025-09-23
CVE-2021-47642
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow Coverity complains of a possible buffer overflow. However, given the 'static' scope of nvidia_setup_i2c_bus() it looks like that can't happen after examiniing the call sites. CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW) 1. fixed_size_dest: You might overrun the 48-character fixed-size string chan->adapter.name by copying name without checking the length. 2. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. 89 strcpy(chan->adapter.name, name); Fix this warning by using strscpy() which will silence the warning and prevent any future buffer overflows should the names used to identify the channel become much longer.
- https://git.kernel.org/stable/c/055cdd2e7b992921424d4daaa285ced787fb205f
- https://git.kernel.org/stable/c/08dff482012758935c185532b1ad7d584785a86e
- https://git.kernel.org/stable/c/37a1a2e6eeeb101285cd34e12e48a881524701aa
- https://git.kernel.org/stable/c/41baa86b6c802cdc6ab8ff2d46c083c9be93de81
- https://git.kernel.org/stable/c/47e5533adf118afaf06d25a3e2aaaab89371b1c5
- https://git.kernel.org/stable/c/580e5d3815474b8349250c25c16416585a72c7fe
- https://git.kernel.org/stable/c/6a5226e544ac043bb2d8dc1bfe8920d02282f7cd
- https://git.kernel.org/stable/c/72dd5c46a152136712a55bf026a9aa8c1b12b60d
- https://git.kernel.org/stable/c/9ff2f7294ab0f011cd4d1b7dcd9a07d8fdf72834
Modified: 2025-09-23
CVE-2021-47643
In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: free before error exiting Fix leak in error path.
- https://git.kernel.org/stable/c/2011363c196846c083649c91ed30aeef64358d52
- https://git.kernel.org/stable/c/382e0f6958ef34eb093127b6d74c12f3b8fd0904
- https://git.kernel.org/stable/c/52cdb013036391d9d87aba5b4fc49cdfc6ea4b23
- https://git.kernel.org/stable/c/93ef3fdf3b6633c58f049e5a6be755777dde4340
- https://git.kernel.org/stable/c/99e3f83539cac6884a4df02cb204a57a184ea12b
Modified: 2025-10-01
CVE-2021-47644
In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: move videodev alloc Move some code out of zr36057_init() and create new functions for handling zr->video_dev. This permit to ease code reading and fix a zr->video_dev memory leak.
- https://git.kernel.org/stable/c/1e501ec38796f43e995731d1bcd4173cb1ccfce0
- https://git.kernel.org/stable/c/82e3a496eb56da0b9f29fdc5b63cedb3289e91de
- https://git.kernel.org/stable/c/8dce4b265a5357731058f69645840dabc718c687
- https://git.kernel.org/stable/c/bd01629315ffd5b63da91d0bd529a77d30e55028
- https://git.kernel.org/stable/c/c1ba65100a359fe28cfe37e09e10c99f247cbf1e
- https://git.kernel.org/stable/c/ff3357bffd9fb78f59762d8955afc7382a279079
Modified: 2025-10-01
CVE-2021-47645
In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com On the case tmp_dcim=1, the index of buffer is miscalculated. This generate a NULL pointer dereference later. So let's fix the calcul and add a check to prevent this to reappear.
- https://git.kernel.org/stable/c/20811bbe685ca3eddd34b0c750860427d7030910
- https://git.kernel.org/stable/c/20db2ed1e2f9fcd417fa67853e5154f0c2537d6c
- https://git.kernel.org/stable/c/7e76f3ed7ab2ae026c6ef9cc23096a7554af8c52
- https://git.kernel.org/stable/c/8dce4b265a5357731058f69645840dabc718c687
- https://git.kernel.org/stable/c/bafec1a6ba4b187a7fcdcfce0faebdc623d4ef8e
- https://git.kernel.org/stable/c/e3b86f4e558cea9eed71d894df2f19b10d60a207
Modified: 2025-03-24
CVE-2021-47646
In the Linux kernel, the following vulnerability has been resolved: Revert "Revert "block, bfq: honor already-setup queue merges"" A crash [1] happened to be triggered in conjunction with commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq: honor already-setup queue merges""). Yet, the reverted commit was not the one introducing the bug. In fact, it actually triggered a UAF introduced by a different commit, and now fixed by commit d29bd41428cf ("block, bfq: reset last_bfqq_created on group change"). So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges") out. This commit restores it. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503
- https://git.kernel.org/stable/c/15729ff8143f8135b03988a100a19e66d7cb7ecd
- https://git.kernel.org/stable/c/4083925bd6dc89216d156474a8076feec904e607
- https://git.kernel.org/stable/c/65d8a737452e88f251fe5d925371de6d606df613
- https://git.kernel.org/stable/c/931aff627469a75c77b9fd3823146d0575afffd6
- https://git.kernel.org/stable/c/abc2129e646af7b43025d90a071f83043f1ae76c
- https://git.kernel.org/stable/c/cc051f497eac9d8a0d816cd4bffa3415f2724871
- https://git.kernel.org/stable/c/f990f0985eda59d4f29fc83fcf300c92b1225d39
Modified: 2025-09-23
CVE-2021-47647
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: ipq8074: fix PCI-E clock oops Fix PCI-E clock related kernel oops that are caused by a missing clock parent. pcie0_rchng_clk_src has num_parents set to 2 but only one parent is actually set via parent_hws, it should also have "XO" defined. This will cause the kernel to panic on a NULL pointer in clk_core_get_parent_by_index(). So, to fix this utilize clk_parent_data to provide gcc_xo_gpll0 parent data. Since there is already an existing static const char * const gcc_xo_gpll0[] used to provide the same parents via parent_names convert those users to clk_parent_data as well. Without this earlycon is needed to even catch the OOPS as it will reset the board before serial is initialized with the following: [ 0.232279] Unable to handle kernel paging request at virtual address 0000a00000000000 [ 0.232322] Mem abort info: [ 0.239094] ESR = 0x96000004 [ 0.241778] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.244908] SET = 0, FnV = 0 [ 0.250377] EA = 0, S1PTW = 0 [ 0.253236] FSC = 0x04: level 0 translation fault [ 0.256277] Data abort info: [ 0.261141] ISV = 0, ISS = 0x00000004 [ 0.264262] CM = 0, WnR = 0 [ 0.267820] [0000a00000000000] address between user and kernel address ranges [ 0.270954] Internal error: Oops: 96000004 [#1] SMP [ 0.278067] Modules linked in: [ 0.282751] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.10 #0 [ 0.285882] Hardware name: Xiaomi AX3600 (DT) [ 0.292043] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.296299] pc : clk_core_get_parent_by_index+0x68/0xec [ 0.303067] lr : __clk_register+0x1d8/0x820 [ 0.308273] sp : ffffffc01111b7d0 [ 0.312438] x29: ffffffc01111b7d0 x28: 0000000000000000 x27: 0000000000000040 [ 0.315919] x26: 0000000000000002 x25: 0000000000000000 x24: ffffff8000308800 [ 0.323037] x23: ffffff8000308850 x22: ffffff8000308880 x21: ffffff8000308828 [ 0.330155] x20: 0000000000000028 x19: ffffff8000309700 x18: 0000000000000020 [ 0.337272] x17: 000000005cc86990 x16: 0000000000000004 x15: ffffff80001d9d0a [ 0.344391] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000006 [ 0.351508] x11: 0000000000000003 x10: 0101010101010101 x9 : 0000000000000000 [ 0.358626] x8 : 7f7f7f7f7f7f7f7f x7 : 6468626f5e626266 x6 : 17000a3a403c1b06 [ 0.365744] x5 : 061b3c403a0a0017 x4 : 0000000000000000 x3 : 0000000000000001 [ 0.372863] x2 : 0000a00000000000 x1 : 0000000000000001 x0 : ffffff8000309700 [ 0.379982] Call trace: [ 0.387091] clk_core_get_parent_by_index+0x68/0xec [ 0.389351] __clk_register+0x1d8/0x820 [ 0.394210] devm_clk_hw_register+0x5c/0xe0 [ 0.398030] devm_clk_register_regmap+0x44/0x8c [ 0.402198] qcom_cc_really_probe+0x17c/0x1d0 [ 0.406711] qcom_cc_probe+0x34/0x44 [ 0.411224] gcc_ipq8074_probe+0x18/0x30 [ 0.414869] platform_probe+0x68/0xe0 [ 0.418776] really_probe.part.0+0x9c/0x30c [ 0.422336] __driver_probe_device+0x98/0x144 [ 0.426329] driver_probe_device+0x44/0x11c [ 0.430842] __device_attach_driver+0xb4/0x120 [ 0.434836] bus_for_each_drv+0x68/0xb0 [ 0.439349] __device_attach+0xb0/0x170 [ 0.443081] device_initial_probe+0x14/0x20 [ 0.446901] bus_probe_device+0x9c/0xa4 [ 0.451067] device_add+0x35c/0x834 [ 0.454886] of_device_add+0x54/0x64 [ 0.458360] of_platform_device_create_pdata+0xc0/0x100 [ 0.462181] of_platform_bus_create+0x114/0x370 [ 0.467128] of_platform_bus_create+0x15c/0x370 [ 0.471641] of_platform_populate+0x50/0xcc [ 0.476155] of_platform_default_populate_init+0xa8/0xc8 [ 0.480324] do_one_initcall+0x50/0x1b0 [ 0.485877] kernel_init_freeable+0x234/0x29c [ 0.489436] kernel_init+0x24/0x120 [ 0.493948] ret_from_fork+0x10/0x20 [ 0.497253] Code: d50323bf d65f03c0 f94002a2 b4000302 (f9400042) [ 0.501079] ---[ end trace 4ca7e1129da2abce ]---
- https://git.kernel.org/stable/c/41e360fa73a4c2f5b78f5ded78a5375b08c206a5
- https://git.kernel.org/stable/c/5a5576ad405c3c89fc9afb245c4dcc3e412b0aa9
- https://git.kernel.org/stable/c/8b89c9e68a01a19a1dd689a42aa65d545e931899
- https://git.kernel.org/stable/c/bf8f5182b8f59309809b41c1d1730ed9ca6134b1
- https://git.kernel.org/stable/c/d02b3d4a8c525068bc5cfb4341e0023d8eb82ace
Modified: 2025-10-01
CVE-2021-47648
In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix a memory leak in 'host1x_remove()' Add a missing 'host1x_channel_list_free()' call in the remove function, as already done in the error handling path of the probe function.
- https://git.kernel.org/stable/c/025c6643a81564f066d8381b9e2f4603e0f8438f
- https://git.kernel.org/stable/c/5124a344983e1b9670dae7add0e4d00d589aabcd
- https://git.kernel.org/stable/c/6bb107332db28a0e9256c2d36a0902b85307612c
- https://git.kernel.org/stable/c/c06577a80485511b894cb688e881ef0bc2d1d296
- https://git.kernel.org/stable/c/fe1ce680560d4f0049ffa0c687de17567421c1ec
Modified: 2025-10-14
CVE-2021-47649
In the Linux kernel, the following vulnerability has been resolved: udmabuf: validate ubuf->pagecount Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR. ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount will be also equal to zero; it causes kmalloc_array() to return ZERO_PTR. Fix it by validating ubuf->pagecount before passing it to kmalloc_array().
- https://git.kernel.org/stable/c/2b6dd600dd72573c23ea180b5b0b2f1813405882
- https://git.kernel.org/stable/c/5d50f851dd307c07ca5591297093f19967c834a9
- https://git.kernel.org/stable/c/811b667cefbea9cb7511a874b169d6a92907137e
- https://git.kernel.org/stable/c/9e9b4a269f84d3230f2af84ff42322db676440d9
- https://git.kernel.org/stable/c/a3728d32fc61eb0fe283cb8ff60b2c8f751e2202
- https://git.kernel.org/stable/c/b267a8118c2b171bf7d67b90ed64154eeab9fae0
Modified: 2025-09-23
CVE-2021-47650
In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-compress: prevent the potentially use of null pointer There is one call trace that snd_soc_register_card() ->snd_soc_bind_card()->soc_init_pcm_runtime() ->snd_soc_dai_compress_new()->snd_soc_new_compress(). In the trace the 'codec_dai' transfers from card->dai_link, and we can see from the snd_soc_add_pcm_runtime() in snd_soc_bind_card() that, if value of card->dai_link->num_codecs is 0, then 'codec_dai' could be null pointer caused by index out of bound in 'asoc_rtd_to_codec(rtd, 0)'. And snd_soc_register_card() is called by various platforms. Therefore, it is better to add the check in the case of misusing. And because 'cpu_dai' has already checked in soc_init_pcm_runtime(), there is no need to check again. Adding the check as follow, then if 'codec_dai' is null, snd_soc_new_compress() will not pass through the check 'if (playback + capture != 1)', avoiding the leftover use of 'codec_dai'.
- https://git.kernel.org/stable/c/08af6da684b44097ea09f1d74d5858b837ed203b
- https://git.kernel.org/stable/c/4639c1d97f385f4784f44d66a3da0672f4951ada
- https://git.kernel.org/stable/c/68a69ad8df959e5211ed4a8e120783b2d352ea74
- https://git.kernel.org/stable/c/de2c6f98817fa5decb9b7d3b3a8a3ab864c10588
- https://git.kernel.org/stable/c/f69a75cb8a98c6c487d620442c68595726a69f60
- https://git.kernel.org/stable/c/fc237b8d624f4bcb0f21a532627ce4e3b3a85569
Modified: 2025-10-01
CVE-2021-47651
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: rpmpd: 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/31b5124d742969ea8bf7a1360596f548ca23e770
- https://git.kernel.org/stable/c/5a811126d38f9767a20cc271b34db7c8efc5a46c
- https://git.kernel.org/stable/c/724376c30af5a57686b223dbcd6188e07d2a1de2
- https://git.kernel.org/stable/c/755dbc3d73789ac9f0017c729abf5e4b153bf799
- https://git.kernel.org/stable/c/84b89fa877ad576e9ee8130f412cfd592f274508
- https://git.kernel.org/stable/c/b5d6eba71997b6d661935d2b15094ac7f9f6132d
Modified: 2025-10-01
CVE-2021-47652
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe() I got a null-ptr-deref report: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:fb_destroy_modelist+0x38/0x100 ... Call Trace: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460 ... ret_from_fork+0x1f/0x30 If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will be called to destroy modelist in the error handling path. But modelist has not been initialized yet, so it will result in null-ptr-deref. Initialize modelist before calling fb_alloc_cmap() to fix this bug.
- https://git.kernel.org/stable/c/0fd28daec73525382e5c992db8743bf76e42cd5c
- https://git.kernel.org/stable/c/1791f487f877a9e83d81c8677bd3e7b259e7cb27
- https://git.kernel.org/stable/c/64ec3e678d76419f207b9cdd338dda438ca10b1c
- https://git.kernel.org/stable/c/9280ef235b05e8f19f8bc6d547b992f0a0ef398d
- https://git.kernel.org/stable/c/c420b540db4b5d69de0a36d8b9d9a6a79a04f05a
- https://git.kernel.org/stable/c/d1b6a1f0c23b7164250479bf92e2893291dca539
- https://git.kernel.org/stable/c/d396c651e2b508b6179bb678cc029f3becbf5170
- https://git.kernel.org/stable/c/da8b269cc0a2526ebeaccbe2484c999eb0f822cf
- https://git.kernel.org/stable/c/dd3a6cc7385b89ec2303f39dfc3bafa4e24cec4b
Modified: 2025-03-24
CVE-2021-47653
In the Linux kernel, the following vulnerability has been resolved: media: davinci: vpif: fix use-after-free on driver unbind The driver allocates and registers two platform device structures during probe, but the devices were never deregistered on driver unbind. This results in a use-after-free on driver unbind as the device structures were allocated using devres and would be freed by driver core when remove() returns. Fix this by adding the missing deregistration calls to the remove() callback and failing probe on registration errors. Note that the platform device structures must be freed using a proper release callback to avoid leaking associated resources like device names.
Modified: 2025-10-01
CVE-2021-47654
In the Linux kernel, the following vulnerability has been resolved: samples/landlock: Fix path_list memory leak Clang static analysis reports this error sandboxer.c:134:8: warning: Potential leak of memory pointed to by 'path_list' ret = 0; ^ path_list is allocated in parse_path() but never freed.
Modified: 2025-10-01
CVE-2021-47655
In the Linux kernel, the following vulnerability has been resolved: media: venus: vdec: fixed possible memory leak issue The venus_helper_alloc_dpb_bufs() implementation allows an early return on an error path when checking the id from ida_alloc_min() which would not release the earlier buffer allocation. Move the direct kfree() from the error checking of dma_alloc_attrs() to the common fail path to ensure that allocations are released on all error paths in this function. Addresses-Coverity: 1494120 ("Resource leak")
Modified: 2025-03-24
CVE-2021-47656
In the Linux kernel, the following vulnerability has been resolved: jffs2: fix use-after-free in jffs2_clear_xattr_subsystem When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super(). Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719 Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ================================================================== The triggering of the BUG is shown in the following stack: ----------------------------------------------------------- jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again ----------------------------------------------------------- An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF problem.
- https://git.kernel.org/stable/c/22327bd7988f21de3a53c1373f3b81542bfe1f44
- https://git.kernel.org/stable/c/30bf7244acf32f19cb722c39f7bc1c2a9f300422
- https://git.kernel.org/stable/c/3bd2454162ec6bbb5503233c804fce6e4b6dcec5
- https://git.kernel.org/stable/c/4c7c44ee1650677fbe89d86edbad9497b7679b5c
- https://git.kernel.org/stable/c/7a75740206af5f17e9f3efa384211cba70213da1
- https://git.kernel.org/stable/c/7bb7428dd73991bf4b3a7a61b493ca50046c2b13
- https://git.kernel.org/stable/c/8c0f024f29e055840a5a89fe23b96ae3f921afed
- https://git.kernel.org/stable/c/9150cb625b46f68d524f4cfd491f1aafc23e10a9
- https://git.kernel.org/stable/c/c3b07c875fa8f906f932976460fd14798596f101
Modified: 2025-10-01
CVE-2021-47657
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it happened in the bug report by syzbot), virtio_gpu_array_put_free() could be called with objs equal to NULL. Ensure that objs is not NULL in virtio_gpu_array_put_free(), or otherwise return from the function.
Modified: 2025-09-23
CVE-2021-47658
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix a potential gpu_metrics_table memory leak Memory is allocated for gpu_metrics_table in renoir_init_smc_tables(), but not freed in int smu_v12_0_fini_smc_tables(). Free it!
Modified: 2024-11-21
CVE-2022-0330
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system.
- http://www.openwall.com/lists/oss-security/2022/11/30/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2042404
- https://security.netapp.com/advisory/ntap-20220526-0001/
- https://www.openwall.com/lists/oss-security/2022/01/25/12
- http://www.openwall.com/lists/oss-security/2022/11/30/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2042404
- https://security.netapp.com/advisory/ntap-20220526-0001/
- https://www.openwall.com/lists/oss-security/2022/01/25/12
Modified: 2024-11-21
CVE-2022-0494
A kernel information leak flaw was identified in the scsi_ioctl function in drivers/scsi/scsi_ioctl.c in the Linux kernel. This flaw allows a local attacker with a special user privilege (CAP_SYS_ADMIN or CAP_SYS_RAWIO) to create issues with confidentiality.
- https://bugzilla.redhat.com/show_bug.cgi?id=2039448
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lore.kernel.org/all/20220216084038.15635-1-tcs.kernel%40gmail.com/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://bugzilla.redhat.com/show_bug.cgi?id=2039448
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lore.kernel.org/all/20220216084038.15635-1-tcs.kernel%40gmail.com/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
Modified: 2024-11-21
CVE-2022-0516
A vulnerability was found in kvm_s390_guest_sida_op in the arch/s390/kvm/kvm-s390.c function in KVM for s390 in the Linux kernel. This flaw allows a local attacker with a normal user privilege to obtain unauthorized memory write access. This flaw affects Linux kernel versions prior to 5.17-rc4.
- https://bugzilla.redhat.com/show_bug.cgi?id=2050237
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09a93c1df3eafa43bcdfd7bf837c574911f12f55
- https://security.netapp.com/advisory/ntap-20220331-0009/
- https://www.debian.org/security/2022/dsa-5092
- https://bugzilla.redhat.com/show_bug.cgi?id=2050237
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09a93c1df3eafa43bcdfd7bf837c574911f12f55
- https://security.netapp.com/advisory/ntap-20220331-0009/
- https://www.debian.org/security/2022/dsa-5092
Modified: 2024-11-21
CVE-2022-0617
A flaw null pointer dereference in the Linux kernel UDF file system functionality was found in the way user triggers udf_file_write_iter function for the malicious UDF image. A local user could use this flaw to crash the system. Actual from Linux kernel 4.2-rc1 till 5.17-rc2.
- http://www.openwall.com/lists/oss-security/2022/04/13/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fc3b7c2981bbd1047916ade327beccb90994eee
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea8569194b43f0f01f0a84c689388542c7254a1f
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://lore.kernel.org/lkml/20220114172329.ygzry5rlz64ua2nr%40quack3.lan/T/
- https://www.debian.org/security/2022/dsa-5095
- https://www.debian.org/security/2022/dsa-5096
- http://www.openwall.com/lists/oss-security/2022/04/13/2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fc3b7c2981bbd1047916ade327beccb90994eee
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea8569194b43f0f01f0a84c689388542c7254a1f
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html
- https://lore.kernel.org/lkml/20220114172329.ygzry5rlz64ua2nr%40quack3.lan/T/
- https://www.debian.org/security/2022/dsa-5095
- https://www.debian.org/security/2022/dsa-5096
Modified: 2024-11-21
CVE-2022-1011
A use-after-free flaw was found in the Linux kernel’s FUSE filesystem in the way a user triggers write(). This flaw allows a local user to gain unauthorized access to data from the FUSE filesystem, resulting in privilege escalation.
- https://bugzilla.redhat.com/show_bug.cgi?id=2064855
- https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://www.debian.org/security/2022/dsa-5173
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2064855
- https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://www.debian.org/security/2022/dsa-5173
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2022-1015
A flaw was found in the Linux kernel in linux/net/netfilter/nf_tables_api.c of the netfilter subsystem. This flaw allows a local user to cause an out-of-bounds write issue.
- http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/08/25/2
- http://www.openwall.com/lists/oss-security/2023/01/13/2
- http://www.openwall.com/lists/oss-security/2023/02/23/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2065323
- https://seclists.org/oss-sec/2022/q1/205
- http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/08/25/2
- http://www.openwall.com/lists/oss-security/2023/01/13/2
- http://www.openwall.com/lists/oss-security/2023/02/23/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2065323
- https://seclists.org/oss-sec/2022/q1/205
Modified: 2024-11-21
CVE-2022-1016
A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle 'return' with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker.
- http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/
- https://access.redhat.com/security/cve/CVE-2022-1016
- https://bugzilla.redhat.com/show_bug.cgi?id=2066614
- https://seclists.org/oss-sec/2022/q1/205
- http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/
- https://access.redhat.com/security/cve/CVE-2022-1016
- https://bugzilla.redhat.com/show_bug.cgi?id=2066614
- https://seclists.org/oss-sec/2022/q1/205
Modified: 2024-11-21
CVE-2022-1048
A use-after-free flaw was found in the Linux kernel’s sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2066706
- https://lore.kernel.org/lkml/20220322170720.3529-5-tiwai%40suse.de/T/#m1d3b791b815556012c6be92f1c4a7086b854f7f3
- https://security.netapp.com/advisory/ntap-20220629-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://bugzilla.redhat.com/show_bug.cgi?id=2066706
- https://lore.kernel.org/lkml/20220322170720.3529-5-tiwai%40suse.de/T/#m1d3b791b815556012c6be92f1c4a7086b854f7f3
- https://security.netapp.com/advisory/ntap-20220629-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
Modified: 2024-11-21
CVE-2022-1055
A use-after-free exists in the Linux Kernel in tc_new_tfilter that could allow a local attacker to gain privilege escalation. The exploit requires unprivileged user namespaces. We recommend upgrading past commit 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5
- https://kernel.dance/#04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5
- https://security.netapp.com/advisory/ntap-20220506-0007/
- https://syzkaller.appspot.com/bug?id=2212474c958978ab86525fe6832ac8102c309ffc
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5
- https://kernel.dance/#04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5
- https://security.netapp.com/advisory/ntap-20220506-0007/
- https://syzkaller.appspot.com/bug?id=2212474c958978ab86525fe6832ac8102c309ffc
Modified: 2024-11-21
CVE-2022-1158
A flaw was found in KVM. When updating a guest's page table entry, vm_pgoff was improperly used as the offset to get the page's pfn. As vaddr and vm_pgoff are controllable by user-mode processes, this flaw allows unprivileged local users on the host to write outside the userspace region and potentially corrupt the kernel, resulting in a denial of service condition.
- https://bugzilla.redhat.com/show_bug.cgi?id=2069793
- https://security.netapp.com/advisory/ntap-20230214-0003/
- https://www.openwall.com/lists/oss-security/2022/04/08/4
- https://bugzilla.redhat.com/show_bug.cgi?id=2069793
- https://security.netapp.com/advisory/ntap-20230214-0003/
- https://www.openwall.com/lists/oss-security/2022/04/08/4
Modified: 2024-11-21
CVE-2022-1198
A use-after-free vulnerabilitity was discovered in drivers/net/hamradio/6pack.c of linux that allows an attacker to crash linux kernel by simulating ax25 device using 6pack driver from user space.
- https://access.redhat.com/security/cve/CVE-2022-1198
- https://bugzilla.redhat.com/show_bug.cgi?id=2070689
- https://github.com/torvalds/linux/commit/efe4186e6a1b54bf38b9e05450d43b0da1fd7739
- https://www.openwall.com/lists/oss-security/2022/04/02/3
- https://access.redhat.com/security/cve/CVE-2022-1198
- https://bugzilla.redhat.com/show_bug.cgi?id=2070689
- https://github.com/torvalds/linux/commit/efe4186e6a1b54bf38b9e05450d43b0da1fd7739
- https://www.openwall.com/lists/oss-security/2022/04/02/3
Modified: 2024-11-21
CVE-2022-1204
A use-after-free flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.
- https://access.redhat.com/security/cve/CVE-2022-1204
- https://bugzilla.redhat.com/show_bug.cgi?id=2071051
- https://security-tracker.debian.org/tracker/CVE-2022-1204
- https://www.openwall.com/lists/oss-security/2022/04/02/2
- https://access.redhat.com/security/cve/CVE-2022-1204
- https://bugzilla.redhat.com/show_bug.cgi?id=2071051
- https://security-tracker.debian.org/tracker/CVE-2022-1204
- https://www.openwall.com/lists/oss-security/2022/04/02/2
Modified: 2024-11-21
CVE-2022-1205
A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system.
- https://access.redhat.com/security/cve/CVE-2022-1205
- https://bugzilla.redhat.com/show_bug.cgi?id=2071047
- https://github.com/torvalds/linux/commit/82e31755e55fbcea6a9dfaae5fe4860ade17cbc0
- https://github.com/torvalds/linux/commit/fc6d01ff9ef03b66d4a3a23b46fc3c3d8cf92009
- https://www.openwall.com/lists/oss-security/2022/04/02/4
- https://access.redhat.com/security/cve/CVE-2022-1205
- https://bugzilla.redhat.com/show_bug.cgi?id=2071047
- https://github.com/torvalds/linux/commit/82e31755e55fbcea6a9dfaae5fe4860ade17cbc0
- https://github.com/torvalds/linux/commit/fc6d01ff9ef03b66d4a3a23b46fc3c3d8cf92009
- https://www.openwall.com/lists/oss-security/2022/04/02/4
Modified: 2024-11-21
CVE-2022-1353
A vulnerability was found in the pfkey_register function in net/key/af_key.c in the Linux kernel. This flaw allows a local, unprivileged user to gain access to kernel memory, leading to a system crash or a leak of internal kernel information.
- https://bugzilla.redhat.com/show_bug.cgi?id=2066819
- https://github.com/torvalds/linux/commit/9a564bccb78a76740ea9d75a259942df8143d02c
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220629-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://bugzilla.redhat.com/show_bug.cgi?id=2066819
- https://github.com/torvalds/linux/commit/9a564bccb78a76740ea9d75a259942df8143d02c
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220629-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
Modified: 2024-11-21
CVE-2022-1651
A memory leak flaw was found in the Linux kernel in acrn_dev_ioctl in the drivers/virt/acrn/hsm.c function in how the ACRN Device Model emulates virtual NICs in VM. This flaw allows a local privileged attacker to leak unauthorized kernel information, causing a denial of service.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecd1735f14d6ac868ae5d8b7a2bf193fa11f388b
- https://security.netapp.com/advisory/ntap-20220901-0008/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecd1735f14d6ac868ae5d8b7a2bf193fa11f388b
- https://security.netapp.com/advisory/ntap-20220901-0008/
Modified: 2024-11-21
CVE-2022-1671
A NULL pointer dereference flaw was found in rxrpc_preparse_s in net/rxrpc/server_key.c in the Linux kernel. This flaw allows a local attacker to crash the system or leak internal kernel information.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff8376ade4f668130385839cef586a0990f8ef87
- https://security.netapp.com/advisory/ntap-20220901-0004/
- https://security.netapp.com/advisory/ntap-20220901-0008/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff8376ade4f668130385839cef586a0990f8ef87
- https://security.netapp.com/advisory/ntap-20220901-0004/
- https://security.netapp.com/advisory/ntap-20220901-0008/
Modified: 2024-11-21
CVE-2022-27666
A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat.
- https://bugzilla.redhat.com/show_bug.cgi?id=2061633
- https://github.com/torvalds/linux/commit/ebe48d368e97d007bfeb76fcb065d6cfc4c96645
- https://security.netapp.com/advisory/ntap-20220429-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://bugzilla.redhat.com/show_bug.cgi?id=2061633
- https://github.com/torvalds/linux/commit/ebe48d368e97d007bfeb76fcb065d6cfc4c96645
- https://security.netapp.com/advisory/ntap-20220429-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
Modified: 2025-05-05
CVE-2022-28356
In the Linux kernel before 5.17.1, a refcount leak bug was found in net/llc/af_llc.c.
- http://www.openwall.com/lists/oss-security/2022/04/06/1
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.1
- https://github.com/torvalds/linux/commit/764f4eb6846f5475f1244767d24d25dd86528a4a
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220506-0006/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- http://www.openwall.com/lists/oss-security/2022/04/06/1
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.1
- https://github.com/torvalds/linux/commit/764f4eb6846f5475f1244767d24d25dd86528a4a
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220506-0006/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
Modified: 2025-05-05
CVE-2022-28388
usb_8dev_start_xmit in drivers/net/can/usb/usb_8dev.c in the Linux kernel through 5.17.1 has a double free.
- https://github.com/torvalds/linux/commit/3d3925ff6433f98992685a9679613a2cc97f3ce2
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/
- https://security.netapp.com/advisory/ntap-20220513-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://github.com/torvalds/linux/commit/3d3925ff6433f98992685a9679613a2cc97f3ce2
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/
- https://security.netapp.com/advisory/ntap-20220513-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
Modified: 2024-11-21
CVE-2022-28389
mcba_usb_start_xmit in drivers/net/can/usb/mcba_usb.c in the Linux kernel through 5.17.1 has a double free.
- https://github.com/torvalds/linux/commit/04c9b00ba83594a29813d6b1fb8fdc93a3915174
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/
- https://security.netapp.com/advisory/ntap-20220513-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://github.com/torvalds/linux/commit/04c9b00ba83594a29813d6b1fb8fdc93a3915174
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/
- https://security.netapp.com/advisory/ntap-20220513-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
Modified: 2025-06-25
CVE-2022-28390
ems_usb_start_xmit in drivers/net/can/usb/ems_usb.c in the Linux kernel through 5.17.1 has a double free.
- https://github.com/torvalds/linux/commit/c70222752228a62135cee3409dccefd494a24646
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/
- https://security.netapp.com/advisory/ntap-20220513-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://github.com/torvalds/linux/commit/c70222752228a62135cee3409dccefd494a24646
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/
- https://security.netapp.com/advisory/ntap-20220513-0001/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
Modified: 2024-11-21
CVE-2022-28893
The SUNRPC subsystem in the Linux kernel through 5.17.2 can call xs_xprt_free before ensuring that sockets are in the intended state.
- http://www.openwall.com/lists/oss-security/2022/04/11/3
- http://www.openwall.com/lists/oss-security/2022/04/11/4
- http://www.openwall.com/lists/oss-security/2022/04/11/5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a3b1bba7c7a5eb8a11513cf88427cb9d77bc60a
- https://security.netapp.com/advisory/ntap-20220526-0002/
- https://www.debian.org/security/2022/dsa-5161
- http://www.openwall.com/lists/oss-security/2022/04/11/3
- http://www.openwall.com/lists/oss-security/2022/04/11/4
- http://www.openwall.com/lists/oss-security/2022/04/11/5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a3b1bba7c7a5eb8a11513cf88427cb9d77bc60a
- https://security.netapp.com/advisory/ntap-20220526-0002/
- https://www.debian.org/security/2022/dsa-5161
Modified: 2024-11-21
CVE-2022-29582
In the Linux kernel before 5.17.3, fs/io_uring.c has a use-after-free due to a race condition in io_uring timeouts. This can be triggered by a local user who has no access to any user namespace; however, the race condition perhaps can only be exploited infrequently.
- http://www.openwall.com/lists/oss-security/2022/04/22/4
- http://www.openwall.com/lists/oss-security/2022/08/08/3
- http://www.openwall.com/lists/oss-security/2024/04/24/3
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.3
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e677edbcabee849bfdd43f1602bccbecf736a646
- https://github.com/Ruia-ruia/CVE-2022-29582-Exploit
- https://github.com/torvalds/linux/commit/e677edbcabee849bfdd43f1602bccbecf736a646
- https://ruia-ruia.github.io/2022/08/05/CVE-2022-29582-io-uring/
- https://www.debian.org/security/2022/dsa-5127
- https://www.openwall.com/lists/oss-security/2022/04/22/3
- http://www.openwall.com/lists/oss-security/2022/04/22/4
- http://www.openwall.com/lists/oss-security/2022/08/08/3
- http://www.openwall.com/lists/oss-security/2024/04/24/3
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.3
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e677edbcabee849bfdd43f1602bccbecf736a646
- https://github.com/Ruia-ruia/CVE-2022-29582-Exploit
- https://github.com/torvalds/linux/commit/e677edbcabee849bfdd43f1602bccbecf736a646
- https://ruia-ruia.github.io/2022/08/05/CVE-2022-29582-io-uring/
- https://www.debian.org/security/2022/dsa-5127
- https://www.openwall.com/lists/oss-security/2022/04/22/3
Modified: 2024-11-21
CVE-2022-2977
A flaw was found in the Linux kernel implementation of proxied virtualized TPM devices. On a system where virtualized TPM devices are configured (this is not the default) a local attacker can create a use-after-free and create a situation where it may be possible to escalate privileges on the system.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d8e7007dc7c4d7c8366739bbcd3f5e51dcd470f
- https://security.netapp.com/advisory/ntap-20230214-0006/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d8e7007dc7c4d7c8366739bbcd3f5e51dcd470f
- https://security.netapp.com/advisory/ntap-20230214-0006/
Modified: 2024-11-21
CVE-2022-30594
The Linux kernel before 5.17.2 mishandles seccomp permissions. The PTRACE_SEIZE code path allows attackers to bypass intended restrictions on setting the PT_SUSPEND_SECCOMP flag.
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- http://packetstormsecurity.com/files/170362/Linux-PT_SUSPEND_SECCOMP-Permission-Bypass-Ptracer-Death-Race.html
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2276
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3
- https://github.com/torvalds/linux/commit/ee1fee900537b5d9560e9f937402de5ddc8412f3
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220707-0001/
- https://www.debian.org/security/2022/dsa-5173
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- http://packetstormsecurity.com/files/170362/Linux-PT_SUSPEND_SECCOMP-Permission-Bypass-Ptracer-Death-Race.html
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2276
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3
- https://github.com/torvalds/linux/commit/ee1fee900537b5d9560e9f937402de5ddc8412f3
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://security.netapp.com/advisory/ntap-20220707-0001/
- https://www.debian.org/security/2022/dsa-5173
Modified: 2024-11-21
CVE-2022-3176
There exists a use-after-free in io_uring in the Linux kernel. Signalfd_poll() and binder_poll() use a waitqueue whose lifetime is the current task. It will send a POLLFREE notification to all waiters before the queue is freed. Unfortunately, the io_uring poll doesn't handle POLLFREE. This allows a use-after-free to occur if a signalfd or binder fd is polled with io_uring poll, and the waitqueue gets freed. We recommend upgrading past commit fc78b2fc21f10c4c9c4d5d659a685710ffa63659
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-5.4.y&id=fc78b2fc21f10c4c9c4d5d659a685710ffa63659
- https://kernel.dance/#fc78b2fc21f10c4c9c4d5d659a685710ffa63659
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://security.netapp.com/advisory/ntap-20230216-0003/
- https://www.debian.org/security/2022/dsa-5257
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-5.4.y&id=fc78b2fc21f10c4c9c4d5d659a685710ffa63659
- https://kernel.dance/#fc78b2fc21f10c4c9c4d5d659a685710ffa63659
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://security.netapp.com/advisory/ntap-20230216-0003/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2024-11-21
CVE-2022-3202
A NULL pointer dereference flaw in diFree in fs/jfs/inode.c in Journaled File System (JFS)in the Linux kernel. This could allow a local attacker to crash the system or leak kernel internal information.
Modified: 2024-11-21
CVE-2022-3239
A flaw use after free in the Linux kernel video4linux driver was found in the way user triggers em28xx_usb_probe() for the Empia 28xx based TV cards. A local user could use this flaw 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=c08eadca1bdfa099e20a32f8fa4b52b2f672236d
- https://security.netapp.com/advisory/ntap-20230214-0006/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c08eadca1bdfa099e20a32f8fa4b52b2f672236d
- https://security.netapp.com/advisory/ntap-20230214-0006/
Modified: 2024-11-21
CVE-2022-3526
A vulnerability classified as problematic was found in Linux Kernel. This vulnerability affects the function macvlan_handle_frame of the file drivers/net/macvlan.c of the component skb. The manipulation leads to memory leak. The attack can be initiated remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211024.
Modified: 2025-04-07
CVE-2022-41858
A flaw was found in the Linux kernel. A NULL pointer dereference may occur while a slip driver is in progress to detach in sl_tx_timeout in drivers/net/slip/slip.c. This issue could allow an attacker to crash the system or leak internal kernel information.
Modified: 2025-02-26
CVE-2022-48629
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - ensure buffer for generate is completely filled The generate function in struct rng_alg expects that the destination buffer is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following from libkcapi: kcapi-rng -b 9000000 > OUTFILE The generated OUTFILE will have three huge sections that contain all zeros, and this is caused by the code where the test 'val & PRNG_STATUS_DATA_AVAIL' fails. Let's fix this issue by ensuring that qcom_rng_read() always returns with a full buffer if the function returns success. Let's also have qcom_rng_generate() return the correct value. Here's some statistics from the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the generated numbers: $ ent -c qcom-random-before Value Char Occurrences Fraction 0 606748 0.067416 1 33104 0.003678 2 33001 0.003667 ... 253 � 32883 0.003654 254 � 33035 0.003671 255 � 33239 0.003693 Total: 9000000 1.000000 Entropy = 7.811590 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 2 percent. Chi square distribution for 9000000 samples is 9329962.81, and randomly would exceed this value less than 0.01 percent of the times. Arithmetic mean value of data bytes is 119.3731 (127.5 = random). Monte Carlo value for Pi is 3.197293333 (error 1.77 percent). Serial correlation coefficient is 0.159130 (totally uncorrelated = 0.0). Without this patch, the results of the chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The results improve with this patch: $ ent -c qcom-random-after Value Char Occurrences Fraction 0 35432 0.003937 1 35127 0.003903 2 35424 0.003936 ... 253 � 35201 0.003911 254 � 34835 0.003871 255 � 35368 0.003930 Total: 9000000 1.000000 Entropy = 7.999979 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 0 percent. Chi square distribution for 9000000 samples is 258.77, and randomly would exceed this value 42.24 percent of the times. Arithmetic mean value of data bytes is 127.5006 (127.5 = random). Monte Carlo value for Pi is 3.141277333 (error 0.01 percent). Serial correlation coefficient is 0.000468 (totally uncorrelated = 0.0). This change was tested on a Nexus 5 phone (msm8974 SoC).
- https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b
- https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d
- https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d
- https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b
- https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d
- https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd
- https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b
- https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d
- https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d
- https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b
- https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d
- https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd
Modified: 2025-10-07
CVE-2022-48833
In the Linux kernel, the following vulnerability has been resolved:
btrfs: skip reserved bytes warning on unmount after log cleanup failure
After the recent changes made by commit c2e39305299f01 ("btrfs: clear
extent buffer uptodate when we fail to write it") and its followup fix,
commit 651740a5024117 ("btrfs: check WRITE_ERR when trying to read an
extent buffer"), we can now end up not cleaning up space reservations of
log tree extent buffers after a transaction abort happens, as well as not
cleaning up still dirty extent buffers.
This happens because if writeback for a log tree extent buffer failed,
then we have cleared the bit EXTENT_BUFFER_UPTODATE from the extent buffer
and we have also set the bit EXTENT_BUFFER_WRITE_ERR on it. Later on,
when trying to free the log tree with free_log_tree(), which iterates
over the tree, we can end up getting an -EIO error when trying to read
a node or a leaf, since read_extent_buffer_pages() returns -EIO if an
extent buffer does not have EXTENT_BUFFER_UPTODATE set and has the
EXTENT_BUFFER_WRITE_ERR bit set. Getting that -EIO means that we return
immediately as we can not iterate over the entire tree.
In that case we never update the reserved space for an extent buffer in
the respective block group and space_info object.
When this happens we get the following traces when unmounting the fs:
[174957.284509] BTRFS: error (device dm-0) in cleanup_transaction:1913: errno=-5 IO failure
[174957.286497] BTRFS: error (device dm-0) in free_log_tree:3420: errno=-5 IO failure
[174957.399379] ------------[ cut here ]------------
[174957.402497] WARNING: CPU: 2 PID: 3206883 at fs/btrfs/block-group.c:127 btrfs_put_block_group+0x77/0xb0 [btrfs]
[174957.407523] Modules linked in: btrfs overlay dm_zero (...)
[174957.424917] CPU: 2 PID: 3206883 Comm: umount Tainted: G W 5.16.0-rc5-btrfs-next-109 #1
[174957.426689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[174957.428716] RIP: 0010:btrfs_put_block_group+0x77/0xb0 [btrfs]
[174957.429717] Code: 21 48 8b bd (...)
[174957.432867] RSP: 0018:ffffb70d41cffdd0 EFLAGS: 00010206
[174957.433632] RAX: 0000000000000001 RBX: ffff8b09c3848000 RCX: ffff8b0758edd1c8
[174957.434689] RDX: 0000000000000001 RSI: ffffffffc0b467e7 RDI: ffff8b0758edd000
[174957.436068] RBP: ffff8b0758edd000 R08: 0000000000000000 R09: 0000000000000000
[174957.437114] R10: 0000000000000246 R11: 0000000000000000 R12: ffff8b09c3848148
[174957.438140] R13: ffff8b09c3848198 R14: ffff8b0758edd188 R15: dead000000000100
[174957.439317] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS:0000000000000000
[174957.440402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[174957.441164] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000370ee0
[174957.442117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[174957.443076] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[174957.443948] Call Trace:
[174957.444264]
- https://git.kernel.org/stable/c/40cdc509877bacb438213b83c7541c5e24a1d9ec
- https://git.kernel.org/stable/c/44557a8f539a822c91238c1f95a95f98a5093d82
- https://git.kernel.org/stable/c/4c5d94990fa2fd609360ecd0f7e183212a7d115c
- https://git.kernel.org/stable/c/40cdc509877bacb438213b83c7541c5e24a1d9ec
- https://git.kernel.org/stable/c/44557a8f539a822c91238c1f95a95f98a5093d82
- https://git.kernel.org/stable/c/4c5d94990fa2fd609360ecd0f7e183212a7d115c
Modified: 2025-01-22
CVE-2022-48834
In the Linux kernel, the following vulnerability has been resolved:
usb: usbtmc: Fix bug in pipe direction for control transfers
The syzbot fuzzer reported a minor bug in the usbtmc driver:
usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0
WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412
usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410
Modules linked in:
CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted
5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0
...
Call Trace:
- https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e
- https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952
- https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016
- https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7
- https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b
- https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e
- https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952
- https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016
- https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7
- https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b
Modified: 2024-11-21
CVE-2022-48835
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Page fault in reply q processing A page fault was encountered in mpt3sas on a LUN reset error path: [ 145.763216] mpt3sas_cm1: Task abort tm failed: handle(0x0002),timeout(30) tr_method(0x0) smid(3) msix_index(0) [ 145.778932] scsi 1:0:0:0: task abort: FAILED scmd(0x0000000024ba29a2) [ 145.817307] scsi 1:0:0:0: attempting device reset! scmd(0x0000000024ba29a2) [ 145.827253] scsi 1:0:0:0: [sg1] tag#2 CDB: Receive Diagnostic 1c 01 01 ff fc 00 [ 145.837617] scsi target1:0:0: handle(0x0002), sas_address(0x500605b0000272b9), phy(0) [ 145.848598] scsi target1:0:0: enclosure logical id(0x500605b0000272b8), slot(0) [ 149.858378] mpt3sas_cm1: Poll ReplyDescriptor queues for completion of smid(0), task_type(0x05), handle(0x0002) [ 149.875202] BUG: unable to handle page fault for address: 00000007fffc445d [ 149.885617] #PF: supervisor read access in kernel mode [ 149.894346] #PF: error_code(0x0000) - not-present page [ 149.903123] PGD 0 P4D 0 [ 149.909387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 149.917417] CPU: 24 PID: 3512 Comm: scsi_eh_1 Kdump: loaded Tainted: G S O 5.10.89-altav-1 #1 [ 149.934327] Hardware name: DDN 200NVX2 /200NVX2-MB , BIOS ATHG2.2.02.01 09/10/2021 [ 149.951871] RIP: 0010:_base_process_reply_queue+0x4b/0x900 [mpt3sas] [ 149.961889] Code: 0f 84 22 02 00 00 8d 48 01 49 89 fd 48 8d 57 38 f0 0f b1 4f 38 0f 85 d8 01 00 00 49 8b 45 10 45 31 e4 41 8b 55 0c 48 8d 1c d0 <0f> b6 03 83 e0 0f 3c 0f 0f 85 a2 00 00 00 e9 e6 01 00 00 0f b7 ee [ 149.991952] RSP: 0018:ffffc9000f1ebcb8 EFLAGS: 00010246 [ 150.000937] RAX: 0000000000000055 RBX: 00000007fffc445d RCX: 000000002548f071 [ 150.011841] RDX: 00000000ffff8881 RSI: 0000000000000001 RDI: ffff888125ed50d8 [ 150.022670] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000ffff7fff [ 150.033445] R10: ffffc9000f1ebb68 R11: ffffc9000f1ebb60 R12: 0000000000000000 [ 150.044204] R13: ffff888125ed50d8 R14: 0000000000000080 R15: 34cdc00034cdea80 [ 150.054963] FS: 0000000000000000(0000) GS:ffff88dfaf200000(0000) knlGS:0000000000000000 [ 150.066715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.076078] CR2: 00000007fffc445d CR3: 000000012448a006 CR4: 0000000000770ee0 [ 150.086887] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 150.097670] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 150.108323] PKRU: 55555554 [ 150.114690] Call Trace: [ 150.120497] ? printk+0x48/0x4a [ 150.127049] mpt3sas_scsih_issue_tm.cold.114+0x2e/0x2b3 [mpt3sas] [ 150.136453] mpt3sas_scsih_issue_locked_tm+0x86/0xb0 [mpt3sas] [ 150.145759] scsih_dev_reset+0xea/0x300 [mpt3sas] [ 150.153891] scsi_eh_ready_devs+0x541/0x9e0 [scsi_mod] [ 150.162206] ? __scsi_host_match+0x20/0x20 [scsi_mod] [ 150.170406] ? scsi_try_target_reset+0x90/0x90 [scsi_mod] [ 150.178925] ? blk_mq_tagset_busy_iter+0x45/0x60 [ 150.186638] ? scsi_try_target_reset+0x90/0x90 [scsi_mod] [ 150.195087] scsi_error_handler+0x3a5/0x4a0 [scsi_mod] [ 150.203206] ? __schedule+0x1e9/0x610 [ 150.209783] ? scsi_eh_get_sense+0x210/0x210 [scsi_mod] [ 150.217924] kthread+0x12e/0x150 [ 150.224041] ? kthread_worker_fn+0x130/0x130 [ 150.231206] ret_from_fork+0x1f/0x30 This is caused by mpt3sas_base_sync_reply_irqs() using an invalid reply_q pointer outside of the list_for_each_entry() loop. At the end of the full list traversal the pointer is invalid. Move the _base_process_reply_queue() call inside of the loop.
- https://git.kernel.org/stable/c/0cd2dd4bcf4abc812148c4943f966a3c8dccb00f
- https://git.kernel.org/stable/c/3916e33b917581e2b2086e856c291cb86ea98a05
- https://git.kernel.org/stable/c/69ad4ef868c1fc7609daa235dfa46d28ba7a3ba3
- https://git.kernel.org/stable/c/98e7a654a5bebaf1a28e987af5e44c002544a413
- https://git.kernel.org/stable/c/0cd2dd4bcf4abc812148c4943f966a3c8dccb00f
- https://git.kernel.org/stable/c/3916e33b917581e2b2086e856c291cb86ea98a05
- https://git.kernel.org/stable/c/69ad4ef868c1fc7609daa235dfa46d28ba7a3ba3
- https://git.kernel.org/stable/c/98e7a654a5bebaf1a28e987af5e44c002544a413
Modified: 2024-11-21
CVE-2022-48836
In the Linux kernel, the following vulnerability has been resolved:
Input: aiptek - properly check endpoint type
Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. There was a check for the number of endpoints, but not
for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with
usb_find_common_endpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Workqueue: usb_hub_wq hub_event
...
Call Trace:
- https://git.kernel.org/stable/c/35069e654bcab567ff8b9f0e68e1caf82c15dcd7
- https://git.kernel.org/stable/c/5600f6986628dde8881734090588474f54a540a8
- https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821
- https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f
- https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c
- https://git.kernel.org/stable/c/e762f57ff255af28236cd02ca9fc5c7e5a089d31
- https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2b33204a
- https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6
- https://git.kernel.org/stable/c/35069e654bcab567ff8b9f0e68e1caf82c15dcd7
- https://git.kernel.org/stable/c/5600f6986628dde8881734090588474f54a540a8
- https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821
- https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f
- https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c
- https://git.kernel.org/stable/c/e762f57ff255af28236cd02ca9fc5c7e5a089d31
- https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2b33204a
- https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6
Modified: 2024-11-21
CVE-2022-48837
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: prevent integer overflow in rndis_set_response() If "BufOffset" is very large the "BufOffset + 8" operation can have an integer overflow.
- https://git.kernel.org/stable/c/138d4f739b35dfb40438a0d5d7054965763bfbe7
- https://git.kernel.org/stable/c/21829376268397f9fd2c35cfa9135937b6aa3a1e
- https://git.kernel.org/stable/c/28bc0267399f42f987916a7174e2e32f0833cc65
- https://git.kernel.org/stable/c/56b38e3ca4064041d93c1ca18828c8cedad2e16c
- https://git.kernel.org/stable/c/65f3324f4b6fed78b8761c3b74615ecf0ffa81fa
- https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7da8006b
- https://git.kernel.org/stable/c/c7953cf03a26876d676145ce5d2ae6d8c9630b90
- https://git.kernel.org/stable/c/df7e088d51cdf78b1a0bf1f3d405c2593295c7b0
- https://git.kernel.org/stable/c/138d4f739b35dfb40438a0d5d7054965763bfbe7
- https://git.kernel.org/stable/c/21829376268397f9fd2c35cfa9135937b6aa3a1e
- https://git.kernel.org/stable/c/28bc0267399f42f987916a7174e2e32f0833cc65
- https://git.kernel.org/stable/c/56b38e3ca4064041d93c1ca18828c8cedad2e16c
- https://git.kernel.org/stable/c/65f3324f4b6fed78b8761c3b74615ecf0ffa81fa
- https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7da8006b
- https://git.kernel.org/stable/c/c7953cf03a26876d676145ce5d2ae6d8c9630b90
- https://git.kernel.org/stable/c/df7e088d51cdf78b1a0bf1f3d405c2593295c7b0
Modified: 2024-11-21
CVE-2022-48838
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
The syzbot fuzzer found a use-after-free bug:
BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320
Read of size 8 at addr ffff88802b934098 by task udevd/3689
CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646
- https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740
- https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a
- https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5
- https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e
- https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b
- https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e
- https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3
- https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646
- https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740
- https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a
- https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5
- https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e
- https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b
- https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e
- https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3
Modified: 2024-11-21
CVE-2022-48839
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix slab-out-of-bounds access in packet_recvmsg()
syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH
and mmap operations, tpacket_rcv() is queueing skbs with
garbage in skb->cb[], triggering a too big copy [1]
Presumably, users of af_packet using mmap() already gets correct
metadata from the mapped buffer, we can simply make sure
to clear 12 bytes that might be copied to user space later.
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]
BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489
Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631
CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
- https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d
- https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02
- https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a
- https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da
- https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33
- https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0
- https://git.kernel.org/stable/c/c700525fcc06b05adfea78039de02628af79e07a
- https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371e18f4b2
- https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d
- https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02
- https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a
- https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da
- https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33
- https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0
- https://git.kernel.org/stable/c/c700525fcc06b05adfea78039de02628af79e07a
- https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371e18f4b2
Modified: 2024-11-21
CVE-2022-48840
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix hang during reboot/shutdown Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets its state to __IAVF_REMOVE. Later shutdown callback of associated PF driver (e.g. ice_shutdown) is called. That callback calls among other things sriov_disable() that calls indirectly iavf_remove() (see stack trace below). As the adapter state is already __IAVF_REMOVE then the mentioned loop is end-less and shutdown process hangs. The patch fixes this by checking adapter's state at the beginning of iavf_remove() and skips the rest of the function if the adapter is already in remove state (shutdown is in progress). Reproducer: 1. Create VF on PF driven by ice or i40e driver 2. Ensure that the VF is bound to iavf driver 3. Reboot [52625.981294] sysrq: SysRq : Show Blocked State [52625.988377] task:reboot state:D stack: 0 pid:17359 ppid: 1 f2 [52625.996732] Call Trace: [52625.999187] __schedule+0x2d1/0x830 [52626.007400] schedule+0x35/0xa0 [52626.010545] schedule_hrtimeout_range_clock+0x83/0x100 [52626.020046] usleep_range+0x5b/0x80 [52626.023540] iavf_remove+0x63/0x5b0 [iavf] [52626.027645] pci_device_remove+0x3b/0xc0 [52626.031572] device_release_driver_internal+0x103/0x1f0 [52626.036805] pci_stop_bus_device+0x72/0xa0 [52626.040904] pci_stop_and_remove_bus_device+0xe/0x20 [52626.045870] pci_iov_remove_virtfn+0xba/0x120 [52626.050232] sriov_disable+0x2f/0xe0 [52626.053813] ice_free_vfs+0x7c/0x340 [ice] [52626.057946] ice_remove+0x220/0x240 [ice] [52626.061967] ice_shutdown+0x16/0x50 [ice] [52626.065987] pci_device_shutdown+0x34/0x60 [52626.070086] device_shutdown+0x165/0x1c5 [52626.074011] kernel_restart+0xe/0x30 [52626.077593] __do_sys_reboot+0x1d2/0x210 [52626.093815] do_syscall_64+0x5b/0x1a0 [52626.097483] entry_SYSCALL_64_after_hwframe+0x65/0xca
- https://git.kernel.org/stable/c/4477b9a4193b35eb3a8afd2adf2d42add2f88d57
- https://git.kernel.org/stable/c/80974bb730270199c6fcb189af04d5945b87e813
- https://git.kernel.org/stable/c/b04683ff8f0823b869c219c78ba0d974bddea0b5
- https://git.kernel.org/stable/c/4477b9a4193b35eb3a8afd2adf2d42add2f88d57
- https://git.kernel.org/stable/c/80974bb730270199c6fcb189af04d5945b87e813
- https://git.kernel.org/stable/c/b04683ff8f0823b869c219c78ba0d974bddea0b5
Modified: 2024-11-21
CVE-2022-48841
In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats() It is possible to do NULL pointer dereference in routine that updates Tx ring stats. Currently only stats and bytes are updated when ring pointer is valid, but later on ring is accessed to propagate gathered Tx stats onto VSI stats. Change the existing logic to move to next ring when ring is NULL.
Modified: 2024-11-21
CVE-2022-48846
In the Linux kernel, the following vulnerability has been resolved: block: release rq qos structures for queue without disk blkcg_init_queue() may add rq qos structures to request queue, previously blk_cleanup_queue() calls rq_qos_exit() to release them, but commit 8e141f9eb803 ("block: drain file system I/O on del_gendisk") moves rq_qos_exit() into del_gendisk(), so memory leak is caused because queues may not have disk, such as un-present scsi luns, nvme admin queue, ... Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back. BTW, v5.18 won't need this patch any more since we move blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release handler, and patches have been in for-5.18/block.
- https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29
- https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e
- https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b
- https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29
- https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e
- https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b
Modified: 2025-09-23
CVE-2022-49044
In the Linux kernel, the following vulnerability has been resolved: dm integrity: fix memory corruption when tag_size is less than digest size It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored. In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final. Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array.
- https://git.kernel.org/stable/c/08c1af8f1c13bbf210f1760132f4df24d0ed46d6
- https://git.kernel.org/stable/c/4d485cf9b609709e45d5113e6e2b1b01254b2fe9
- https://git.kernel.org/stable/c/6a95d91c0b315c965198f6ab7dec7c94129e17e0
- https://git.kernel.org/stable/c/6b4bf97587ef6c1927a78934b700204920655123
- https://git.kernel.org/stable/c/7f84c937222944c03f4615ca4742df6bed0e5adf
- https://git.kernel.org/stable/c/cd02b2687d66f0a8e716384de4b9a0671331f1dc
Modified: 2025-11-03
CVE-2022-49046
In the Linux kernel, the following vulnerability has been resolved: i2c: dev: check return value when calling dev_set_name() If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref.
- https://git.kernel.org/stable/c/2e539b17d4cbe5fb8b5152dd9a6e4a8828f97db2
- https://git.kernel.org/stable/c/2f345bb14ad4744950499ff222e2899209297afa
- https://git.kernel.org/stable/c/993eb48fa199b5f476df8204e652eff63dd19361
- https://git.kernel.org/stable/c/c74d77a2d07744147d734138acd6ce9dba715e5d
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-03-24
CVE-2022-49047
In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix UAF in ep93xx_clk_register_gate() arch/arm/mach-ep93xx/clock.c:154:2: warning: Use of memory after it is freed [clang-analyzer-unix.Malloc] arch/arm/mach-ep93xx/clock.c:151:2: note: Taking true branch if (IS_ERR(clk)) ^ arch/arm/mach-ep93xx/clock.c:152:3: note: Memory is released kfree(psc); ^~~~~~~~~~ arch/arm/mach-ep93xx/clock.c:154:2: note: Use of memory after it is freed return &psc->hw; ^ ~~~~~~~~
Modified: 2025-10-14
CVE-2022-49048
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix panic when forwarding a pkt with no in6 dev kongweibin reported a kernel panic in ip6_forward() when input interface has no in6 dev associated. The following tc commands were used to reproduce this panic: tc qdisc del dev vxlan100 root tc qdisc add dev vxlan100 root netem corrupt 5%
- https://git.kernel.org/stable/c/74b68f5249f16c5f7f675d0f604fa6ae20e3a151
- https://git.kernel.org/stable/c/a263712ba8c9ded25dd9d2d5ced11bcea5b33a3e
- https://git.kernel.org/stable/c/ab2f5afb7af5c68389e8c7dd29e0a98fbeaaa435
- https://git.kernel.org/stable/c/adee01bbf6cb5b3e4ed08be8ff866aac90f13836
- https://git.kernel.org/stable/c/e3fa461d8b0e185b7da8a101fe94dfe6dd500ac0
- https://git.kernel.org/stable/c/e69fb3de87a8923e5931a272a38fa3cceb01da44
Modified: 2025-10-14
CVE-2022-49049
In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix panic when growing a memfd_secret
When one tries to grow an existing memfd_secret with ftruncate, one gets
a panic [1]. For example, doing the following reliably induces the
panic:
fd = memfd_secret();
ftruncate(fd, 10);
ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
strcpy(ptr, "123456789");
munmap(ptr, 10);
ftruncate(fd, 20);
The basic reason for this is, when we grow with ftruncate, we call down
into simple_setattr, and then truncate_inode_pages_range, and eventually
we try to zero part of the memory. The normal truncation code does this
via the direct map (i.e., it calls page_address() and hands that to
memset()).
For memfd_secret though, we specifically don't map our pages via the
direct map (i.e. we call set_direct_map_invalid_noflush() on every
fault). So the address returned by page_address() isn't useful, and
when we try to memset() with it we panic.
This patch avoids the panic by implementing a custom setattr for
memfd_secret, which detects resizes specifically (setting the size for
the first time works just fine, since there are no existing pages to try
to zero), and rejects them with EINVAL.
One could argue growing should be supported, but I think that will
require a significantly more lengthy change. So, I propose a minimal
fix for the benefit of stable kernels, and then perhaps to extend
memfd_secret to support growing in a separate patch.
[1]:
BUG: unable to handle page fault for address: ffffa0a889277028
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060
Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:memset_erms+0x9/0x10
Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1
Modified: 2025-09-23
CVE-2022-49050
In the Linux kernel, the following vulnerability has been resolved: memory: renesas-rpc-if: fix platform-device leak in error path Make sure to free the flash platform device in the event that registration fails during probe.
Modified: 2025-09-23
CVE-2022-49051
In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Fix out-of-bounds accesses in RX fixup aqc111_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. Found doing variant analysis. Tested it with another driver (ax88179_178a), since I don't have a aqc111 device to test it, but the code looks very similar.
- https://git.kernel.org/stable/c/36311fe98f55dea9200c69e2dd6d6ddb8fc94080
- https://git.kernel.org/stable/c/404998a137bcb8a926f7c949030afbe285472593
- https://git.kernel.org/stable/c/afb8e246527536848b9b4025b40e613edf776a9d
- https://git.kernel.org/stable/c/b416898442f2b6aa9f1b2f2968ce07e3abaa05f7
- https://git.kernel.org/stable/c/d90df6da50c56ad8b1a132e3cf86b6cdf8f507b7
Modified: 2025-10-14
CVE-2022-49052
In the Linux kernel, the following vulnerability has been resolved: mm: fix unexpected zeroed page mapping with zram swap Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed data The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU B The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly.
- https://git.kernel.org/stable/c/12ba1d38115a101c45d8e0ca3aa1181fd148e57f
- https://git.kernel.org/stable/c/20ed94f8181a25212e7404e44958e234f407624b
- https://git.kernel.org/stable/c/afac4b88699a06c8b9369f9d759a1ec3c254b788
- https://git.kernel.org/stable/c/e914d8f00391520ecc4495dd0ca0124538ab7119
- https://git.kernel.org/stable/c/f098f8b9820fe3f2e41aefc4329dfe8a3859d1c1
- https://git.kernel.org/stable/c/f86d55cf616199404c05f5b0c5c41b17351baa02
Modified: 2025-03-24
CVE-2022-49053
In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcmu: Fix possible page UAF tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not take refcount properly and just returns page pointer. When tcmu_try_get_data_page() returns, the returned page may have been freed by tcmu_blocks_release(). We need to get_page() under cmdr_lock to avoid concurrent tcmu_blocks_release().
- https://git.kernel.org/stable/c/a6968f7a367f128d120447360734344d5a3d5336
- https://git.kernel.org/stable/c/a9564d84ed9f6ee71017d062d0d2182154294a4b
- https://git.kernel.org/stable/c/aec36b98a1bbaa84bfd8299a306e4c12314af626
- https://git.kernel.org/stable/c/b7f3b5d70c834f49f7d87a2f2ed1c6284d9a0322
- https://git.kernel.org/stable/c/d7c5d79e50be6e06b669141e3db1f977a0dd4e8e
- https://git.kernel.org/stable/c/e3e0e067d5b34e4a68e3cc55f8eebc413f56f8ed
- https://git.kernel.org/stable/c/fb7a5115422fbd6a4d505e8844f1ef5529f10489
Modified: 2025-10-14
CVE-2022-49054
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Deactivate sysctl_record_panic_msg by default in isolated guests hv_panic_page might contain guest-sensitive information, do not dump it over to Hyper-V by default in isolated guests. While at it, update some comments in hyperv_{panic,die}_event().
Modified: 2025-10-01
CVE-2022-49055
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check for potential null return of kmalloc_array() As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.
- https://git.kernel.org/stable/c/0a692c625e373fef692ffbc7fc41f8a025f01cb7
- https://git.kernel.org/stable/c/1d7a5aae884ca727d41c7ed15d4c82fdb67c040c
- https://git.kernel.org/stable/c/32cf90a521dcc0f136db7ee5ba32bfe5f79e460e
- https://git.kernel.org/stable/c/40bf32dbfef866c83a3e74800b81d79e52b6d20b
- https://git.kernel.org/stable/c/94869bb0de69a812f70231b0eb480bb2f7ae73a6
- https://git.kernel.org/stable/c/c7a268b33882d5feaafd29c1734456f41ba41396
- https://git.kernel.org/stable/c/ebbb7bb9e80305820dc2328a371c1b35679f2667
- https://git.kernel.org/stable/c/f2658d5966bcee8c3eb487875f459756d4f7cdfc
Modified: 2025-09-23
CVE-2022-49057
In the Linux kernel, the following vulnerability has been resolved: block: null_blk: end timed out poll request When poll request is timed out, it is removed from the poll list, but not completed, so the request is leaked, and never get chance to complete. Fix the issue by ending it in timeout handler.
Modified: 2025-10-01
CVE-2022-49058
In the Linux kernel, the following vulnerability has been resolved: cifs: potential buffer overflow in handling symlinks Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer.
- https://git.kernel.org/stable/c/1316c28569a80ab3596eeab05bf5e01991e7e739
- https://git.kernel.org/stable/c/22d658c6c5affed10c8907e67160cef0b6c92186
- https://git.kernel.org/stable/c/3e582749e742e662a8e9bb37cffac62dccaaa1e2
- https://git.kernel.org/stable/c/4e166a41180be2f1e66bbb6d46448e80a9a5ec05
- https://git.kernel.org/stable/c/515e7ba11ef043d6febe69389949c8ef5f25e9d0
- https://git.kernel.org/stable/c/64c4a37ac04eeb43c42d272f6e6c8c12bfcf4304
- https://git.kernel.org/stable/c/9901b07ba42b39266b34a888e48d7306fd707bee
- https://git.kernel.org/stable/c/eb5f51756944735ac70cd8bb38637cc202e29c91
Modified: 2025-03-24
CVE-2022-49059
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: add flush_workqueue to prevent uaf
Our detector found a concurrent use-after-free bug when detaching an
NCI device. The main reason for this bug is the unexpected scheduling
between the used delayed mechanism (timer and workqueue).
The race can be demonstrated below:
Thread-1 Thread-2
| nci_dev_up()
| nci_open_device()
| __nci_request(nci_reset_req)
| nci_send_cmd
| queue_work(cmd_work)
nci_unregister_device() |
nci_close_device() | ...
del_timer_sync(cmd_timer)[1] |
... | Worker
nci_free_device() | nci_cmd_work()
kfree(ndev)[3] | mod_timer(cmd_timer)[2]
In short, the cleanup routine thought that the cmd_timer has already
been detached by [1] but the mod_timer can re-attach the timer [2], even
it is already released [3], resulting in UAF.
This UAF is easy to trigger, crash trace by POC is like below
[ 66.703713] ==================================================================
[ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490
[ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33
[ 66.703974]
[ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5
[ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work
[ 66.703974] Call Trace:
[ 66.703974]
- https://git.kernel.org/stable/c/1a1748d0dd0f0a98535c6baeef671c8722107639
- https://git.kernel.org/stable/c/5c63ad2b0a267a524c12c88acb1ba9c2d109a801
- https://git.kernel.org/stable/c/67677050cecbe0edfdd81cd508415e9636ba7c65
- https://git.kernel.org/stable/c/7d3232214ca4ea8f7d18df264c3b254aa8089d7f
- https://git.kernel.org/stable/c/9d243aff5f7e6b04e907c617426bbdf26e996ac8
- https://git.kernel.org/stable/c/9ded5ae40f4fe37fcc28f36d76bf45df20be5432
- https://git.kernel.org/stable/c/edd4600120641e1714e30112e69a548cfb68e067
- https://git.kernel.org/stable/c/ef27324e2cb7bb24542d6cb2571740eefe6b00dc
Modified: 2025-10-01
CVE-2022-49060
In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() dev_name() was called with dev.parent as argument but without to NULL-check it before. Solve this by checking the pointer before the call to dev_name().
- https://git.kernel.org/stable/c/22025513ced3d599ee8b24169141c95cf2467a4a
- https://git.kernel.org/stable/c/35b91e49bc80ca944a8679c3b139ddaf2f8eea0f
- https://git.kernel.org/stable/c/3a523807f01455fe9a0c1a433f27cd4411ee400f
- https://git.kernel.org/stable/c/a05f5e26cb8bb4d07e0595545fcad1bb406f0085
- https://git.kernel.org/stable/c/d22f4f977236f97e01255a80bca2ea93a8094fc8
Modified: 2025-10-01
CVE-2022-49061
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link When using a fixed-link, the altr_tse_pcs driver crashes due to null-pointer dereference as no phy_device is provided to tse_pcs_fix_mac_speed function. Fix this by adding a check for phy_dev before calling the tse_pcs_fix_mac_speed() function. Also clean up the tse_pcs_fix_mac_speed function a bit. There is no need to check for splitter_base and sgmii_adapter_base because the driver will fail if these 2 variables are not derived from the device tree.
- https://git.kernel.org/stable/c/08d5e3e954537931c8da7428034808d202e98299
- https://git.kernel.org/stable/c/62a48383ebe2e159fd68425dd3e16d4c6bd6599a
- https://git.kernel.org/stable/c/6c020f05253df04c3480b586fe188a3582740049
- https://git.kernel.org/stable/c/7e59fdf9547c4f948d1d917ec7ffa5fb5ac53bdb
- https://git.kernel.org/stable/c/a6aaa00324240967272b451bfa772547bd576ee6
Modified: 2025-11-18
CVE-2022-49063
In the Linux kernel, the following vulnerability has been resolved: ice: arfs: fix use-after-free when freeing @rx_cpu_rmap The CI testing bots triggered the following splat: [ 718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80 [ 718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834 [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S W IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1 [ 718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020 [ 718.223418] Call Trace: [ 718.227139] [ 718.230783] dump_stack_lvl+0x33/0x42 [ 718.234431] print_address_description.constprop.9+0x21/0x170 [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80 [ 718.241885] ? free_irq_cpu_rmap+0x53/0x80 [ 718.245539] kasan_report.cold.18+0x7f/0x11b [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80 [ 718.252852] free_irq_cpu_rmap+0x53/0x80 [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice] [ 718.260174] ice_remove_arfs+0x5f/0x70 [ice] [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [ice] [ 718.267419] ice_rebuild+0x39c/0xb60 [ice] [ 718.270974] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 718.274472] ? ice_init_phy_user_cfg+0x360/0x360 [ice] [ 718.278033] ? delay_tsc+0x4a/0xb0 [ 718.281513] ? preempt_count_sub+0x14/0xc0 [ 718.284984] ? delay_tsc+0x8f/0xb0 [ 718.288463] ice_do_reset+0x92/0xf0 [ice] [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice] [ 718.295561] pci_reset_function+0x53/0x80 <...> [ 718.393035] Allocated by task 690: [ 718.433497] Freed by task 20834: [ 718.495688] Last potentially related work creation: [ 718.568966] The buggy address belongs to the object at ffff8881bd127e00 which belongs to the cache kmalloc-96 of size 96 [ 718.574085] The buggy address is located 0 bytes inside of 96-byte region [ffff8881bd127e00, ffff8881bd127e60) [ 718.579265] The buggy address belongs to the page: [ 718.598905] Memory state around the buggy address: [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.610811] ^ [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc This is due to that free_irq_cpu_rmap() is always being called *after* (devm_)free_irq() and thus it tries to work with IRQ descs already freed. For example, on device reset the driver frees the rmap right before allocating a new one (the splat above). Make rmap creation and freeing function symmetrical with {request,free}_irq() calls i.e. do that on ifup/ifdown instead of device probe/remove/resume. These operations can be performed independently from the actual device aRFS configuration. Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers only when aRFS is disabled -- otherwise, CPU rmap sets and clears its own and they must not be touched manually.
- https://git.kernel.org/stable/c/618df75f2e30c7838a3e010ca32cd4893ec9fe33
- https://git.kernel.org/stable/c/ba2f6ec28733fb6b24ed086e676df3df4c138f3f
- https://git.kernel.org/stable/c/d08d2fb6d99d82da1c63aba5c0d1c6f237e150f3
- https://git.kernel.org/stable/c/d7442f512b71fc63a99c8a801422dde4fbbf9f93
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-10-01
CVE-2022-49065
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix the svc_deferred_event trace class Fix a NULL deref crash that occurs when an svc_rqst is deferred while the sunrpc tracing subsystem is enabled. svc_revisit() sets dr->xprt to NULL, so it can't be relied upon in the tracepoint to provide the remote's address. Unfortunately we can't revert the "svc_deferred_class" hunk in commit ece200ddd54b ("sunrpc: Save remote presentation address in svc_xprt for trace events") because there is now a specific check of event format specifiers for unsafe dereferences. The warning that check emits is: event svc_defer_recv has unsafe dereference of argument 1 A "%pISpc" format specifier with a "struct sockaddr *" is indeed flagged by this check. Instead, take the brute-force approach used by the svcrdma_qp_error tracepoint. Convert the dr::addr field into a presentation address in the TP_fast_assign() arm of the trace event, and store that as a string. This fix can be backported to -stable kernels. In the meantime, commit c6ced22997ad ("tracing: Update print fmt check to handle new __get_sockaddr() macro") is now in v5.18, so this wonky fix can be replaced with __sockaddr() and friends properly during the v5.19 merge window.
Modified: 2025-10-14
CVE-2022-49066
In the Linux kernel, the following vulnerability has been resolved:
veth: Ensure eth header is in skb's linear part
After feeding a decapsulated packet to a veth device with act_mirred,
skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(),
which expects at least ETH_HLEN byte of linear data (as
__dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes
unconditionally).
Use pskb_may_pull() to ensure veth_xmit() respects this constraint.
kernel BUG at include/linux/skbuff.h:2328!
RIP: 0010:eth_type_trans+0xcf/0x140
Call Trace:
- https://git.kernel.org/stable/c/1ef0088e43af1de4e3b365218c4d3179d9a37eec
- https://git.kernel.org/stable/c/2fd90b86dff413fbf8128780c04ea9c6849c16e2
- https://git.kernel.org/stable/c/3de2a02b60a4ef0ab76263216f08c7d095fc7c42
- https://git.kernel.org/stable/c/46bc359fec0c6d87b70d7a008bcd9a5e30dd6f27
- https://git.kernel.org/stable/c/726e2c5929de841fdcef4e2bf995680688ae1b87
- https://git.kernel.org/stable/c/93940fc4cb81840dc0fa202de48cccb949a0261d
- https://git.kernel.org/stable/c/d417a859221f127e8edf09c14b76ab50f825e171
- https://git.kernel.org/stable/c/d67c900f1947d64ba8a64f693504bcaab8d9000c
Modified: 2025-10-14
CVE-2022-49067
In the Linux kernel, the following vulnerability has been resolved: powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000. Because of the way __pa() works we have: __pa(0x8000000000000000) == 0, and therefore virt_to_pfn(0x8000000000000000) == 0, and therefore virt_addr_valid(0x8000000000000000) == true Which is wrong, virt_addr_valid() should be false for vmalloc space. In fact all vmalloc addresses that alias with a valid PFN will return true from virt_addr_valid(). That can cause bugs with hardened usercopy as described below by Kefeng Wang: When running ethtool eth0 on 64-bit Book3E, a BUG occurred: usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)! kernel BUG at mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 (unreliable) __check_heap_object+0x168/0x190 __check_object_size+0x1a0/0x200 dev_ethtool+0x2494/0x2b20 dev_ioctl+0x5d0/0x770 sock_do_ioctl+0xf0/0x1d0 sock_ioctl+0x3ec/0x5a0 __se_sys_ioctl+0xf0/0x160 system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 The code shows below, data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true on 64-bit Book3E, which leads to the panic. As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in the virt_addr_valid() for 64-bit, also add upper limit check to make sure the virt is below high_memory. Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start of lowmem, high_memory is the upper low virtual address, the check is suitable for 32-bit, this will fix the issue mentioned in commit 602946ec2f90 ("powerpc: Set max_mapnr correctly") too. On 32-bit there is a similar problem with high memory, that was fixed in commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that commit breaks highmem and needs to be reverted. We can't easily fix __pa(), we have code that relies on its current behaviour. So for now add extra checks to virt_addr_valid(). For 64-bit Book3S the extra checks are not necessary, the combination of virt_to_pfn() and pfn_valid() should yield the correct result, but they are harmless. [mpe: Add additional change log detail]
- https://git.kernel.org/stable/c/a3727c25eacd7e437c4f560957fa3a376fe93e6b
- https://git.kernel.org/stable/c/cbc065efcba000ad8f615f506ebe61b6d3c5145b
- https://git.kernel.org/stable/c/d36febbcd537fcc50284e8b89609632d0146529f
- https://git.kernel.org/stable/c/deab81144d5a043f42804207fb76cfbd8a806978
- https://git.kernel.org/stable/c/fddb88bd266f4513abab7c36bca98935c9148a98
- https://git.kernel.org/stable/c/ffa0b64e3be58519ae472ea29a1a1ad681e32f48
Modified: 2025-10-14
CVE-2022-49068
In the Linux kernel, the following vulnerability has been resolved:
btrfs: release correct delalloc amount in direct IO write path
Running generic/406 causes the following WARNING in btrfs_destroy_inode()
which tells there are outstanding extents left.
In btrfs_get_blocks_direct_write(), we reserve a temporary outstanding
extents with btrfs_delalloc_reserve_metadata() (or indirectly from
btrfs_delalloc_reserve_space(()). We then release the outstanding extents
with btrfs_delalloc_release_extents(). However, the "len" can be modified
in the COW case, which releases fewer outstanding extents than expected.
Fix it by calling btrfs_delalloc_release_extents() for the original length.
To reproduce the warning, the filesystem should be 1 GiB. It's
triggering a short-write, due to not being able to allocate a large
extent and instead allocating a smaller one.
WARNING: CPU: 0 PID: 757 at fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs]
Modules linked in: btrfs blake2b_generic xor lzo_compress
lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram
zsmalloc
CPU: 0 PID: 757 Comm: umount Not tainted 5.17.0-rc8+ #101
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014
RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs]
RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000
RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78
RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8
R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800
R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68
FS: 00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-10-14
CVE-2022-49069
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix by adding FPU protection for dcn30_internal_validate_bw
[Why]
Below general protection fault observed when WebGL Aquarium is run for
longer duration. If drm debug logs are enabled and set to 0x1f then the
issue is observed within 10 minutes of run.
[ 100.717056] general protection fault, probably for non-canonical address 0x2d33302d32323032: 0000 [#1] PREEMPT SMP NOPTI
[ 100.727921] CPU: 3 PID: 1906 Comm: DrmThread Tainted: G W 5.15.30 #12 d726c6a2d6ebe5cf9223931cbca6892f916fe18b
[ 100.754419] RIP: 0010:CalculateSwathWidth+0x1f7/0x44f
[ 100.767109] Code: 00 00 00 f2 42 0f 11 04 f0 48 8b 85 88 00 00 00 f2 42 0f 10 04 f0 48 8b 85 98 00 00 00 f2 42 0f 11 04 f0 48 8b 45 10 0f 57 c0
Modified: 2025-10-01
CVE-2022-49071
In the Linux kernel, the following vulnerability has been resolved: drm/panel: ili9341: fix optional regulator handling If the optional regulator lookup fails, reset the pointer to NULL. Other functions such as mipi_dbi_poweron_reset_conditional() only do a NULL pointer check and will otherwise dereference the error pointer.
Modified: 2025-09-23
CVE-2022-49072
In the Linux kernel, the following vulnerability has been resolved: gpio: Restrict usage of GPIO chip irq members before initialization GPIO chip irq members are exposed before they could be completely initialized and this leads to race conditions. One such issue was observed for the gc->irq.domain variable which was accessed through the I2C interface in gpiochip_to_irq() before it could be initialized by gpiochip_add_irqchip(). This resulted in Kernel NULL pointer dereference. Following are the logs for reference :- kernel: Call Trace: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 To avoid such scenarios, restrict usage of GPIO chip irq members before they are completely initialized.
- https://git.kernel.org/stable/c/0912cf021fb5749372b3782611d8b1de4986c13a
- https://git.kernel.org/stable/c/2c1fa3614795e2b24da1ba95de0b27b8f6ea4537
- https://git.kernel.org/stable/c/5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320
- https://git.kernel.org/stable/c/7e88a50704b0c49ad3f2d11e8b963341cf68a89f
- https://git.kernel.org/stable/c/f8dea54f74cae8c2e4d7b2952e8fed7743a85c87
Modified: 2025-09-23
CVE-2022-49073
In the Linux kernel, the following vulnerability has been resolved:
ata: sata_dwc_460ex: Fix crash due to OOB write
the driver uses libata's "tag" values from in various arrays.
Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,
the value of the SATA_DWC_QCMD_MAX needs to account for that.
Otherwise ATA_TAG_INTERNAL usage cause similar crashes like
this as reported by Tice Rex on the OpenWrt Forum and
reproduced (with symbols) here:
| BUG: Kernel NULL pointer dereference at 0x00000000
| Faulting instruction address: 0xc03ed4b8
| Oops: Kernel access of bad area, sig: 11 [#1]
| BE PAGE_SIZE=4K PowerPC 44x Platform
| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0
| NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c
| REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163)
| MSR: 00021000
- https://git.kernel.org/stable/c/234c0132f76f0676d175757f61b0025191a3d935
- https://git.kernel.org/stable/c/3a8751c0d4e24129e72dcec0139e99833b13904a
- https://git.kernel.org/stable/c/55e1465ba79562a191708a40eeae3f8082a209e3
- https://git.kernel.org/stable/c/596c7efd69aae94f4b0e91172b075eb197958b99
- https://git.kernel.org/stable/c/7aa8104a554713b685db729e66511b93d989dd6a
- https://git.kernel.org/stable/c/8a05a6952ecd59aaa62cbdcdaf523ae2c8f436e8
- https://git.kernel.org/stable/c/fc629224aa62f23849cae83717932985ac51232d
Modified: 2025-10-14
CVE-2022-49074
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing.
- https://git.kernel.org/stable/c/0df6664531a12cdd8fc873f0cac0dcb40243d3e9
- https://git.kernel.org/stable/c/3c07cc242baf83f0bddbbd9d7945d0bee56d8b57
- https://git.kernel.org/stable/c/60e1eb4811f53f5f60c788297d978515e7a2637a
- https://git.kernel.org/stable/c/6fef3e3179e6ed8fecdd004ede541674ffa7749d
- https://git.kernel.org/stable/c/7218a789abb3e033f5f3a85636ca50d9ae7b0fc9
- https://git.kernel.org/stable/c/c7daf1b4ad809692d5c26f33c02ed8a031066548
- https://git.kernel.org/stable/c/ff24114bb08d8b90edf2aff0a4fd0689523e6c17
Modified: 2025-09-23
CVE-2022-49075
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix qgroup reserve overflow the qgroup limit We use extent_changeset->bytes_changed in qgroup_reserve_data() to record how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the bytes_changed is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit. Unlike regular buffered/direct write, which we use one changeset for each ordered extent, which can never be larger than 256M. For fallocate, we use one changeset for the whole range, thus it no longer respects the 256M per extent limit, and caused the problem. The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNT When running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiB Since we have no control of how bytes_changed is used, it's better to set it to u64.
- https://git.kernel.org/stable/c/0355387ea5b02d353c9415613fab908fac5c52a6
- https://git.kernel.org/stable/c/44277c50fdba5019ca25bfad1b71e2561b0de11b
- https://git.kernel.org/stable/c/4b98799e181b4326a613108cf37acc1f55d21b45
- https://git.kernel.org/stable/c/6bfff81286d4491f02dad7814bae5c77c9ad2320
- https://git.kernel.org/stable/c/7941b74ed49b6db25efbef2256ebef843c11a010
- https://git.kernel.org/stable/c/82ae73ac963cee877ce34f7c31b2b456b516e96c
- https://git.kernel.org/stable/c/b642b52d0b50f4d398cb4293f64992d0eed2e2ce
- https://git.kernel.org/stable/c/f3d97b22a708bf9e3f3ac2ba232bcefd0b0c136b
Modified: 2025-03-24
CVE-2022-49076
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix use-after-free bug for mm struct Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may represent the last reference held on the task mm. hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed before the final use in hfi1_release_user_pages(). A new task may allocate the mm structure while it is still being used, resulting in problems. One manifestation is corruption of the mmap_sem counter leading to a hang in down_write(). Another is corruption of an mm struct that is in use by another task.
- https://git.kernel.org/stable/c/0b7186d657ee55e2cdefae498f07d5c1961e8023
- https://git.kernel.org/stable/c/2bbac98d0930e8161b1957dc0ec99de39ade1b3c
- https://git.kernel.org/stable/c/5a9a1b24ddb510715f8f621263938186579a965c
- https://git.kernel.org/stable/c/5f54364ff6cfcd14cddf5441c4a490bb28dd69f7
- https://git.kernel.org/stable/c/9ca11bd8222a612de0d2f54d050bfcf61ae2883f
Modified: 2025-10-14
CVE-2022-49077
In the Linux kernel, the following vulnerability has been resolved: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0) If an mremap() syscall with old_size=0 ends up in move_page_tables(), it will call invalidate_range_start()/invalidate_range_end() unnecessarily, i.e. with an empty range. This causes a WARN in KVM's mmu_notifier. In the past, empty ranges have been diagnosed to be off-by-one bugs, hence the WARNing. Given the low (so far) number of unique reports, the benefits of detecting more buggy callers seem to outweigh the cost of having to fix cases such as this one, where userspace is doing something silly. In this particular case, an early return from move_page_tables() is enough to fix the issue.
- https://git.kernel.org/stable/c/01e67e04c28170c47700c2c226d732bbfedb1ad0
- https://git.kernel.org/stable/c/04bc13dae4a27b8d030843c85ae452bb2f1d9c1f
- https://git.kernel.org/stable/c/2358aa84ef6dafcf544a557caaa6b91afb4a0bd2
- https://git.kernel.org/stable/c/7d659cb1763ff17d1c6ee082fa6feb4267c7a30b
- https://git.kernel.org/stable/c/a04cb99c5d4668fe3f5c0e5b6da1cecd34c3f219
- https://git.kernel.org/stable/c/a05540f3903bd8295e8c4cd90dd3d416239a115b
- https://git.kernel.org/stable/c/c19d8de4e682ec4b0ea2b04a832cd8cc0be3bb31
- https://git.kernel.org/stable/c/e2c328c2a8f9de8b761bd4025b66c63120c55761
- https://git.kernel.org/stable/c/eeaf28e2a0128147d687237e59d5407ee1b14693
Modified: 2025-12-19
CVE-2022-49078
In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/
- https://git.kernel.org/stable/c/467d5e200ab4486b744fe1776154a43d1aa22d4b
- https://git.kernel.org/stable/c/6adc01a7aa37445dafe8846faa0610a86029b253
- https://git.kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3
- https://git.kernel.org/stable/c/9fb8bc6cfc58773ce95414e11c9ccc8fc6ac4927
- https://git.kernel.org/stable/c/e64dbe97c05c769525cbca099ddbd22485630235
- https://git.kernel.org/stable/c/eafc0a02391b7b36617b36c97c4b5d6832cf5e24
Modified: 2025-10-14
CVE-2022-49079
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone
btrfs_can_activate_zone() can be called with the device_list_mutex already
held, which will lead to a deadlock:
insert_dev_extents() // Takes device_list_mutex
`-> insert_dev_extent()
`-> btrfs_insert_empty_item()
`-> btrfs_insert_empty_items()
`-> btrfs_search_slot()
`-> btrfs_cow_block()
`-> __btrfs_cow_block()
`-> btrfs_alloc_tree_block()
`-> btrfs_reserve_extent()
`-> find_free_extent()
`-> find_free_extent_update_loop()
`-> can_allocate_chunk()
`-> btrfs_can_activate_zone() // Takes device_list_mutex again
Instead of using the RCU on fs_devices->device_list we
can use fs_devices->alloc_list, protected by the chunk_mutex to traverse
the list of active devices.
We are in the chunk allocation thread. The newer chunk allocation
happens from the devices in the fs_device->alloc_list protected by the
chunk_mutex.
btrfs_create_chunk()
lockdep_assert_held(&info->chunk_mutex);
gather_device_info
list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list)
Also, a device that reappears after the mount won't join the alloc_list
yet and, it will be in the dev_list, which we don't want to consider in
the context of the chunk alloc.
[15.166572] WARNING: possible recursive locking detected
[15.167117] 5.17.0-rc6-dennis #79 Not tainted
[15.167487] --------------------------------------------
[15.167733] kworker/u8:3/146 is trying to acquire lock:
[15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs]
[15.167733]
[15.167733] but task is already holding lock:
[15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]
[15.167733]
[15.167733] other info that might help us debug this:
[15.167733] Possible unsafe locking scenario:
[15.167733]
[15.171834] CPU0
[15.171834] ----
[15.171834] lock(&fs_devs->device_list_mutex);
[15.171834] lock(&fs_devs->device_list_mutex);
[15.171834]
[15.171834] *** DEADLOCK ***
[15.171834]
[15.171834] May be due to missing lock nesting notation
[15.171834]
[15.171834] 5 locks held by kworker/u8:3/146:
[15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0
[15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0
[15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs]
[15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]
[15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs]
[15.179641]
[15.179641] stack backtrace:
[15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79
[15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014
[15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]
[15.179641] Call Trace:
[15.179641]
Modified: 2025-09-23
CVE-2022-49080
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix mpol_new leak in shared_policy_replace If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation. This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
- https://git.kernel.org/stable/c/198932a14aeb19a15cf19e51e151d023bc4cd648
- https://git.kernel.org/stable/c/25f506273b6ae806fd46bfcb6fdaa5b9ec81a05b
- https://git.kernel.org/stable/c/39a32f3c06f6d68a530bf9612afa19f50f12e93d
- https://git.kernel.org/stable/c/4ad099559b00ac01c3726e5c95dc3108ef47d03e
- https://git.kernel.org/stable/c/5e16dc5378abd749a836daa9ee4ab2c8d2668999
- https://git.kernel.org/stable/c/6e00309ac716fa8225f0cbde2cd9c24f0e74ee21
- https://git.kernel.org/stable/c/8510c2346d9e47a72b7f018a36ef0c39483e53d6
- https://git.kernel.org/stable/c/f7e183b0a7136b6dc9c7b9b2a85a608a8feba894
- https://git.kernel.org/stable/c/fe39ac59dbbf893b73b24e3184161d0bd06d6651
Modified: 2025-10-14
CVE-2022-49081
In the Linux kernel, the following vulnerability has been resolved: highmem: fix checks in __kmap_local_sched_{in,out} When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check that even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots are initialized with 0 value, but the check is done with pte_none. 0 pte however does not necessarily mean that pte_none will return true. e.g. on xtensa it returns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 finish_task_switch$isra$0+0x1ce/0x2f8 __schedule+0x86e/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.
Modified: 2025-03-25
CVE-2022-49082
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove()
The function mpt3sas_transport_port_remove() called in
_scsih_expander_node_remove() frees the port field of the sas_expander
structure, leading to the following use-after-free splat from KASAN when
the ioc_info() call following that function is executed (e.g. when doing
rmmod of the driver module):
[ 3479.371167] ==================================================================
[ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
[ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531
[ 3479.393524]
[ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436
[ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021
[ 3479.409263] Call Trace:
[ 3479.411743]
Modified: 2025-09-23
CVE-2022-49083
In the Linux kernel, the following vulnerability has been resolved:
iommu/omap: Fix regression in probe for NULL pointer dereference
Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started
triggering a NULL pointer dereference for some omap variants:
__iommu_probe_device from probe_iommu_group+0x2c/0x38
probe_iommu_group from bus_for_each_dev+0x74/0xbc
bus_for_each_dev from bus_iommu_probe+0x34/0x2e8
bus_iommu_probe from bus_set_iommu+0x80/0xc8
bus_set_iommu from omap_iommu_init+0x88/0xcc
omap_iommu_init from do_one_initcall+0x44/0x24
This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV)
as noted by Jason Gunthorpe
- https://git.kernel.org/stable/c/1d89f2b9eadbcf3ce93c6d7238f68299a1f84968
- https://git.kernel.org/stable/c/47e239117bd97c8556f9187af7a9a7938db4e021
- https://git.kernel.org/stable/c/71ff461c3f41f6465434b9e980c01782763e7ad8
- https://git.kernel.org/stable/c/bd905fed87ce01ac010011bb8f44ed0140116ceb
- https://git.kernel.org/stable/c/ea518578aa8a9a0280605b53cc33f707e10c8178
Modified: 2025-09-23
CVE-2022-49084
In the Linux kernel, the following vulnerability has been resolved: qede: confirm skb is allocated before using qede_build_skb() assumes build_skb() always works and goes straight to skb_reserve(). However, build_skb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL. Add a check in case build_skb() failed to allocate and return NULL. The NULL return is handled correctly in callers to qede_build_skb().
- https://git.kernel.org/stable/c/034a92c6a81048128fc7b18d278d52438a13902a
- https://git.kernel.org/stable/c/4e910dbe36508654a896d5735b318c0b88172570
- https://git.kernel.org/stable/c/8928239e5e2e460d95b8a0b89f61671625e7ece0
- https://git.kernel.org/stable/c/9648adb1b3ece55c657d3a4f52bfee663b710dfe
- https://git.kernel.org/stable/c/b2d6b3db9d1cf80908964036dbe1c52a86b1afb1
- https://git.kernel.org/stable/c/c9bdce2359b5f4986eb38d1e81865b3586cc20d2
- https://git.kernel.org/stable/c/e1fd0c42acfa22bb34d2ab6a111484f466ab8093
Modified: 2025-03-25
CVE-2022-49085
In the Linux kernel, the following vulnerability has been resolved: drbd: Fix five use after free bugs in get_initial_state In get_initial_state, it calls notify_initial_state_done(skb,..) if cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(), the skb will be freed by nlmsg_free(skb). Then get_initial_state will goto out and the freed skb will be used by return value skb->len, which is a uaf bug. What's worse, the same problem goes even further: skb can also be freed in the notify_*_state_change -> notify_*_state calls below. Thus 4 additional uaf bugs happened. My patch lets the problem callee functions: notify_initial_state_done and notify_*_state_change return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid. v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/
- https://git.kernel.org/stable/c/0489700bfeb1e53eb2039c2291c67e71b0b40103
- https://git.kernel.org/stable/c/188fe6b26765edbad4055611c0f788b6870f4024
- https://git.kernel.org/stable/c/226e993c39405292781bfcf4b039a8db56aab362
- https://git.kernel.org/stable/c/594205b4936771a250f9d141e7e0fff21c3dd2d9
- https://git.kernel.org/stable/c/a972c768723359ec995579902473028fe3cd64b1
- https://git.kernel.org/stable/c/aadb22ba2f656581b2f733deb3a467c48cc618f6
- https://git.kernel.org/stable/c/b6a4055036eed1f5e239ce3d8b0db1ce38bba447
- https://git.kernel.org/stable/c/dcf6be17b5c53b741898d2223b23e66d682de300
- https://git.kernel.org/stable/c/de63e74da2333b4068bb79983e632db730fea97e
Modified: 2025-09-23
CVE-2022-49086
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0) Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too.
- https://git.kernel.org/stable/c/1f30fb9166d4f15a1aa19449b9da871fe0ed4796
- https://git.kernel.org/stable/c/3554c214b83ec9a839ed574263a34218f372990c
- https://git.kernel.org/stable/c/53bce9d19b0a9d245b25cd050b81652ed974a509
- https://git.kernel.org/stable/c/5ae05b5eb58773cfec307ff88aff4cfd843c4cff
- https://git.kernel.org/stable/c/7438dc55c0709819b813f4778aec2c48b782990b
- https://git.kernel.org/stable/c/837b96d8103938e35e7d92cd9db96af914ca4fff
- https://git.kernel.org/stable/c/ef6f9ce0a79aa23b10fc5f3b3cab3814a25aac40
Modified: 2025-03-25
CVE-2022-49087
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix a race in rxrpc_exit_net()
Current code can lead to the following race:
CPU0 CPU1
rxrpc_exit_net()
rxrpc_peer_keepalive_worker()
if (rxnet->live)
rxnet->live = false;
del_timer_sync(&rxnet->peer_keepalive_timer);
timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);
cancel_work_sync(&rxnet->peer_keepalive_work);
rxrpc_exit_net() exits while peer_keepalive_timer is still armed,
leading to use-after-free.
syzbot report was:
ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0
WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Modules linked in:
CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0
R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/08ff0e74fab517dbc44e11b8bc683dd4ecc65950
- https://git.kernel.org/stable/c/1946014ca3b19be9e485e780e862c375c6f98bad
- https://git.kernel.org/stable/c/41024a40f6c793abbb916a857f18fb009f07464c
- https://git.kernel.org/stable/c/571d8e1d154ca18f08dcb72b69318d36e10010a0
- https://git.kernel.org/stable/c/7ee84d29f22de6f6c63fad6c54690517659862f1
- https://git.kernel.org/stable/c/864297ee30727ae6233f80296b7fc91442620b05
- https://git.kernel.org/stable/c/cd8aef1f30d1215648e4e6686cfb422004851429
Modified: 2025-09-23
CVE-2022-49088
In the Linux kernel, the following vulnerability has been resolved: dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak.
- https://git.kernel.org/stable/c/2b04bd4f03bba021959ca339314f6739710f0954
- https://git.kernel.org/stable/c/45fdd98b70142521739615ad1bfb760401863b73
- https://git.kernel.org/stable/c/46d120f7c163706d6c31ee00baa0be64c4572b78
- https://git.kernel.org/stable/c/599874bbc4ed832ccb578d48ac0ae7344382ef43
- https://git.kernel.org/stable/c/ebd1e3458dbf6643aa0272da398cb5b537d492b7
- https://git.kernel.org/stable/c/fbe5f4c0dd3475178f17ddd8b8d5044ebeae0be7
Modified: 2025-09-23
CVE-2022-49089
In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition.
- https://git.kernel.org/stable/c/43c2d7890ecabe527448a6c391fb2d9a5e6bbfe0
- https://git.kernel.org/stable/c/4d809f69695d4e7d1378b3a072fa9aef23123018
- https://git.kernel.org/stable/c/57800cc36e55db0547461c49acf5cd84c0f502b0
- https://git.kernel.org/stable/c/77ffb2495a41098f9d6a14f8aefde3188da75944
- https://git.kernel.org/stable/c/8a50937227c385a477177c9ffa122b4230e40666
- https://git.kernel.org/stable/c/92f1947c0d26060e978b3a9f21f32ce7c8c9cca3
Modified: 2025-09-23
CVE-2022-49090
In the Linux kernel, the following vulnerability has been resolved: arch/arm64: Fix topology initialization for core scheduling Arm64 systems rely on store_cpu_topology() to call update_siblings_masks() to transfer the toplogy to the various cpu masks. This needs to be done before the call to notify_cpu_starting() which tells the scheduler about each cpu found, otherwise the core scheduling data structures are setup in a way that does not match the actual topology. With smt_mask not setup correctly we bail on `cpumask_weight(smt_mask) == 1` for !leaders in: notify_cpu_starting() cpuhp_invoke_callback_range() sched_cpu_starting() sched_core_cpu_starting() which leads to rq->core not being correctly set for !leader-rq's. Without this change stress-ng (which enables core scheduling in its prctl tests in newer versions -- i.e. with PR_SCHED_CORE support) causes a warning and then a crash (trimmed for legibility): [ 1853.805168] ------------[ cut here ]------------ [ 1853.809784] task_rq(b)->core != rq->core [ 1853.809792] WARNING: CPU: 117 PID: 0 at kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4 ... [ 1854.015210] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... [ 1854.231256] Call trace: [ 1854.233689] pick_next_task+0x3dc/0x81c [ 1854.237512] __schedule+0x10c/0x4cc [ 1854.240988] schedule_idle+0x34/0x54
Modified: 2025-09-23
CVE-2022-49091
In the Linux kernel, the following vulnerability has been resolved: drm/imx: Fix memory leak in imx_pd_connector_get_modes Avoid leaking the display mode variable if of_get_drm_display_mode fails. Addresses-Coverity-ID: 1443943 ("Resource leak")
- https://git.kernel.org/stable/c/31e449302ed00c38d4068443cf0243279701ab28
- https://git.kernel.org/stable/c/38bf605bd8c83d942c8dcffaef3633b7d8b37549
- https://git.kernel.org/stable/c/41624d7c0c3df71dee170c610744aaa5909327b8
- https://git.kernel.org/stable/c/7526102d908ec5ae777aa77723d52fce12916093
- https://git.kernel.org/stable/c/bc23c327e1a23cc3555fa1e86288e13288515442
- https://git.kernel.org/stable/c/bce81feb03a20fca7bbdd1c4af16b4e9d5c0e1d3
- https://git.kernel.org/stable/c/c539a6a5896ed92bfb91494e46996d013f3d5967
- https://git.kernel.org/stable/c/d2c2758cfb0262637fd93350bdc8ad485fb1dd61
- https://git.kernel.org/stable/c/f8b0ef0a5889890b50482b6593bd8de544736351
Modified: 2025-10-14
CVE-2022-49092
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: fix route with nexthop object delete warning
FRR folks have hit a kernel warning[1] while deleting routes[2] which is
caused by trying to delete a route pointing to a nexthop id without
specifying nhid but matching on an interface. That is, a route is found
but we hit a warning while matching it. The warning is from
fib_info_nh() in include/net/nexthop.h because we run it on a fib_info
with nexthop object. The call chain is:
inet_rtm_delroute -> fib_table_delete -> fib_nh_match (called with a
nexthop fib_info and also with fc_oif set thus calling fib_info_nh on
the fib_info and triggering the warning). The fix is to not do any
matching in that branch if the fi has a nexthop object because those are
managed separately. I.e. we should match when deleting without nh spec and
should fail when deleting a nexthop route with old-style nh spec because
nexthop objects are managed separately, e.g.:
$ ip r show 1.2.3.4/32
1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0
$ ip r del 1.2.3.4/32
$ ip r del 1.2.3.4/32 nhid 12
- https://git.kernel.org/stable/c/63ea57478aaa3e06a597081a0f537318fc04e49f
- https://git.kernel.org/stable/c/6bf92d70e690b7ff12b24f4bfff5e5434d019b82
- https://git.kernel.org/stable/c/907c97986d6fa77318d17659dd76c94b65dd27c5
- https://git.kernel.org/stable/c/dcd689f9e2640c992f94eae9955b106f71c6825d
- https://git.kernel.org/stable/c/f5064531c23ad646da7be8b938292b00a7e61438
- https://git.kernel.org/stable/c/f8db5743d09523c0bb35f16e13691e3b7eb5dba0
Modified: 2025-03-25
CVE-2022-49093
In the Linux kernel, the following vulnerability has been resolved: skbuff: fix coalescing for page_pool fragment recycling Fix a use-after-free when using page_pool with page fragments. We encountered this problem during normal RX in the hns3 driver: (1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through page_pool, and the other two allocate one half of PAGE2 each. Page references look like this: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcp_queue_rcv(). (3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netif_receive_skb(): netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 and SKB3 share a reference to PAGE2 through skb_shinfo()->dataref. The other ref to PAGE2 is still held by RX_BD3: SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ (3b) Now while handling TCP, coalesce SKB3 with SKB1: tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds kfree_skb_partial(SKB3) skb_release_data(SKB3) // drops one dataref SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ In skb_try_coalesce(), __skb_frag_ref() takes a page reference to PAGE2, where it should instead have increased the page_pool frag reference, pp_frag_count. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow. (3c) Drop SKB2: af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // drops second dataref page_pool_return_skb_page(PAGE2) // drops one pp_frag_count SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/ (4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well: tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // drops second pp_frag_count (5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled. Change the logic that checks whether pp_recycle SKBs can be coalesced. We still reject differing pp_recycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pp_recycled and 'from' is cloned. The new logic allows coalescing a cloned pp_recycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skb_try_coalesce().
Modified: 2025-09-23
CVE-2022-49094
In the Linux kernel, the following vulnerability has been resolved:
net/tls: fix slab-out-of-bounds bug in decrypt_internal
The memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting in
tls_set_sw_offload(). The return value of crypto_aead_ivsize()
for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes
memory space will trigger slab-out-of-bounds bug as following:
==================================================================
BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]
Read of size 16 at addr ffff888114e84e60 by task tls/10911
Call Trace:
- https://git.kernel.org/stable/c/2304660ab6c425df64d95301b601424c6a50f28b
- https://git.kernel.org/stable/c/29be1816cbab9a0dc6243120939fd10a92753756
- https://git.kernel.org/stable/c/2b7d14c105dd8f6412eda5a91e1e6154653731e3
- https://git.kernel.org/stable/c/589154d0f18945f41d138a5b4e49e518d294474b
- https://git.kernel.org/stable/c/6e2f1b033b17dedda51d465861b69e58317d6343
- https://git.kernel.org/stable/c/9381fe8c849cfbe50245ac01fc077554f6eaa0e2
Modified: 2025-09-23
CVE-2022-49095
In the Linux kernel, the following vulnerability has been resolved: scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one() The error handling path of the probe releases a resource that is not freed in the remove function. In some cases, a ioremap() must be undone. Add the missing iounmap() call in the remove function.
- https://git.kernel.org/stable/c/16ed828b872d12ccba8f07bcc446ae89ba662f9c
- https://git.kernel.org/stable/c/1e0c01319dedf1e63ec5df37ead048e17afd92ba
- https://git.kernel.org/stable/c/34a47f7ddb4fd1cbd12397aa6f7dad1de08b4050
- https://git.kernel.org/stable/c/a845c678e094894f38cc9526d212b21933ce44c7
- https://git.kernel.org/stable/c/aefd755a96051aa56b198cb7ecd168b22ba384f6
- https://git.kernel.org/stable/c/c5f77b595379b5191316edd365a542f8b1526066
- https://git.kernel.org/stable/c/ce430cfad6a5385d5b7f7c1dc3fa50f10abfd41b
- https://git.kernel.org/stable/c/db863ab2baf058ed05c7b723612e3c40c9dd6885
- https://git.kernel.org/stable/c/de6aee0978f164d3d0c771ce03e3066a26c371c5
Modified: 2025-10-01
CVE-2022-49096
In the Linux kernel, the following vulnerability has been resolved:
net: sfc: add missing xdp queue reinitialization
After rx/tx ring buffer size is changed, kernel panic occurs when
it acts XDP_TX or XDP_REDIRECT.
When tx/rx ring buffer size is changed(ethtool -G), sfc driver
reallocates and reinitializes rx and tx queues and their buffer
(tx_queue->buffer).
But it misses reinitializing xdp queues(efx->xdp_tx_queues).
So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized
tx_queue->buffer.
A new function efx_set_xdp_channels() is separated from efx_set_channels()
to handle only xdp queues.
Splat looks like:
BUG: kernel NULL pointer dereference, address: 000000000000002a
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#4] PREEMPT SMP NOPTI
RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 5.17.0+ #55 e8beeee8289528f11357029357cf
Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80
RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297
RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]
RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870
RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0
RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000
R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040
R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0
FS: 0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80
CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0
RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297
PKRU: 55555554
RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870
RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700
RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000
R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040
R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700
FS: 0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0
PKRU: 55555554
Call Trace:
Modified: 2025-09-23
CVE-2022-49097
In the Linux kernel, the following vulnerability has been resolved: NFS: Avoid writeback threads getting stuck in mempool_alloc() In a low memory situation, allow the NFS writeback code to fail without getting stuck in infinite loops in mempool_alloc().
- https://git.kernel.org/stable/c/0bae835b63c53f86cdc524f5962e39409585b22c
- https://git.kernel.org/stable/c/1b3fa9a3c420c31e77b406ddc28f3a627100516c
- https://git.kernel.org/stable/c/a6caeddd68977a1aaaf62fbd1955b41dd5c3c5d3
- https://git.kernel.org/stable/c/c74e2f6ecc51bd08bb5b0335477dba954a50592e
- https://git.kernel.org/stable/c/ea029e4ce760f786919d06ef52efa2e50ea92a5f
Modified: 2025-10-14
CVE-2022-49098
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix potential crash on module unload The vmbus driver relies on the panic notifier infrastructure to perform some operations when a panic event is detected. Since vmbus can be built as module, it is required that the driver handles both registering and unregistering such panic notifier callback. After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback") though, the panic notifier registration is done unconditionally in the module initialization routine whereas the unregistering procedure is conditionally guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability is set. This patch fixes that by unconditionally unregistering the panic notifier in the module's exit routine as well.
- https://git.kernel.org/stable/c/2133c422a103cf7c7768c37b9ac382e73b691892
- https://git.kernel.org/stable/c/3d0078f8bddd58d9bb1ad40bbe929f8633abb276
- https://git.kernel.org/stable/c/5ea98d0f5f035c1bcf1517ccec0e024ae35a48b2
- https://git.kernel.org/stable/c/6b4c0149a56147b29169e07000d566162892722a
- https://git.kernel.org/stable/c/792f232d57ff28bbd5f9c4abe0466b23d5879dc8
- https://git.kernel.org/stable/c/cf580d2e3884dbafd6b90269b03a24d661578624
- https://git.kernel.org/stable/c/dcd6b1a624c0ffa21034d8b1e02e9d068458f596
Modified: 2025-10-14
CVE-2022-49100
In the Linux kernel, the following vulnerability has been resolved: virtio_console: eliminate anonymous module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs
- https://git.kernel.org/stable/c/0f3d824bd70a1303464d5e93ee3e7afe7832fe89
- https://git.kernel.org/stable/c/3504b0a177208eda85bf472bbf7c9aa77d2b8343
- https://git.kernel.org/stable/c/3fd5dee7404ce40c79cba468bb2510115639d975
- https://git.kernel.org/stable/c/44c2d5fbe7b2bd1f8cb114d608a591a73a5d4ae6
- https://git.kernel.org/stable/c/71612aee09ecea3475f8751dc841d75a011b1fd0
- https://git.kernel.org/stable/c/7deaddb704713608e0ae559e27185581b9af71a0
- https://git.kernel.org/stable/c/93e3d88321d2274fa4e26b006e19cc10fec331c2
- https://git.kernel.org/stable/c/c69b442125bf009fce26e15aa5616caf8a3673c3
- https://git.kernel.org/stable/c/fefb8a2a941338d871e2d83fbd65fbfa068857bd
Modified: 2025-10-01
CVE-2022-49102
In the Linux kernel, the following vulnerability has been resolved: habanalabs: fix possible memory leak in MMU DR fini This patch fixes what seems to be copy paste error. We will have a memory leak if the host-resident shadow is NULL (which will likely happen as the DR and HR are not dependent).
Modified: 2025-10-01
CVE-2022-49103
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix reference count leaks in _nfs42_proc_copy_notify() [You don't often get email from xiongx18@fudan.edu.cn. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.] The reference counting issue happens in two error paths in the function _nfs42_proc_copy_notify(). In both error paths, the function simply returns the error code and forgets to balance the refcount of object `ctx`, bumped by get_nfs_open_context() earlier, which may cause refcount leaks. Fix it by balancing refcount of the `ctx` object before the function returns in both error paths.
- https://git.kernel.org/stable/c/9b9feec97c1fc7dd9bb69f62c4905cddf1801599
- https://git.kernel.org/stable/c/b37f482ba9f0e6382c188e3fccf6c4b2fdc938eb
- https://git.kernel.org/stable/c/b7f114edd54326f730a754547e7cfb197b5bc132
- https://git.kernel.org/stable/c/f46f632f9cfae4b2e3635fa58840a8ec584c42e3
- https://git.kernel.org/stable/c/fb73bf6305f4eb8f0cf9a61ee874d55f019d6dc4
Modified: 2025-10-01
CVE-2022-49104
In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_core: handle NULL result of find_service_by_handle In case of an invalid handle the function find_servive_by_handle returns NULL. So take care of this and avoid a NULL pointer dereference.
- https://git.kernel.org/stable/c/04202f54dd8899e10f56a89c4c1ede0043fa22af
- https://git.kernel.org/stable/c/3b424f6586a870b8d657c5e5419465bbe0e7b61f
- https://git.kernel.org/stable/c/42f2142a337ee372455574809fc924580a7e51b2
- https://git.kernel.org/stable/c/aa0b7296785312a4bfa8fac0ba8ad78698fd9fcf
- https://git.kernel.org/stable/c/ca225857faf237234d2fffe5d1919467dfadd822
Modified: 2025-10-01
CVE-2022-49105
In the Linux kernel, the following vulnerability has been resolved: staging: wfx: fix an error handling in wfx_init_common() One error handler of wfx_init_common() return without calling ieee80211_free_hw(hw), which may result in memory leak. And I add one err label to unify the error handler, which is useful for the subsequent changes.
- https://git.kernel.org/stable/c/60f1d3c92dc1ef1026e5b917a329a7fa947da036
- https://git.kernel.org/stable/c/86efcb524ae1889ae73f2a2f0bb7fff2ec757ab0
- https://git.kernel.org/stable/c/93498c6e775ae91732a8109dba1bdcd324908f84
- https://git.kernel.org/stable/c/9727912e906762a63c1a667c84731d3427653f88
- https://git.kernel.org/stable/c/ab0fed1fa744173433cfd1dbaf9239f200ded650
Modified: 2025-10-01
CVE-2022-49106
In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_arm: Avoid NULL ptr deref in vchiq_dump_platform_instances vchiq_get_state() can return a NULL pointer. So handle this cases and avoid a NULL pointer derefence in vchiq_dump_platform_instances.
Modified: 2025-10-01
CVE-2022-49107
In the Linux kernel, the following vulnerability has been resolved: ceph: fix memory leak in ceph_readdir when note_last_dentry returns error Reset the last_readdir at the same time, and add a comment explaining why we don't free last_readdir when dir_emit returns false.
- https://git.kernel.org/stable/c/2fe82d3254029ef9ec4e7be890125d5ef4f537de
- https://git.kernel.org/stable/c/7f740ede35132d3d5d19747cad56a511d21bb156
- https://git.kernel.org/stable/c/e792575b902a3939ca482491ee9fb3a236f99640
- https://git.kernel.org/stable/c/f4429786129648a8f4bb1e5faa143c4478cc5c4a
- https://git.kernel.org/stable/c/f639d9867eea647005dc824e0e24f39ffc50d4e4
Modified: 2025-10-01
CVE-2022-49108
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: Fix memory leaks on probe Handle the error branches to free memory where required. Addresses-Coverity-ID: 1491825 ("Resource leak")
Modified: 2025-09-23
CVE-2022-49109
In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode reference leakage in ceph_get_snapdir() The ceph_get_inode() will search for or insert a new inode into the hash for the given vino, and return a reference to it. If new is non-NULL, its reference is consumed. We should release the reference when in error handing cases.
Modified: 2025-09-23
CVE-2022-49110
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: revisit gc autotuning as of commit 4608fdfc07e1 ("netfilter: conntrack: collect all entries in one cycle") conntrack gc was changed to run every 2 minutes. On systems where conntrack hash table is set to large value, most evictions happen from gc worker rather than the packet path due to hash table distribution. This causes netlink event overflows when events are collected. This change collects average expiry of scanned entries and reschedules to the average remaining value, within 1 to 60 second interval. To avoid event overflows, reschedule after each bucket and add a limit for both run time and number of evictions per run. If more entries have to be evicted, reschedule and restart 1 jiffy into the future.
Modified: 2025-03-25
CVE-2022-49111
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use after free in hci_send_acl
This fixes the following trace caused by receiving
HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without
first checking if conn->type is in fact AMP_LINK and in case it is
do properly cleanup upper layers with hci_disconn_cfm:
==================================================================
BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50
Read of size 8 at addr ffff88800e404818 by task bluetoothd/142
CPU: 0 PID: 142 Comm: bluetoothd Not tainted
5.17.0-rc5-00006-gda4022eeac1a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/2cc803804ec9a296b3156855d6c8c4ca1c6b84be
- https://git.kernel.org/stable/c/3803d896ddd97c7c16689a5381c0960040727647
- https://git.kernel.org/stable/c/4da302b90b96c309987eb9b37c8547f939f042d2
- https://git.kernel.org/stable/c/643a6c26bd32e339d00ad97b8822b6db009e803c
- https://git.kernel.org/stable/c/684e505406abaeabe0058e9776f9210bf2747953
- https://git.kernel.org/stable/c/b3c2ea1fd444b3bb7b82bfd2c3a45418f85c2502
- https://git.kernel.org/stable/c/c41de54b0a963e59e4dd04c029a4a6d73f45ef9c
- https://git.kernel.org/stable/c/d404765dffdbd8dcd14758695d0c96c52fb2e624
- https://git.kernel.org/stable/c/f63d24baff787e13b723d86fe036f84bdbc35045
Modified: 2025-10-14
CVE-2022-49112
In the Linux kernel, the following vulnerability has been resolved: mt76: fix monitor mode crash with sdio driver mt7921s driver may receive frames with fragment buffers. If there is a CTS packet received in monitor mode, the payload is 10 bytes only and need 6 bytes header padding after RXD buffer. However, only RXD in the first linear buffer, if we pull buffer size RXD-size+6 bytes with skb_pull(), that would trigger "BUG_ON(skb->len < skb->data_len)" in __skb_pull(). To avoid the nonlinear buffer issue, enlarge the RXD size from 128 to 256 to make sure all MCU operation in linear buffer. [ 52.007562] kernel BUG at include/linux/skbuff.h:2313! [ 52.007578] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 52.007987] pc : skb_pull+0x48/0x4c [ 52.008015] lr : mt7921_queue_rx_skb+0x494/0x890 [mt7921_common] [ 52.008361] Call trace: [ 52.008377] skb_pull+0x48/0x4c [ 52.008400] mt76s_net_worker+0x134/0x1b0 [mt76_sdio 35339a92c6eb7d4bbcc806a1d22f56365565135c] [ 52.008431] __mt76_worker_fn+0xe8/0x170 [mt76 ef716597d11a77150bc07e3fdd68eeb0f9b56917] [ 52.008449] kthread+0x148/0x3ac [ 52.008466] ret_from_fork+0x10/0x30
Modified: 2025-10-01
CVE-2022-49113
In the Linux kernel, the following vulnerability has been resolved: powerpc/secvar: fix refcount leak in format_show() Refcount leak will happen when format_show returns failure in multiple cases. Unified management of of_node_put can fix this problem.
- https://git.kernel.org/stable/c/02222bf4f0a27f6eba66d1f597cdb5daadd51829
- https://git.kernel.org/stable/c/2a71e3ecd829a82013cf095c55068c61d991e885
- https://git.kernel.org/stable/c/c105ffb6b9744158e37e9f81f0f38861951d1c1f
- https://git.kernel.org/stable/c/d05e4265d33af60b39606c20c731e3e719bfe3d6
- https://git.kernel.org/stable/c/d601fd24e6964967f115f036a840f4f28488f63f
Modified: 2025-03-25
CVE-2022-49114
In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix use after free in fc_exch_abts_resp() fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free.
- https://git.kernel.org/stable/c/1d7effe5fff9d28e45e18ac3a564067c7ddfe898
- https://git.kernel.org/stable/c/271add11994ba1a334859069367e04d2be2ebdd4
- https://git.kernel.org/stable/c/412dd8299b02e4410fe77b8396953c1a8dde183a
- https://git.kernel.org/stable/c/499d198494e77b6533251b9b909baf5c101129cb
- https://git.kernel.org/stable/c/4a131d4ea8b581ac9b01d3a72754db4848be3232
- https://git.kernel.org/stable/c/5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836
- https://git.kernel.org/stable/c/6044ad64f41c87382cfeeca281573d1886d80cbe
- https://git.kernel.org/stable/c/87909291762d08fdb60d19069d7a89b5b308d0ef
- https://git.kernel.org/stable/c/f581df412bc45c95176e3c808ee2839c05b2ab0c
Modified: 2025-10-01
CVE-2022-49115
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix misused goto label Fix a misused goto label jump since that can result in a memory leak.
- https://git.kernel.org/stable/c/70236a0d2d62b081d52076de22d8d017d6cbe99f
- https://git.kernel.org/stable/c/7c657c0694ff690e361a13ce41c36b9dfb433ec8
- https://git.kernel.org/stable/c/bf8d87c076f55b8b4dfdb6bc6c6b6dc0c2ccb487
- https://git.kernel.org/stable/c/d3642fc64276b06446290f82fd45630aeaa4b007
- https://git.kernel.org/stable/c/dc9d33b2d8d09e6478e8ef817a81cf26930acc3e
Modified: 2025-10-01
CVE-2022-49116
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: use memset avoid memory leaks Use memset to initialize structs to prevent memory leaks in l2cap_ecred_connect
- https://git.kernel.org/stable/c/42b6a39f439b6f37cc2024d91ce547d83290ff78
- https://git.kernel.org/stable/c/9567d54e70ff58c2695c2cc2e53c86c67551d3e6
- https://git.kernel.org/stable/c/d3715b2333e9a21692ba16ef8645eda584a9515d
- https://git.kernel.org/stable/c/d588c183a971b85c775ad66da563ee6e8bc8158f
- https://git.kernel.org/stable/c/e9e55acee9b7a737ec7f5161b94a78932a5514c8
Modified: 2025-10-01
CVE-2022-49117
In the Linux kernel, the following vulnerability has been resolved: mips: ralink: fix a refcount leak in ill_acc_of_setup() of_node_put(np) needs to be called when pdev == NULL.
- https://git.kernel.org/stable/c/060a485df4ec1183d543317511cb4caa43468b5d
- https://git.kernel.org/stable/c/142ae7d4f21524acfe073e5a3da5667aa85eb970
- https://git.kernel.org/stable/c/4a0a1436053b17e50b7c88858fb0824326641793
- https://git.kernel.org/stable/c/5fb47ca3490813d3884d8ad0b2ce511aa3537551
- https://git.kernel.org/stable/c/8d7f7ef7980f287ace1c15f2ac03d6754e12f071
- https://git.kernel.org/stable/c/c74c755daed551b9aceb8388159180861474bdfe
Modified: 2025-10-15
CVE-2022-49118
In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Free irq vectors in order for v3 HW If the driver probe fails to request the channel IRQ or fatal IRQ, the driver will free the IRQ vectors before freeing the IRQs in free_irq(), and this will cause a kernel BUG like this: ------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:369! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: free_msi_irqs+0x118/0x13c pci_disable_msi+0xfc/0x120 pci_free_irq_vectors+0x24/0x3c hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw] local_pci_probe+0x44/0xb0 work_for_cpu_fn+0x20/0x34 process_one_work+0x1d0/0x340 worker_thread+0x2e0/0x460 kthread+0x180/0x190 ret_from_fork+0x10/0x20 ---[ end trace b88990335b610c11 ]--- So we use devm_add_action() to control the order in which we free the vectors.
- https://git.kernel.org/stable/c/224903cc60d045576393c3b16907742f23e6c740
- https://git.kernel.org/stable/c/554fb72ee34f4732c7f694f56c3c6e67790352a0
- https://git.kernel.org/stable/c/8b6eab9d683bae7f88dc894b8c851f866032301c
- https://git.kernel.org/stable/c/b4cc04fa8f1fc3816c8494d77abab3f72b9d2292
- https://git.kernel.org/stable/c/f05a0d8de2ea49af36821a20b0b501e20ced937e
Modified: 2025-10-01
CVE-2022-49119
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req() In pm8001_chip_fw_flash_update_build(), if pm8001_chip_fw_flash_update_build() fails, the struct fw_control_ex allocated must be freed.
- https://git.kernel.org/stable/c/a25ed5f21f94f9ae4bcc8dd747e978668890c921
- https://git.kernel.org/stable/c/d83574666bac4b1462e90df393fbed6c5f57d1a3
- https://git.kernel.org/stable/c/e5ecdb01952f230921aa8163d8d7f4c97c925ed8
- https://git.kernel.org/stable/c/f792a3629f4c4aa4c3703d66b43ce1edcc3ec09a
- https://git.kernel.org/stable/c/fe5b8ea5583b5c3f6f68e06acba50387edf3b5d5
Modified: 2025-09-23
CVE-2022-49120
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix task leak in pm8001_send_abort_all() In pm8001_send_abort_all(), make sure to free the allocated sas task if pm8001_tag_alloc() or pm8001_mpi_build_cmd() fail.
- https://git.kernel.org/stable/c/146cae06d2682d7563732544be334e8e6d3862b8
- https://git.kernel.org/stable/c/2051044d7901f1a9d7be95d0d32e53b88e9548f7
- https://git.kernel.org/stable/c/2290dcad6f65864dec518fb2d5fb45f67d684150
- https://git.kernel.org/stable/c/34c79d16ee69cb53288c202bb1ab0ba0130d9674
- https://git.kernel.org/stable/c/f90a74892f3acf0cdec5844e90fc8686ca13e7d7
Modified: 2025-09-23
CVE-2022-49121
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix tag leaks on error In pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(), pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing calls to pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd() fails. Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abort method fails, the tag allocated for the abort request task must be freed. Add the missing call to pm8001_tag_free().
- https://git.kernel.org/stable/c/43c617eefab7077d69f5989ad3e2a273da1d728b
- https://git.kernel.org/stable/c/4c8f04b1905cd4b776d0b720463c091545478ef7
- https://git.kernel.org/stable/c/9cc72bcc1c096ed42c91646f130d4b4191580a4c
- https://git.kernel.org/stable/c/a0bb65eadbf942024226241d9d99fed17168940b
- https://git.kernel.org/stable/c/bdc74815f1c39905054b7d47399e0260b201b14d
Modified: 2025-10-14
CVE-2022-49122
In the Linux kernel, the following vulnerability has been resolved: dm ioctl: prevent potential spectre v1 gadget It appears like cmd could be a Spectre v1 gadget as it's supplied by a user and used as an array index. Prevent the contents of kernel memory from being leaked to userspace via speculative execution by using array_index_nospec.
- https://git.kernel.org/stable/c/02cc46f397eb3691c56affbd5073e54f7a82ac32
- https://git.kernel.org/stable/c/0320bac5801b31407200227173205d017488f140
- https://git.kernel.org/stable/c/44e6cb3ab177faae840bb2c1ebda9a2539876184
- https://git.kernel.org/stable/c/58880025e3362024f6d8ea01cb0c7a5df6c84ba6
- https://git.kernel.org/stable/c/71c8df33fd777c7628f6fbc09b14e84806c55914
- https://git.kernel.org/stable/c/76c94651005f58885facf9c973007f5ea01ab01f
- https://git.kernel.org/stable/c/7ae2c5b89da3cfaf856df880af27d3bb32a74b3d
- https://git.kernel.org/stable/c/cd9c88da171a62c4b0f1c70e50c75845969fbc18
- https://git.kernel.org/stable/c/dd86064417de828ff2102ddc6049c829bf7585b4
Modified: 2025-10-01
CVE-2022-49123
In the Linux kernel, the following vulnerability has been resolved: ath11k: Fix frames flush failure caused by deadlock We are seeing below warnings: kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0 this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work has no chance to run in 5 seconds. By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing ATH11K_FLUSH_TIMEOUT to 50 we get below warnings: kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds. kernel: [ 120.763169] Not tainted 5.10.90 #12 kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0 kernel: [ 120.763201] Call Trace: kernel: [ 120.763214] __schedule+0x785/0x12fa kernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb kernel: [ 120.763242] schedule+0x7e/0xa1 kernel: [ 120.763253] schedule_timeout+0x98/0xfe kernel: [ 120.763266] ? run_local_timers+0x4a/0x4a kernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a] kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e kernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2 kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763802] ? genl_rcv+0x36/0x36 kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7 kernel: [ 120.763829] genl_rcv+0x28/0x36 kernel: [ 120.763840] netlink_unicast+0x179/0x24b kernel: [ 120.763854] netlink_sendmsg+0x393/0x401 kernel: [ 120.763872] sock_sendmsg+0x72/0x76 kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6 kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2 kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1 kernel: [ 120.763940] __sys_sendmsg+0x85/0xbf kernel: [ 120.763956] do_syscall_64+0x43/0x55 kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83 kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e kernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83 kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009 kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000 kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980 kernel: [ 120.764032] R13: 00007ffe604 ---truncated---
Modified: 2025-10-15
CVE-2022-49124
In the Linux kernel, the following vulnerability has been resolved: x86/mce: Work around an erratum on fast string copy instructions A rare kernel panic scenario can happen when the following conditions are met due to an erratum on fast string copy instructions: 1) An uncorrected error. 2) That error must be in first cache line of a page. 3) Kernel must execute page_copy from the page immediately before that page. The fast string copy instructions ("REP; MOVS*") could consume an uncorrectable memory error in the cache line _right after_ the desired region to copy and raise an MCE. Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast string copy and will avoid such spurious machine checks. However, that is less preferable due to the permanent performance impact. Considering memory poison is rare, it's desirable to keep fast string copy enabled until an MCE is seen. Intel has confirmed the following: 1. The CPU erratum of fast string copy only applies to Skylake, Cascade Lake and Cooper Lake generations. Directly return from the MCE handler: 2. Will result in complete execution of the "REP; MOVS*" with no data loss or corruption. 3. Will not result in another MCE firing on the next poisoned cache line due to "REP; MOVS*". 4. Will resume execution from a correct point in code. 5. Will result in the same instruction that triggered the MCE firing a second MCE immediately for any other software recoverable data fetch errors. 6. Is not safe without disabling the fast string copy, as the next fast string copy of the same buffer on the same CPU would result in a PANIC MCE. This should mitigate the erratum completely with the only caveat that the fast string copy is disabled on the affected hyper thread thus performance degradation. This is still better than the OS crashing on MCEs raised on an irrelevant process due to "REP; MOVS*' accesses in a kernel context, e.g., copy_page. Injected errors on 1st cache line of 8 anonymous pages of process 'proc1' and observed MCE consumption from 'proc2' with no panic (directly returned). Without the fix, the host panicked within a few minutes on a random 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]
Modified: 2025-10-01
CVE-2022-49125
In the Linux kernel, the following vulnerability has been resolved: drm/sprd: fix potential NULL dereference 'drm' could be null in sprd_drm_shutdown, and drm_warn maybe dereference it, remove this warning log. v1 -> v2: - Split checking platform_get_resource() return value to a separate patch - Use dev_warn() instead of removing the warning log
Modified: 2025-10-01
CVE-2022-49126
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix memory leaks Fix memory leaks related to operational reply queue's memory segments which are not getting freed while unloading the driver.
Modified: 2025-10-01
CVE-2022-49128
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: Add missing pm_runtime_put_sync pm_runtime_get_sync() will increase the rumtime PM counter even when it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Besides, a matching decrement is needed on the error handling path to keep the counter balanced.
Modified: 2025-03-25
CVE-2022-49129
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix crash when startup fails. If the nic fails to start, it is possible that the reset_work has already been scheduled. Ensure the work item is canceled so we do not have use-after-free crash in case cleanup is called before the work item is executed. This fixes crash on my x86_64 apu2 when mt7921k radio fails to work. Radio still fails, but OS does not crash.
Modified: 2025-10-01
CVE-2022-49130
In the Linux kernel, the following vulnerability has been resolved:
ath11k: mhi: use mhi_sync_power_up()
If amss.bin was missing ath11k would crash during 'rmmod ath11k_pci'. The
reason for that was that we were using mhi_async_power_up() which does not
check any errors. But mhi_sync_power_up() on the other hand does check for
errors so let's use that to fix the crash.
I was not able to find a reason why an async version was used.
ath11k_mhi_start() (which enables state ATH11K_MHI_POWER_ON) is called from
ath11k_hif_power_up(), which can sleep. So sync version should be safe to use
here.
[ 145.569731] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI
[ 145.569789] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 145.569843] CPU: 2 PID: 1628 Comm: rmmod Kdump: loaded Tainted: G W 5.16.0-wt-ath+ #567
[ 145.569898] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021
[ 145.569956] RIP: 0010:ath11k_hal_srng_access_begin+0xb5/0x2b0 [ath11k]
[ 145.570028] Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 ec 01 00 00 48 8b ab a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <0f> b6 14 02 48 89 e8 83 e0 07 83 c0 03 45 85 ed 75 48 38 d0 7c 08
[ 145.570089] RSP: 0018:ffffc900025d7ac0 EFLAGS: 00010246
[ 145.570144] RAX: dffffc0000000000 RBX: ffff88814fca2dd8 RCX: 1ffffffff50cb455
[ 145.570196] RDX: 0000000000000000 RSI: ffff88814fca2dd8 RDI: ffff88814fca2e80
[ 145.570252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffa8659497
[ 145.570329] R10: fffffbfff50cb292 R11: 0000000000000001 R12: ffff88814fca0000
[ 145.570410] R13: 0000000000000000 R14: ffff88814fca2798 R15: ffff88814fca2dd8
[ 145.570465] FS: 00007fa399988540(0000) GS:ffff888233e00000(0000) knlGS:0000000000000000
[ 145.570519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 145.570571] CR2: 00007fa399b51421 CR3: 0000000137898002 CR4: 00000000003706e0
[ 145.570623] Call Trace:
[ 145.570675]
- https://git.kernel.org/stable/c/20d01a11efde2e05e47d5c66101f5c26eaca68e2
- https://git.kernel.org/stable/c/339bd0b55ecdd0f7f341e9357c4cfde799de9418
- https://git.kernel.org/stable/c/3df6d74aedfdca919cca475d15dfdbc8b05c9e5d
- https://git.kernel.org/stable/c/3fd7d50384c3808b7f7fa135aa9bb5feb1cb9849
- https://git.kernel.org/stable/c/646d533af2911be1184eaee8c900b7eb8ecc4396
Modified: 2025-10-01
CVE-2022-49131
In the Linux kernel, the following vulnerability has been resolved: ath11k: fix kernel panic during unload/load ath11k modules Call netif_napi_del() from ath11k_ahb_free_ext_irq() to fix the following kernel panic when unload/load ath11k modules for few iterations. [ 971.201365] Unable to handle kernel paging request at virtual address 6d97a208 [ 971.204227] pgd = 594c2919 [ 971.211478] [6d97a208] *pgd=00000000 [ 971.214120] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 971.412024] CPU: 2 PID: 4435 Comm: insmod Not tainted 5.4.89 #0 [ 971.434256] Hardware name: Generic DT based system [ 971.440165] PC is at napi_by_id+0x10/0x40 [ 971.445019] LR is at netif_napi_add+0x160/0x1dc [ 971.743127] (napi_by_id) from [<807d89a0>] (netif_napi_add+0x160/0x1dc) [ 971.751295] (netif_napi_add) from [<7f1209ac>] (ath11k_ahb_config_irq+0xf8/0x414 [ath11k_ahb]) [ 971.759164] (ath11k_ahb_config_irq [ath11k_ahb]) from [<7f12135c>] (ath11k_ahb_probe+0x40c/0x51c [ath11k_ahb]) [ 971.768567] (ath11k_ahb_probe [ath11k_ahb]) from [<80666864>] (platform_drv_probe+0x48/0x94) [ 971.779670] (platform_drv_probe) from [<80664718>] (really_probe+0x1c8/0x450) [ 971.789389] (really_probe) from [<80664cc4>] (driver_probe_device+0x15c/0x1b8) [ 971.797547] (driver_probe_device) from [<80664f60>] (device_driver_attach+0x44/0x60) [ 971.805795] (device_driver_attach) from [<806650a0>] (__driver_attach+0x124/0x140) [ 971.814822] (__driver_attach) from [<80662adc>] (bus_for_each_dev+0x58/0xa4) [ 971.823328] (bus_for_each_dev) from [<80663a2c>] (bus_add_driver+0xf0/0x1e8) [ 971.831662] (bus_add_driver) from [<806658a4>] (driver_register+0xa8/0xf0) [ 971.839822] (driver_register) from [<8030269c>] (do_one_initcall+0x78/0x1ac) [ 971.847638] (do_one_initcall) from [<80392524>] (do_init_module+0x54/0x200) [ 971.855968] (do_init_module) from [<803945b0>] (load_module+0x1e30/0x1ffc) [ 971.864126] (load_module) from [<803948b0>] (sys_init_module+0x134/0x17c) [ 971.871852] (sys_init_module) from [<80301000>] (ret_fast_syscall+0x0/0x50) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00760-QCAHKSWPL_SILICONZ-1
- https://git.kernel.org/stable/c/22b59cb965f79ee1accf83172441c9ca0ecb632a
- https://git.kernel.org/stable/c/38e488db194dc16d2eb23c77c6a8c04ff583c40d
- https://git.kernel.org/stable/c/699e8c87e5c406af0f0606f40eeebd248c51b702
- https://git.kernel.org/stable/c/c4b7653af62a9a5efe2856183d1f987c5429758b
- https://git.kernel.org/stable/c/c6a815f5abdf324108799829dd19ea62fef4bf95
Modified: 2025-09-23
CVE-2022-49132
In the Linux kernel, the following vulnerability has been resolved:
ath11k: pci: fix crash on suspend if board file is not found
Mario reported that the kernel was crashing on suspend if ath11k was not able
to find a board file:
[ 473.693286] PM: Suspending system (s2idle)
[ 473.693291] printk: Suspending console(s) (use no_console_suspend to debug)
[ 474.407787] BUG: unable to handle page fault for address: 0000000000002070
[ 474.407791] #PF: supervisor read access in kernel mode
[ 474.407794] #PF: error_code(0x0000) - not-present page
[ 474.407798] PGD 0 P4D 0
[ 474.407801] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 474.407805] CPU: 2 PID: 2350 Comm: kworker/u32:14 Tainted: G W 5.16.0 #248
[...]
[ 474.407868] Call Trace:
[ 474.407870]
Modified: 2025-10-15
CVE-2022-49133
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: svm range restore work deadlock when process exit kfd_process_notifier_release flush svm_range_restore_work which calls svm_range_list_lock_and_flush_work to flush deferred_list work, but if deferred_list work mmput release the last user, it will call exit_mmap -> notifier_release, it is deadlock with below backtrace. Move flush svm_range_restore_work to kfd_process_wq_release to avoid deadlock. Then svm_range_restore_work take task->mm ref to avoid mm is gone while validating and mapping ranges to GPU. Workqueue: events svm_range_deferred_list_work [amdgpu] Call Trace: wait_for_completion+0x94/0x100 __flush_work+0x12a/0x1e0 __cancel_work_timer+0x10e/0x190 cancel_delayed_work_sync+0x13/0x20 kfd_process_notifier_release+0x98/0x2a0 [amdgpu] __mmu_notifier_release+0x74/0x1f0 exit_mmap+0x170/0x200 mmput+0x5d/0x130 svm_range_deferred_list_work+0x104/0x230 [amdgpu] process_one_work+0x220/0x3c0
Modified: 2025-10-01
CVE-2022-49134
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum: Guard against invalid local ports When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port. This can result in a NULL pointer dereference when trying access 'struct mlxsw_sp_port' fields which are not initialized for CPU port. Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port. Generalize the approach by moving the check to a common function and making use of it in all relevant places.
Modified: 2025-10-01
CVE-2022-49135
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak [why] Resource release is needed on the error handling path to prevent memory leak. [how] Fix this by adding kfree on the error handling path.
Modified: 2025-10-01
CVE-2022-49137
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code.
- https://git.kernel.org/stable/c/3edd8646cb7c11b57c90e026bda6f21076223f5b
- https://git.kernel.org/stable/c/4009f104b02b223d1a11d74b36b1cc083bc37028
- https://git.kernel.org/stable/c/72d77ddb2224ebc00648f4f78f8a9a259dccbdf7
- https://git.kernel.org/stable/c/927beb05aaa429c883cc0ec6adc48964b187e291
- https://git.kernel.org/stable/c/b6d1f7d97c81ebaf2cda9c4c943ee2e484fffdcf
- https://git.kernel.org/stable/c/bc2d5c0775c839e2b072884f4ee6a93ba410f107
- https://git.kernel.org/stable/c/dfced44f122c500004a48ecc8db516bb6a295a1b
Modified: 2025-09-23
CVE-2022-49138
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Ignore multiple conn complete events When one of the three connection complete events is received multiple times for the same handle, the device is registered multiple times which leads to memory corruptions. Therefore, consequent events for a single connection are ignored. The conn->state can hold different values, therefore HCI_CONN_HANDLE_UNSET is introduced to identify new connections. To make sure the events do not contain this or another invalid handle HCI_CONN_HANDLE_MAX and checks are introduced. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497
Modified: 2025-10-01
CVE-2022-49139
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL.
- https://git.kernel.org/stable/c/0f9db1209f59844839175b5b907d3778cafde93d
- https://git.kernel.org/stable/c/1c1291a84e94f6501644634c97544bb8291e9a1a
- https://git.kernel.org/stable/c/3afee2118132e93e5f6fa636dfde86201a860ab3
- https://git.kernel.org/stable/c/c1aa0dd52db4ce888be0bd820c3fa918d350ca0b
- https://git.kernel.org/stable/c/f61c23e73dc653b957781066abfa8105c3fa3f5b
Modified: 2025-10-15
CVE-2022-49142
In the Linux kernel, the following vulnerability has been resolved:
net: preserve skb_end_offset() in skb_unclone_keeptruesize()
syzbot found another way to trigger the infamous WARN_ON_ONCE(delta < len)
in skb_try_coalesce() [1]
I was able to root cause the issue to kfence.
When kfence is in action, the following assertion is no longer true:
int size = xxxx;
void *ptr1 = kmalloc(size, gfp);
void *ptr2 = kmalloc(size, gfp);
if (ptr1 && ptr2)
ASSERT(ksize(ptr1) == ksize(ptr2));
We attempted to fix these issues in the blamed commits, but forgot
that TCP was possibly shifting data after skb_unclone_keeptruesize()
has been used, notably from tcp_retrans_try_collapse().
So we not only need to keep same skb->truesize value,
we also need to make sure TCP wont fill new tailroom
that pskb_expand_head() was able to get from a
addr = kmalloc(...) followed by ksize(addr)
Split skb_unclone_keeptruesize() into two parts:
1) Inline skb_unclone_keeptruesize() for the common case,
when skb is not cloned.
2) Out of line __skb_unclone_keeptruesize() for the 'slow path'.
WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295
Modules linked in:
CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295
Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 fa
RSP: 0018:ffffc900063af268 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000
RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003
RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000
R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8
R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155
FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-10-01
CVE-2022-49144
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix memory leak of uid in files registration When there are no files for __io_sqe_files_scm() to process in the range, it'll free everything and return. However, it forgets to put uid.
- https://git.kernel.org/stable/c/0853bd6885c2f293d88aaa7f7f1702c959b31680
- https://git.kernel.org/stable/c/7fa8b228c3f30060b9f4b24bb9aaaf41b0ae83fe
- https://git.kernel.org/stable/c/b27de7011cb3ba14b047be2cee0ed8278368665b
- https://git.kernel.org/stable/c/c86d18f4aa93e0e66cda0e55827cd03eea6bc5f8
- https://git.kernel.org/stable/c/d6d7a517e81accf6ed22d55684baea763d2dbe43
Modified: 2025-09-23
CVE-2022-49145
In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Avoid out of bounds access when parsing _CPC data If the NumEntries field in the _CPC return package is less than 2, do not attempt to access the "Revision" element of that package, because it may not be present then. BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/
- https://git.kernel.org/stable/c/28d5387c1994f5e1e0d41b30a1f3dd6e1f609252
- https://git.kernel.org/stable/c/40d8abf364bcab23bc715a9221a3c8623956257b
- https://git.kernel.org/stable/c/97b5593fd1b182b3fdb180b6bbe64ec09669988b
- https://git.kernel.org/stable/c/b3f15609ffa521de12244cd6af24002030dda3f5
- https://git.kernel.org/stable/c/b80b19b32a432c9eee1cd200ef7aaddf608f54d1
- https://git.kernel.org/stable/c/cb249f8c00f40dba83b7da8207ac14ca46e9ec9e
- https://git.kernel.org/stable/c/d208ea44e25b31db5a4d5e8c31df51787a3e9303
- https://git.kernel.org/stable/c/d7339f2a3938fb56b5f28d53f5345900b5fa0e74
- https://git.kernel.org/stable/c/e5b681822cac1f8093759b02e16c06b2c64b6788
Modified: 2025-10-15
CVE-2022-49146
In the Linux kernel, the following vulnerability has been resolved:
virtio: use virtio_device_ready() in virtio_device_restore()
After waking up a suspended VM, the kernel prints the following trace
for virtio drivers which do not directly call virtio_device_ready() in
the .restore:
PM: suspend exit
irq 22: nobody cared (try booting with the "irqpoll" option)
Call Trace:
Modified: 2025-10-15
CVE-2022-49147
In the Linux kernel, the following vulnerability has been resolved: block: Fix the maximum minor value is blk_alloc_ext_minor() ida_alloc_range(..., min, max, ...) returns values from min to max, inclusive. So, NR_EXT_DEVT is a valid idx returned by blk_alloc_ext_minor(). This is an issue because in device_add_disk(), this value is used in: ddev->devt = MKDEV(disk->major, disk->first_minor); and NR_EXT_DEVT is '(1 << MINORBITS)'. So, should 'disk->first_minor' be NR_EXT_DEVT, it would overflow.
Modified: 2025-10-01
CVE-2022-49148
In the Linux kernel, the following vulnerability has been resolved: watch_queue: Free the page array when watch_queue is dismantled Commit 7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the watch_queue is torn down") took care of the bitmap, but not the page array. BUG: memory leak unreferenced object 0xffff88810d9bc140 (size 32): comm "syz-executor335", pid 3603, jiffies 4294946994 (age 12.840s) hex dump (first 32 bytes): 40 a7 40 04 00 ea ff ff 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: kmalloc_array include/linux/slab.h:621 [inline] kcalloc include/linux/slab.h:652 [inline] watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251 pipe_ioctl+0x82/0x140 fs/pipe.c:632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
- https://git.kernel.org/stable/c/375cd2536494cfbcdda84ae8b3e35bf19d0250b9
- https://git.kernel.org/stable/c/3963a5d1ff75585bddf0c3a918566a6be09d7520
- https://git.kernel.org/stable/c/4913daecd04addb41bc96a9175a885e1c19862a8
- https://git.kernel.org/stable/c/7169f60110915c8b53bffd43741fa020a75eb87a
- https://git.kernel.org/stable/c/b490207017ba237d97b735b2aa66dc241ccd18f5
Modified: 2025-09-23
CVE-2022-49149
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call timer start racing with call destruction The rxrpc_call struct has a timer used to handle various timed events relating to a call. This timer can get started from the packet input routines that are run in softirq mode with just the RCU read lock held. Unfortunately, because only the RCU read lock is held - and neither ref or other lock is taken - the call can start getting destroyed at the same time a packet comes in addressed to that call. This causes the timer - which was already stopped - to get restarted. Later, the timer dispatch code may then oops if the timer got deallocated first. Fix this by trying to take a ref on the rxrpc_call struct and, if successful, passing that ref along to the timer. If the timer was already running, the ref is discarded. The timer completion routine can then pass the ref along to the call's work item when it queues it. If the timer or work item where already queued/running, the extra ref is discarded.
- https://git.kernel.org/stable/c/051360e51341cd17738d82c15a8226010c7cb7f6
- https://git.kernel.org/stable/c/4a7f62f91933c8ae5308f9127fd8ea48188b6bc3
- https://git.kernel.org/stable/c/54df5a37f1d951ed27fd47bf9b15a42279582110
- https://git.kernel.org/stable/c/5e3c11144e557a9dbf9a2f6abe444689ef9d8aae
- https://git.kernel.org/stable/c/8cbf4ae7a2833767d63114573e5f9a45740cc975
Modified: 2025-10-15
CVE-2022-49151
In the Linux kernel, the following vulnerability has been resolved:
can: mcba_usb: properly check endpoint type
Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. We should check that in endpoint is actually present to
prevent this warning.
Found pipes are now saved to struct mcba_priv and code uses them
directly instead of making pipes in place.
Fail log:
| usb 5-1: BOGUS urb xfer, pipe 3 != type 1
| WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
| Modules linked in:
| CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0
| Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| Workqueue: usb_hub_wq hub_event
| RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
| ...
| Call Trace:
|
- https://git.kernel.org/stable/c/136bed0bfd3bc9c95c88aafff2d22ecb3a919f23
- https://git.kernel.org/stable/c/5598442edc29e8f6f2380e4b471dc1a3fcd80508
- https://git.kernel.org/stable/c/88272b4a37913bdf6f339162a7920bd8e9b49de2
- https://git.kernel.org/stable/c/b48d1bb3f1ca337ad653022aefb5a40a47dfe5cd
- https://git.kernel.org/stable/c/cbd110b8dd7ad763bf413f71c0484116ae9302d4
- https://git.kernel.org/stable/c/ef0acc514123140157b19a9ff2e2de5d91d612bc
- https://git.kernel.org/stable/c/f2ec3cd0f34f8c3f94bc21fbba14868301c9c49d
- https://git.kernel.org/stable/c/fa9c1f14002dc0d5293e16a2007bd89b6e79207b
Modified: 2025-06-19
CVE-2022-49152
In the Linux kernel, the following vulnerability has been resolved: XArray: Fix xas_create_range() when multi-order entry present If there is already an entry present that is of order >= XA_CHUNK_SHIFT when we call xas_create_range(), xas_create_range() will misinterpret that entry as a node and dereference xa_node->parent, generally leading to a crash that looks something like this: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0 RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline] RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725 It's deterministically reproducable once you know what the problem is, but producing it in a live kernel requires khugepaged to hit a race. While the problem has been present since xas_create_range() was introduced, I'm not aware of a way to hit it before the page cache was converted to use multi-index entries.
Modified: 2025-10-01
CVE-2022-49153
In the Linux kernel, the following vulnerability has been resolved:
wireguard: socket: free skb in send6 when ipv6 is disabled
I got a memory leak report:
unreferenced object 0xffff8881191fc040 (size 232):
comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/096f9d35cac0a0c95ffafc00db84786b665a4837
- https://git.kernel.org/stable/c/0b19bcb753dbfb74710d12bb2761ec5ed706c726
- https://git.kernel.org/stable/c/402991a9771587acc2947cf6c4d689c5397f2258
- https://git.kernel.org/stable/c/bbbf962d9460194993ee1943a793a0a0af4a7fbf
- https://git.kernel.org/stable/c/ebcc492f4ba14bae54b898f1016a37b4282558d1
Modified: 2025-09-23
CVE-2022-49154
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: fix panic on out-of-bounds guest IRQ As guest_irq is coming from KVM_IRQFD API call, it may trigger crash in svm_update_pi_irte() due to out-of-bounds: crash> bt PID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8" #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397 #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9 #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51 #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace [exception RIP: svm_update_pi_irte+227] RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086 RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001 RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8 RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200 R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001 R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm] #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm] #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm] RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020 RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0 R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0 R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b Vmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on out-of-bounds guest IRQ), so we can just copy source from that to fix this.
- https://git.kernel.org/stable/c/0fb470eb48892e131d10aa3be6915239e65758f3
- https://git.kernel.org/stable/c/3fa2d747960521a646fc1aad7aea82e95e139a68
- https://git.kernel.org/stable/c/a6ffdebfb6a9c2ffeed902b544b96fe67498210e
- https://git.kernel.org/stable/c/a80ced6ea514000d34bf1239d47553de0d1ee89e
- https://git.kernel.org/stable/c/e4d153d53d9648513481eb4ef8c212e7f1f8173d
Modified: 2025-10-01
CVE-2022-49155
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair() [ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020 [ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1 [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018 [ 12.356356] Call Trace: [ 12.358821] dump_stack_lvl+0x34/0x44 [ 12.362514] check_preemption_disabled+0xd9/0xe0 [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40 [ 12.384284] local_pci_probe+0x42/0x80 [ 12.390162] ? pci_match_device+0xd7/0x110 [ 12.396366] pci_device_probe+0xfd/0x1b0 [ 12.402372] really_probe+0x1e7/0x3e0 [ 12.408114] __driver_probe_device+0xfe/0x180 [ 12.414544] driver_probe_device+0x1e/0x90 [ 12.420685] __driver_attach+0xc0/0x1c0 [ 12.426536] ? __device_attach_driver+0xe0/0xe0 [ 12.433061] ? __device_attach_driver+0xe0/0xe0 [ 12.439538] bus_for_each_dev+0x78/0xc0 [ 12.445294] bus_add_driver+0x12b/0x1e0 [ 12.451021] driver_register+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx] [ 12.468776] do_one_initcall+0x44/0x200 [ 12.474401] ? load_module+0xad3/0xba0 [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410 [ 12.486268] do_init_module+0x5c/0x280 [ 12.491730] __do_sys_init_module+0x12e/0x1b0 [ 12.497785] do_syscall_64+0x3b/0x90 [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e
- https://git.kernel.org/stable/c/1ab81d82fb1db7ec4be4b0d04563513e6d4bcdd5
- https://git.kernel.org/stable/c/43195a0c620761fbb88db04e2475313855b948a4
- https://git.kernel.org/stable/c/8077a7162bc3cf658dd9ff112bc77716c08458c5
- https://git.kernel.org/stable/c/9c33d49ab9f3d8bd7512b3070cd2f07c4a8849d5
- https://git.kernel.org/stable/c/a60447e7d451df42c7bde43af53b34f10f34f469
- https://git.kernel.org/stable/c/a669a22aef0ceff706b885370af74b5a60a8ac85
- https://git.kernel.org/stable/c/f68776f28d9134fa65056e7e63bfc734049730b7
- https://git.kernel.org/stable/c/f97316dd393bc8df1cc2af6295a97b876eecf252
Modified: 2025-10-15
CVE-2022-49156
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix scheduling while atomic
The driver makes a call into midlayer (fc_remote_port_delete) which can put
the thread to sleep. The thread that originates the call is in interrupt
context. The combination of the two trigger a crash. Schedule the call in
non-interrupt context where it is more safe.
kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000
kernel: Call Trace:
kernel:
- https://git.kernel.org/stable/c/78225d6a2a4ffdb2250ce2b7691a9e68a3f86912
- https://git.kernel.org/stable/c/78612f2fe8e26637476d756a44f0f05cca0d97de
- https://git.kernel.org/stable/c/7fef50214dd04427233a2e66cd624d468e67aecb
- https://git.kernel.org/stable/c/826a9d4a00d1424afa961504aec6298ee92d5053
- https://git.kernel.org/stable/c/afd438ff874ca40b74321b3fa19bd61adfd7ca0c
Modified: 2025-10-15
CVE-2022-49157
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix premature hw access after PCI error After a recoverable PCI error has been detected and recovered, qla driver needs to check to see if the error condition still persist and/or wait for the OS to give the resume signal. Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440 qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: Call Trace: Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80 Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80 Sep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90 Sep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0 Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240 Sep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0 Sep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360 .. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI disconnect. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to capture FW dump Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0, waited 5221 msecs Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio enabled returning. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5 mb[0-3]=[0xffff 0xffff 0xffff 0xffff]
Modified: 2025-09-23
CVE-2022-49158
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix warning message due to adisc being flushed Fix warning message due to adisc being flushed. Linux kernel triggered a warning message where a different error code type is not matching up with the expected type. Add additional translation of one error code type to another. WARNING: CPU: 2 PID: 1131623 at drivers/scsi/qla2xxx/qla_init.c:498 qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx] CPU: 2 PID: 1131623 Comm: drmgr Not tainted 5.13.0-rc1-autotest #1 .. GPR28: c000000aaa9c8890 c0080000079ab678 c00000140a104800 c00000002bd19000 NIP [c00800000790857c] qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx] LR [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] Call Trace: [c00000001cdc3620] [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] (unreliable) [c00000001cdc3710] [c0080000078f3080] __qla2x00_abort_all_cmds+0x1b8/0x580 [qla2xxx] [c00000001cdc3840] [c0080000078f589c] qla2x00_abort_all_cmds+0x34/0xd0 [qla2xxx] [c00000001cdc3880] [c0080000079153d8] qla2x00_abort_isp_cleanup+0x3f0/0x570 [qla2xxx] [c00000001cdc3920] [c0080000078fb7e8] qla2x00_remove_one+0x3d0/0x480 [qla2xxx] [c00000001cdc39b0] [c00000000071c274] pci_device_remove+0x64/0x120 [c00000001cdc39f0] [c0000000007fb818] device_release_driver_internal+0x168/0x2a0 [c00000001cdc3a30] [c00000000070e304] pci_stop_bus_device+0xb4/0x100 [c00000001cdc3a70] [c00000000070e4f0] pci_stop_and_remove_bus_device+0x20/0x40 [c00000001cdc3aa0] [c000000000073940] pci_hp_remove_devices+0x90/0x130 [c00000001cdc3b30] [c0080000070704d0] disable_slot+0x38/0x90 [rpaphp] [ c00000001cdc3b60] [c00000000073eb4c] power_write_file+0xcc/0x180 [c00000001cdc3be0] [c0000000007354bc] pci_slot_attr_store+0x3c/0x60 [c00000001cdc3c00] [c00000000055f820] sysfs_kf_write+0x60/0x80 [c00000001cdc3c20] [c00000000055df10] kernfs_fop_write_iter+0x1a0/0x290 [c00000001cdc3c70] [c000000000447c4c] new_sync_write+0x14c/0x1d0 [c00000001cdc3d10] [c00000000044b134] vfs_write+0x224/0x330 [c00000001cdc3d60] [c00000000044b3f4] ksys_write+0x74/0x130 [c00000001cdc3db0] [c00000000002df70] system_call_exception+0x150/0x2d0 [c00000001cdc3e10] [c00000000000d45c] system_call_common+0xec/0x278
Modified: 2025-09-23
CVE-2022-49159
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Implement ref count for SRB The timeout handler and the done function are racing. When qla2x00_async_iocb_timeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xx_async_gpsc_sp_done() releases the SRB unconditionally. When scheduling back to qla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed sp->qpair pointer: qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx] Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks. When we are able to cancel a timer (del_timer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one. If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling kref_put().
Modified: 2025-09-23
CVE-2022-49160
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash during module load unload test During purex packet handling the driver was incorrectly freeing a pre-allocated structure. Fix this by skipping that entry. System crashed with the following stack during a module unload test. Call Trace: sbitmap_init_node+0x7f/0x1e0 sbitmap_queue_init_node+0x24/0x150 blk_mq_init_bitmaps+0x3d/0xa0 blk_mq_init_tags+0x68/0x90 blk_mq_alloc_map_and_rqs+0x44/0x120 blk_mq_alloc_set_map_and_rqs+0x63/0x150 blk_mq_alloc_tag_set+0x11b/0x230 scsi_add_host_with_dma.cold+0x3f/0x245 qla2x00_probe_one+0xd5a/0x1b80 [qla2xxx] Call Trace with slub_debug and debug kernel: kasan_report_invalid_free+0x50/0x80 __kasan_slab_free+0x137/0x150 slab_free_freelist_hook+0xc6/0x190 kfree+0xe8/0x2e0 qla2x00_free_device+0x3bb/0x5d0 [qla2xxx] qla2x00_remove_one+0x668/0xcf0 [qla2xxx]
Modified: 2025-09-23
CVE-2022-49161
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too.
Modified: 2025-10-15
CVE-2022-49162
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: sm712fb: Fix crash in smtcfb_write() When the sm712fb driver writes three bytes to the framebuffer, the driver will crash: BUG: unable to handle page fault for address: ffffc90001ffffff RIP: 0010:smtcfb_write+0x454/0x5b0 Call Trace: vfs_write+0x291/0xd60 ? do_sys_openat2+0x27d/0x350 ? __fget_light+0x54/0x340 ksys_write+0xce/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Fix it by removing the open-coded endianness fixup-code.
- https://git.kernel.org/stable/c/0ec746674296c94137f074309c26d17e644c0498
- https://git.kernel.org/stable/c/1aea36a62f0a0ad67eccc945bac0bd6422ef720f
- https://git.kernel.org/stable/c/3b36c05f68ba32d0dfb63abc9016d6fe9117829f
- https://git.kernel.org/stable/c/4f01d09b2bbfbcb47b3eb305560a7f4857a32260
- https://git.kernel.org/stable/c/809b8cde86320698661eec677222bc5c5df76176
- https://git.kernel.org/stable/c/aeb635b49530b7d19e140949753409f759ba99be
- https://git.kernel.org/stable/c/b1c28577529cdfad40c8242673285f1e1e4c314e
- https://git.kernel.org/stable/c/eae90015d10f0c9a47fc4adccba4cd79dce664e4
- https://git.kernel.org/stable/c/fb791514acf9070225eed46e1ccbb0aa7aae5da5
Modified: 2025-09-23
CVE-2022-49163
In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: fix a bug of accessing array out of bounds When error occurs in parsing jpeg, the slot isn't acquired yet, it may be the default value MXC_MAX_SLOTS. If the driver access the slot using the incorrect slot number, it will access array out of bounds. The result is the driver will change num_domains, which follows slot_data in struct mxc_jpeg_dev. Then the driver won't detach the pm domain at rmmod, which will lead to kernel panic when trying to insmod again.
Modified: 2025-09-23
CVE-2022-49164
In the Linux kernel, the following vulnerability has been resolved: powerpc/tm: Fix more userspace r13 corruption Commit cf13435b730a ("powerpc/tm: Fix userspace r13 corruption") fixes a problem in treclaim where a SLB miss can occur on the thread_struct->ckpt_regs while SCRATCH0 is live with the saved user r13 value, clobbering it with the kernel r13 and ultimately resulting in kernel r13 being stored in ckpt_regs. There is an equivalent problem in trechkpt where the user r13 value is loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss could occur on ckpt_regs accesses after that, which will result in r13 being clobbered with a kernel value and that will get recheckpointed and then restored to user registers. The same memory page is accessed right before this critical window where a SLB miss could cause corruption, so hitting the bug requires the SLB entry be removed within a small window of instructions, which is possible if a SLB related MCE hits there. PAPR also permits the hypervisor to discard this SLB entry (because slb_shadow->persistent is only set to SLB_NUM_BOLTED) although it's not known whether any implementations would do this (KVM does not). So this is an extremely unlikely bug, only found by inspection. Fix this by also storing user r13 in a temporary location on the kernel stack and don't change the r13 register from kernel r13 until the RI=0 critical section that does not fault. The SCRATCH0 change is not strictly part of the fix, it's only used in the RI=0 section so it does not have the same problem as the previous SCRATCH0 bug.
Modified: 2025-09-23
CVE-2022-49165
In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Prevent decoding NV12M jpegs into single-planar buffers If the application queues an NV12M jpeg as output buffer, but then queues a single planar capture buffer, the kernel will crash with "Unable to handle kernel NULL pointer dereference" in mxc_jpeg_addrs, prevent this by finishing the job with error.
Modified: 2025-10-15
CVE-2022-49166
In the Linux kernel, the following vulnerability has been resolved: ntfs: add sanity check on allocation size ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation size. It triggers one BUG in the __ntfs_malloc function. Fix this by adding sanity check on ni->attr_list_size.
- https://git.kernel.org/stable/c/07793d2e55563124108762f4e5f811db92ffe02f
- https://git.kernel.org/stable/c/115fae2c1566eacc5ad2055f72521354612e72c3
- https://git.kernel.org/stable/c/21d490232f323ed4053eb9924615e6fea291f154
- https://git.kernel.org/stable/c/24ab2d4ef52c2dbb62a60844b87fc8872383407a
- https://git.kernel.org/stable/c/714fbf2647b1a33d914edd695d4da92029c7e7c0
- https://git.kernel.org/stable/c/b230f2d9441a34c7f483d39ab78519bcf73cc2e0
- https://git.kernel.org/stable/c/bd8d7daa0e53b184a2f3c6e0d47330780d0a0650
- https://git.kernel.org/stable/c/c641087d381a08363e5f14179bc6b0a23eca7c47
- https://git.kernel.org/stable/c/fe41ad8be036a3de3e4bdde709551aeb4de2fe7d
Modified: 2025-10-21
CVE-2022-49167
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not double complete bio on errors during compressed reads I hit some weird panics while fixing up the error handling from btrfs_lookup_bio_sums(). Turns out the compression path will complete the bio we use if we set up any of the compression bios and then return an error, and then btrfs_submit_data_bio() will also call bio_endio() on the bio. Fix this by making btrfs_submit_compressed_read() responsible for calling bio_endio() on the bio if there are any errors. Currently it was only doing it if we created the compression bios, otherwise it was depending on btrfs_submit_data_bio() to do the right thing. This creates the above problem, so fix up btrfs_submit_compressed_read() to always call bio_endio() in case of an error, and then simply return from btrfs_submit_data_bio() if we had to call btrfs_submit_compressed_read().
Modified: 2026-01-21
CVE-2022-49168
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not clean up repair bio if submit fails The submit helper will always run bio_endio() on the bio if it fails to submit, so cleaning up the bio just leads to a variety of use-after-free and NULL pointer dereference bugs because we race with the endio function that is cleaning up the bio. Instead just return BLK_STS_OK as the repair function has to continue to process the rest of the pages, and the endio for the repair bio will do the appropriate cleanup for the page that it was given.
- https://git.kernel.org/stable/c/7170875083254b51fcc5d67f96640977083f481e
- https://git.kernel.org/stable/c/8cbc3001a3264d998d6b6db3e23f935c158abd4d
- https://git.kernel.org/stable/c/d1cb11fb45ebbb1e7dfe5e9038b32ea72c184b14
- https://git.kernel.org/stable/c/e76c78c48902dae6fa612749f59162bca0a79e0b
- https://git.kernel.org/stable/c/e7e1d15d2bd8c373cf621614ddd17971a2132713
Modified: 2025-10-22
CVE-2022-49169
In the Linux kernel, the following vulnerability has been resolved:
f2fs: use spin_lock to avoid hang
[14696.634553] task:cat state:D stack: 0 pid:1613738 ppid:1613735 flags:0x00000004
[14696.638285] Call Trace:
[14696.639038]
Modified: 2025-09-23
CVE-2022-49170
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on curseg->alloc_type
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=215657
- Overview
UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 when mount and operate a corrupted image
- Reproduce
tested on kernel 5.17-rc4, 5.17-rc6
1. mkdir test_crash
2. cd test_crash
3. unzip tmp2.zip
4. mkdir mnt
5. ./single_test.sh f2fs 2
- Kernel dump
[ 46.434454] loop0: detected capacity change from 0 to 131072
[ 46.529839] F2FS-fs (loop0): Mounted with checkpoint version = 7548c2d9
[ 46.738319] ================================================================================
[ 46.738412] UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2
[ 46.738475] index 231 is out of range for type 'unsigned int [2]'
[ 46.738539] CPU: 2 PID: 939 Comm: umount Not tainted 5.17.0-rc6 #1
[ 46.738547] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[ 46.738551] Call Trace:
[ 46.738556]
- https://git.kernel.org/stable/c/0748a0f7dcb9d9dddc80302d73ebcecef6782ef0
- https://git.kernel.org/stable/c/498b7088db71f9707359448cd6800bbb1882f4c3
- https://git.kernel.org/stable/c/c12765e3f129b144421c80d3383df885f85ee290
- https://git.kernel.org/stable/c/f41ee8b91c00770d718be2ff4852a80017ae9ab3
- https://git.kernel.org/stable/c/f68caedf264a95c0b02dfd0d9f92ac2637d5848a
Modified: 2025-09-23
CVE-2022-49171
In the Linux kernel, the following vulnerability has been resolved: ext4: don't BUG if someone dirty pages without asking ext4 first [un]pin_user_pages_remote is dirtying pages without properly warning the file system in advance. A related race was noted by Jan Kara in 2018[1]; however, more recently instead of it being a very hard-to-hit race, it could be reliably triggered by process_vm_writev(2) which was discovered by Syzbot[2]. This is technically a bug in mm/gup.c, but arguably ext4 is fragile in that if some other kernel subsystem dirty pages without properly notifying the file system using page_mkwrite(), ext4 will BUG, while other file systems will not BUG (although data will still be lost). So instead of crashing with a BUG, issue a warning (since there may be potential data loss) and just mark the page as clean to avoid unprivileged denial of service attacks until the problem can be properly fixed. More discussion and background can be found in the thread starting at [2]. [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com
- https://git.kernel.org/stable/c/0d3a6926f7e8be3c897fa46216ce13b119a9f56a
- https://git.kernel.org/stable/c/330d0e44fc5a47c27df958ecdd4693a3cb1d8b81
- https://git.kernel.org/stable/c/343117559ef41e992e326f7a92da1a8f254dfa8c
- https://git.kernel.org/stable/c/5a016c053f426a73752c3b41b60b497b58694d48
- https://git.kernel.org/stable/c/5db60e76edf5680ff1f3a7221036fc44b308f146
- https://git.kernel.org/stable/c/677c9d30e8487bee6c8e3b034070319d98f6e203
- https://git.kernel.org/stable/c/a0856764dc1276ad2dc7891288c2e9246bf11a37
- https://git.kernel.org/stable/c/cc5095747edfb054ca2068d01af20be3fcc3634f
- https://git.kernel.org/stable/c/d666dfaa571465a19f014534a214c255ea33f301
Modified: 2025-09-23
CVE-2022-49172
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix non-access data TLB cache flush faults When a page is not present, we get non-access data TLB faults from the fdc and fic instructions in flush_user_dcache_range_asm and flush_user_icache_range_asm. When these occur, the cache line is not invalidated and potentially we get memory corruption. The problem was hidden by the nullification of the flush instructions. These faults also affect performance. With pa8800/pa8900 processors, there will be 32 faults per 4 KB page since the cache line is 128 bytes. There will be more faults with earlier processors. The problem is fixed by using flush_cache_pages(). It does the flush using a tmp alias mapping. The flush_cache_pages() call in flush_cache_range() flushed too large a range. V2: Remove unnecessary preempt_disable() and preempt_enable() calls.
Modified: 2025-10-22
CVE-2022-49173
In the Linux kernel, the following vulnerability has been resolved: spi: fsi: Implement a timeout for polling status The data transfer routines must poll the status register to determine when more data can be shifted in or out. If the hardware gets into a bad state, these polling loops may never exit. Prevent this by returning an error if a timeout is exceeded.
Modified: 2025-10-22
CVE-2022-49174
In the Linux kernel, the following vulnerability has been resolved: ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit In case of flex_bg feature (which is by default enabled), extents for any given inode might span across blocks from two different block group. ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the starting block group, but it fails to read it again when the extent length boundary overflows to another block group. Then in this below loop it accesses memory beyond the block group bitmap buffer_head and results into a data abort. for (i = 0; i < clen; i++) if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state) already++; This patch adds this functionality for checking block group boundary in ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different block group. w/o this patch, I was easily able to hit a data access abort using Power platform. <...> [ 74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters [ 74.533214] EXT4-fs (loop3): shut down requested (2) [ 74.536705] Aborting journal on device loop3-8. [ 74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000 [ 74.703727] Faulting instruction address: 0xc0000000007bffb8 cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060] pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0 lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0 sp: c000000015db7300 msr: 800000000280b033 dar: c00000005e980000 dsisr: 40000000 current = 0xc000000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> enter ? for help [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410 [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000 [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0 [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0 [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0 [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10 [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350 [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70 [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550 [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0 [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250
- https://git.kernel.org/stable/c/6a6beb074186a0452368a023a261c7d0eaebe838
- https://git.kernel.org/stable/c/803fb0e8240cc16585a5c9df76add1dfaa781773
- https://git.kernel.org/stable/c/b07eedd0222e9548ffc568ec429bb1f61d21a39c
- https://git.kernel.org/stable/c/bfdc502a4a4c058bf4cbb1df0c297761d528f54d
- https://git.kernel.org/stable/c/cd6d719534af993210306f8a13f9cb3e615f7c8d
Modified: 2025-10-22
CVE-2022-49175
In the Linux kernel, the following vulnerability has been resolved:
PM: core: keep irq flags in device_pm_check_callbacks()
The function device_pm_check_callbacks() can be called under the spin
lock (in the reported case it happens from genpd_add_device() ->
dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.
However this function uncoditionally uses spin_lock_irq() /
spin_unlock_irq(), thus not preserving the CPU flags. Use the
irqsave/irqrestore instead.
The backtrace for the reference:
[ 2.752010] ------------[ cut here ]------------
[ 2.756769] raw_local_irq_restore() called with IRQs enabled
[ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50
[ 2.772338] Modules linked in:
[ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684
[ 2.781384] Freeing initrd memory: 46024K
[ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50
[ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50
[ 2.785846] sp : ffff80000805b7d0
[ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002
[ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800
[ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00
[ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff
[ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7
[ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8
[ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0
[ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0
[ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000
[ 2.889774] Call trace:
[ 2.892290] warn_bogus_irq_restore+0x34/0x50
[ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0
[ 2.901690] genpd_unlock_spin+0x20/0x30
[ 2.905724] genpd_add_device+0x100/0x2d0
[ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c
[ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190
[ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0
[ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30
[ 2.929102] psci_dt_attach_cpu+0x24/0x90
[ 2.933230] psci_cpuidle_probe+0x2d4/0x46c
[ 2.937534] platform_probe+0x68/0xe0
[ 2.941304] really_probe.part.0+0x9c/0x2fc
[ 2.945605] __driver_probe_device+0x98/0x144
[ 2.950085] driver_probe_device+0x44/0x15c
[ 2.954385] __device_attach_driver+0xb8/0x120
[ 2.958950] bus_for_each_drv+0x78/0xd0
[ 2.962896] __device_attach+0xd8/0x180
[ 2.966843] device_initial_probe+0x14/0x20
[ 2.971144] bus_probe_device+0x9c/0xa4
[ 2.975092] device_add+0x380/0x88c
[ 2.978679] platform_device_add+0x114/0x234
[ 2.983067] platform_device_register_full+0x100/0x190
[ 2.988344] psci_idle_init+0x6c/0xb0
[ 2.992113] do_one_initcall+0x74/0x3a0
[ 2.996060] kernel_init_freeable+0x2fc/0x384
[ 3.000543] kernel_init+0x28/0x130
[ 3.004132] ret_from_fork+0x10/0x20
[ 3.007817] irq event stamp: 319826
[ 3.011404] hardirqs last enabled at (319825): [
- https://git.kernel.org/stable/c/0cccf9d4fb45f1acbc0bbf6d7e4d8d0fb7a10416
- https://git.kernel.org/stable/c/2add538e57a2825c61d639260386f385c75e4166
- https://git.kernel.org/stable/c/3ec80d52b9b74b9e691997632a543c73eddfeba0
- https://git.kernel.org/stable/c/524bb1da785a7ae43dd413cd392b5071c6c367f8
- https://git.kernel.org/stable/c/78c4d68b952f5f537788dbd454031ea9bf50f642
- https://git.kernel.org/stable/c/be8bc05f38d667eda1e820bc6f69234795be7809
- https://git.kernel.org/stable/c/c29642ba72f87c0a3d7449f7db5d6d76a7ed53c3
- https://git.kernel.org/stable/c/c7c0ec5a1dcc3eaa1e85c804c2ccf46e457788a3
- https://git.kernel.org/stable/c/ede1ef1a7de973321699736ef96d01a4b9a6fe9e
Modified: 2025-03-25
CVE-2022-49176
In the Linux kernel, the following vulnerability has been resolved: bfq: fix use-after-free in bfq_dispatch_request KASAN reports a use-after-free report when doing normal scsi-mq test [69832.239032] ================================================================== [69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0 [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155 [69832.244656] [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8 [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [69832.249069] Workqueue: kblockd blk_mq_run_work_fn [69832.250022] Call Trace: [69832.250541] dump_stack+0x9b/0xce [69832.251232] ? bfq_dispatch_request+0x1045/0x44b0 [69832.252243] print_address_description.constprop.6+0x3e/0x60 [69832.253381] ? __cpuidle_text_end+0x5/0x5 [69832.254211] ? vprintk_func+0x6b/0x120 [69832.254994] ? bfq_dispatch_request+0x1045/0x44b0 [69832.255952] ? bfq_dispatch_request+0x1045/0x44b0 [69832.256914] kasan_report.cold.9+0x22/0x3a [69832.257753] ? bfq_dispatch_request+0x1045/0x44b0 [69832.258755] check_memory_region+0x1c1/0x1e0 [69832.260248] bfq_dispatch_request+0x1045/0x44b0 [69832.261181] ? bfq_bfqq_expire+0x2440/0x2440 [69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170 [69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100 [69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570 [69832.267147] ? __switch_to+0x5f4/0xee0 [69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.268946] __blk_mq_run_hw_queue+0xc0/0x270 [69832.269840] blk_mq_run_work_fn+0x51/0x60 [69832.278170] process_one_work+0x6d4/0xfe0 [69832.278984] worker_thread+0x91/0xc80 [69832.279726] ? __kthread_parkme+0xb0/0x110 [69832.280554] ? process_one_work+0xfe0/0xfe0 [69832.281414] kthread+0x32d/0x3f0 [69832.282082] ? kthread_park+0x170/0x170 [69832.282849] ret_from_fork+0x1f/0x30 [69832.283573] [69832.283886] Allocated by task 7725: [69832.284599] kasan_save_stack+0x19/0x40 [69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0 [69832.286350] kmem_cache_alloc_node+0x13f/0x460 [69832.287237] bfq_get_queue+0x3d4/0x1140 [69832.287993] bfq_get_bfqq_handle_split+0x103/0x510 [69832.289015] bfq_init_rq+0x337/0x2d50 [69832.289749] bfq_insert_requests+0x304/0x4e10 [69832.290634] blk_mq_sched_insert_requests+0x13e/0x390 [69832.291629] blk_mq_flush_plug_list+0x4b4/0x760 [69832.292538] blk_flush_plug_list+0x2c5/0x480 [69832.293392] io_schedule_prepare+0xb2/0xd0 [69832.294209] io_schedule_timeout+0x13/0x80 [69832.295014] wait_for_common_io.constprop.1+0x13c/0x270 [69832.296137] submit_bio_wait+0x103/0x1a0 [69832.296932] blkdev_issue_discard+0xe6/0x160 [69832.297794] blk_ioctl_discard+0x219/0x290 [69832.298614] blkdev_common_ioctl+0x50a/0x1750 [69832.304715] blkdev_ioctl+0x470/0x600 [69832.305474] block_ioctl+0xde/0x120 [69832.306232] vfs_ioctl+0x6c/0xc0 [69832.306877] __se_sys_ioctl+0x90/0xa0 [69832.307629] do_syscall_64+0x2d/0x40 [69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [69832.309382] [69832.309701] Freed by task 155: [69832.310328] kasan_save_stack+0x19/0x40 [69832.311121] kasan_set_track+0x1c/0x30 [69832.311868] kasan_set_free_info+0x1b/0x30 [69832.312699] __kasan_slab_free+0x111/0x160 [69832.313524] kmem_cache_free+0x94/0x460 [69832.314367] bfq_put_queue+0x582/0x940 [69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0 [69832.317275] bfq_bfqq_expire+0xb27/0x2440 [69832.318084] bfq_dispatch_request+0x697/0x44b0 [69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.322225] __blk_mq_run_hw_queue+0xc0/0x270 [69832.323114] blk_mq_run_work_fn+0x51/0x6 ---truncated---
- https://git.kernel.org/stable/c/080665e2c3cbfc68359b9a348a3546ed9b908e7a
- https://git.kernel.org/stable/c/40b4ba0030e0b02cbacd424ebb9f4c8b0976c786
- https://git.kernel.org/stable/c/5117c9ff4c2ebae0f5c2c262d42a25a8fbc086e6
- https://git.kernel.org/stable/c/5687958bf18f84384d809f521210d0f5deed03b0
- https://git.kernel.org/stable/c/74e610b5ee0d95e751280567100509eb11517efa
- https://git.kernel.org/stable/c/ab552fcb17cc9e4afe0e4ac4df95fc7b30e8490a
- https://git.kernel.org/stable/c/df6e00b1a53c57dca82c63b5ecbcad5452231bc7
Modified: 2025-10-01
CVE-2022-49177
In the Linux kernel, the following vulnerability has been resolved: hwrng: cavium - fix NULL but dereferenced coccicheck error Fix following coccicheck warning: ./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR: pdev is NULL but dereferenced.
Modified: 2025-09-23
CVE-2022-49178
In the Linux kernel, the following vulnerability has been resolved: memstick/mspro_block: fix handling of read-only devices Use set_disk_ro to propagate the read-only state to the block layer instead of checking for it in ->open and leaking a reference in case of a read-only device.
Modified: 2025-03-25
CVE-2022-49179
In the Linux kernel, the following vulnerability has been resolved: block, bfq: don't move oom_bfqq Our test report a UAF: [ 2073.019181] ================================================================== [ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584 [ 2073.019192] [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5 [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 2073.019200] Call trace: [ 2073.019203] dump_backtrace+0x0/0x310 [ 2073.019206] show_stack+0x28/0x38 [ 2073.019210] dump_stack+0xec/0x15c [ 2073.019216] print_address_description+0x68/0x2d0 [ 2073.019220] kasan_report+0x238/0x2f0 [ 2073.019224] __asan_store8+0x88/0xb0 [ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019233] bfq_put_async_queues+0xbc/0x208 [ 2073.019236] bfq_pd_offline+0x178/0x238 [ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019244] bfq_exit_queue+0x128/0x178 [ 2073.019249] blk_mq_exit_sched+0x12c/0x160 [ 2073.019252] elevator_exit+0xc8/0xd0 [ 2073.019256] blk_exit_queue+0x50/0x88 [ 2073.019259] blk_cleanup_queue+0x228/0x3d8 [ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019274] null_exit+0x90/0x114 [null_blk] [ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019282] el0_svc_common+0xc8/0x320 [ 2073.019287] el0_svc_handler+0xf8/0x160 [ 2073.019290] el0_svc+0x10/0x218 [ 2073.019291] [ 2073.019294] Allocated by task 14163: [ 2073.019301] kasan_kmalloc+0xe0/0x190 [ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418 [ 2073.019308] bfq_pd_alloc+0x54/0x118 [ 2073.019313] blkcg_activate_policy+0x250/0x460 [ 2073.019317] bfq_create_group_hierarchy+0x38/0x110 [ 2073.019321] bfq_init_queue+0x6d0/0x948 [ 2073.019325] blk_mq_init_sched+0x1d8/0x390 [ 2073.019330] elevator_switch_mq+0x88/0x170 [ 2073.019334] elevator_switch+0x140/0x270 [ 2073.019338] elv_iosched_store+0x1a4/0x2a0 [ 2073.019342] queue_attr_store+0x90/0xe0 [ 2073.019348] sysfs_kf_write+0xa8/0xe8 [ 2073.019351] kernfs_fop_write+0x1f8/0x378 [ 2073.019359] __vfs_write+0xe0/0x360 [ 2073.019363] vfs_write+0xf0/0x270 [ 2073.019367] ksys_write+0xdc/0x1b8 [ 2073.019371] __arm64_sys_write+0x50/0x60 [ 2073.019375] el0_svc_common+0xc8/0x320 [ 2073.019380] el0_svc_handler+0xf8/0x160 [ 2073.019383] el0_svc+0x10/0x218 [ 2073.019385] [ 2073.019387] Freed by task 72584: [ 2073.019391] __kasan_slab_free+0x120/0x228 [ 2073.019394] kasan_slab_free+0x10/0x18 [ 2073.019397] kfree+0x94/0x368 [ 2073.019400] bfqg_put+0x64/0xb0 [ 2073.019404] bfqg_and_blkg_put+0x90/0xb0 [ 2073.019408] bfq_put_queue+0x220/0x228 [ 2073.019413] __bfq_put_async_bfqq+0x98/0x168 [ 2073.019416] bfq_put_async_queues+0xbc/0x208 [ 2073.019420] bfq_pd_offline+0x178/0x238 [ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019429] bfq_exit_queue+0x128/0x178 [ 2073.019433] blk_mq_exit_sched+0x12c/0x160 [ 2073.019437] elevator_exit+0xc8/0xd0 [ 2073.019440] blk_exit_queue+0x50/0x88 [ 2073.019443] blk_cleanup_queue+0x228/0x3d8 [ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019459] null_exit+0x90/0x114 [null_blk] [ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019467] el0_svc_common+0xc8/0x320 [ 2073.019471] el0_svc_handler+0xf8/0x160 [ 2073.019474] el0_svc+0x10/0x218 [ 2073.019475] [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00 which belongs to the cache kmalloc-1024 of size 1024 [ 2073.019484] The buggy address is located 552 bytes inside of 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300) [ 2073.019486] The buggy address belongs to the page: [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0 [ 2073.020123] flags: 0x7ffff0000008100(slab|head) [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00 [ 2073.020409] ra ---truncated---
- https://git.kernel.org/stable/c/7507ead1e9d42957c2340f2c4a0e9d00034e3366
- https://git.kernel.org/stable/c/8410f70977734f21b8ed45c37e925d311dfda2e7
- https://git.kernel.org/stable/c/87fdfe8589d43e471dffb4c60f75eeb6f37afc4c
- https://git.kernel.org/stable/c/8f34dea99cd7761156a146a5258a67d045d862f7
- https://git.kernel.org/stable/c/c01fced8d38fbccc82787065229578006f28e020
- https://git.kernel.org/stable/c/c4f5a678add58a8a0e7ee5e038496b376ea6d205
Modified: 2025-10-22
CVE-2022-49180
In the Linux kernel, the following vulnerability has been resolved: LSM: general protection fault in legacy_parse_param The usual LSM hook "bail on fail" scheme doesn't work for cases where a security module may return an error code indicating that it does not recognize an input. In this particular case Smack sees a mount option that it recognizes, and returns 0. A call to a BPF hook follows, which returns -ENOPARAM, which confuses the caller because Smack has processed its data. The SELinux hook incorrectly returns 1 on success. There was a time when this was correct, however the current expectation is that it return 0 on success. This is repaired.
- https://git.kernel.org/stable/c/00fc07fa0b4a004711b6e1a944f0d2e46f7093b7
- https://git.kernel.org/stable/c/2784604c8c6fc523248f8f80a421c313a9d790b7
- https://git.kernel.org/stable/c/cadae7c5e477aaafcba819b8e4a3d1c1a1503b62
- https://git.kernel.org/stable/c/ddcdda888e14ca451b3ee83d11b65b2a9c8e783b
- https://git.kernel.org/stable/c/ecff30575b5ad0eda149aadad247b7f75411fd47
- https://git.kernel.org/stable/c/f3f93a1aaafc3032e0a9655fb43deccfb3e953a3
Modified: 2025-03-25
CVE-2022-49182
In the Linux kernel, the following vulnerability has been resolved: net: hns3: add vlan list lock to protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in vf VLAN list as false. If the periodicity task is freeing the same node, it may cause "use after free" error. This patch adds a vlan list lock to protect the vlan list.
Modified: 2025-10-01
CVE-2022-49183
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix ref leak when switching zones When switching zones or network namespaces without doing a ct clear in between, it is now leaking a reference to the old ct entry. That's because tcf_ct_skb_nfct_cached() returns false and tcf_ct_flow_table_lookup() may simply overwrite it. The fix is to, as the ct entry is not reusable, free it already at tcf_ct_skb_nfct_cached().
Modified: 2025-10-01
CVE-2022-49184
In the Linux kernel, the following vulnerability has been resolved: net: sparx5: switchdev: fix possible NULL pointer dereference As the possible failure of the allocation, devm_kzalloc() may return NULL pointer. Therefore, it should be better to check the 'db' in order to prevent the dereference of NULL pointer.
Modified: 2025-10-01
CVE-2022-49185
In the Linux kernel, the following vulnerability has been resolved: pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/0067ba448f1c29ca06e5aee00d8506889ed1f9d0
- https://git.kernel.org/stable/c/0356d4b64a03d23daf99a2a29d7d7d91d6ec2ea8
- https://git.kernel.org/stable/c/59250d547542f1c7765a78dc97ddfe5e6b0d2ab0
- https://git.kernel.org/stable/c/62580a40c9bef3d8a90629c64dda381344b35ffd
- https://git.kernel.org/stable/c/669b05ff43bd7ed684379c6e2006a6dad5127b71
- https://git.kernel.org/stable/c/9511c6018cd772668def8b034bc67269847e591a
- https://git.kernel.org/stable/c/bc1e29a35147c1ba6ea2b06a16cb0028f7c852d2
- https://git.kernel.org/stable/c/c09ac191b1f97cfa06f394dbfd7a5db07986cefc
- https://git.kernel.org/stable/c/c52703355766c347f270df222a744e0c491a02f2
Modified: 2025-10-01
CVE-2022-49187
In the Linux kernel, the following vulnerability has been resolved: clk: Fix clk_hw_get_clk() when dev is NULL Any registered clk_core structure can have a NULL pointer in its dev field. While never actually documented, this is evidenced by the wide usage of clk_register and clk_hw_register with a NULL device pointer, and the fact that the core of_clk_hw_register() function also passes a NULL device pointer. A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that case will result in a NULL pointer derefence when it calls dev_name() on that NULL device pointer. Add a test for this case and use NULL as the dev_id if the device pointer is NULL.
Modified: 2025-09-23
CVE-2022-49188
In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region The device_node pointer is returned by of_parse_phandle() or of_get_child_by_name() with refcount incremented. We should use of_node_put() on it when done. This function only call of_node_put(node) when of_address_to_resource succeeds, missing error cases.
- https://git.kernel.org/stable/c/07a5dcc4bed9d7cae54adf5aa10ff9f037a3204b
- https://git.kernel.org/stable/c/a7d988735e757e111f9722de7cf1b40a84a48b1f
- https://git.kernel.org/stable/c/b9df3007b3cda4936cc50f5a7d2d30505a652828
- https://git.kernel.org/stable/c/bd4771ba2cf9e18473a42b5b70175e50d67a64bb
- https://git.kernel.org/stable/c/f7210ca29a783c94478da02368731e4c9cf7cdb7
Modified: 2025-10-21
CVE-2022-49189
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: clk-rcg2: Update logic to calculate D value for RCG The display pixel clock has a requirement on certain newer platforms to support M/N as (2/3) and the final D value calculated results in underflow errors. As the current implementation does not check for D value is within the accepted range for a given M & N value. Update the logic to calculate the final D value based on the range.
- https://git.kernel.org/stable/c/334720f418f57b1d969dad2117b21f9388cb9395
- https://git.kernel.org/stable/c/34dca60982e93e69ae442aa2d36ce61c9a3bb563
- https://git.kernel.org/stable/c/52592f9afbfe01bce8f8953e4f19cbe3bcbdbd3a
- https://git.kernel.org/stable/c/58922910add18583d5273c2edcdb9fd7bf4eca02
- https://git.kernel.org/stable/c/96888f0dcf351e758b9df57e015a48427ca709c1
- https://git.kernel.org/stable/c/a4e2e31971354790b0d1fa3e783452a9d135fcff
Modified: 2025-11-03
CVE-2022-49190
In the Linux kernel, the following vulnerability has been resolved: kernel/resource: fix kfree() of bootmem memory again Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory"), we could get a resource allocated during boot via alloc_resource(). And it's required to release the resource using free_resource(). Howerver, many people use kfree directly which will result in kernel BUG. In order to fix this without fixing every call site, just leak a couple of bytes in such corner case.
- https://git.kernel.org/stable/c/0cbcc92917c5de80f15c24d033566539ad696892
- https://git.kernel.org/stable/c/3379a60f6bb4afcd9c456e340ac525ae649d3ce7
- https://git.kernel.org/stable/c/a9e88c2618d228d7a4e7e515cf30dc0d0d813f27
- https://git.kernel.org/stable/c/ab86020070999e758ce2e60c4348f20bf7ddba56
- https://git.kernel.org/stable/c/d7faa04a44a0c37ac3d222fa8e0bdcbfcee9c0c8
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-09-23
CVE-2022-49191
In the Linux kernel, the following vulnerability has been resolved: mxser: fix xmit_buf leak in activate when LSR == 0xff When LSR is 0xff in ->activate() (rather unlike), we return an error. Provided ->shutdown() is not called when ->activate() fails, nothing actually frees the buffer in this case. Fix this by properly freeing the buffer in a designated label. We jump there also from the "!info->type" if now too.
- https://git.kernel.org/stable/c/125b7c929fc9b1e5eaa344bceb6367dfa6fd3f9d
- https://git.kernel.org/stable/c/2cd05c38a27bee7fb42aa4d43174d68ac55dac0f
- https://git.kernel.org/stable/c/376922045009f8ea2d20a8fa3475e95b47c41690
- https://git.kernel.org/stable/c/685b6d16bf89595310b5d61394c9b97cc9505c7c
- https://git.kernel.org/stable/c/6c9041b2f90c0eace73106f22350e1d2c98f5edc
- https://git.kernel.org/stable/c/6dffc2035fbaada60ca8db59e0962e34f760370a
- https://git.kernel.org/stable/c/996291d06851a26678a0fab488b6e1f0677c0576
- https://git.kernel.org/stable/c/b125b08dbee3611f03f53b71471813ed4ccafcdd
- https://git.kernel.org/stable/c/cd3a4907ee334b40d7aa880c7ab310b154fd5cd4
Modified: 2025-10-21
CVE-2022-49192
In the Linux kernel, the following vulnerability has been resolved: drivers: ethernet: cpsw: fix panic when interrupt coaleceing is set via ethtool cpsw_ethtool_begin directly returns the result of pm_runtime_get_sync when successful. pm_runtime_get_sync returns -error code on failure and 0 on successful resume but also 1 when the device is already active. So the common case for cpsw_ethtool_begin is to return 1. That leads to inconsistent calls to pm_runtime_put in the call-chain so that pm_runtime_put is called one too many times and as result leaving the cpsw dev behind suspended. The suspended cpsw dev leads to an access violation later on by different parts of the cpsw driver. Fix this by calling the return-friendly pm_runtime_resume_and_get function.
Modified: 2025-10-21
CVE-2022-49193
In the Linux kernel, the following vulnerability has been resolved:
ice: fix 'scheduling while atomic' on aux critical err interrupt
There's a kernel BUG splat on processing aux critical error
interrupts in ice_misc_intr():
[ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000
...
[ 2101.060770] Call Trace:
[ 2101.063229]
Modified: 2025-10-21
CVE-2022-49194
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [ 210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp : ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated---
- https://git.kernel.org/stable/c/06d836801cd82ded282aaf9e888ff9e7e4a88b91
- https://git.kernel.org/stable/c/1d717816189fd68f9e089cf89ed1f7327d2c2e71
- https://git.kernel.org/stable/c/8d3ea3d402db94b61075617e71b67459a714a502
- https://git.kernel.org/stable/c/b26091a02093104259ca64aeca73601e56160d62
- https://git.kernel.org/stable/c/f49769b462f282477ca801cf648f875b1c5b59db
Modified: 2025-09-23
CVE-2022-49195
In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix panic on shutdown if multi-chip tree failed to probe DSA probing is atypical because a tree of devices must probe all at once, so out of N switches which call dsa_tree_setup_routing_table() during probe, for (N - 1) of them, "complete" will return false and they will exit probing early. The Nth switch will set up the whole tree on their behalf. The implication is that for (N - 1) switches, the driver binds to the device successfully, without doing anything. When the driver is bound, the ->shutdown() method may run. But if the Nth switch has failed to initialize the tree, there is nothing to do for the (N - 1) driver instances, since the slave devices have not been created, etc. Moreover, dsa_switch_shutdown() expects that the calling @ds has been in fact initialized, so it jumps at dereferencing the various data structures, which is incorrect. Avoid the ensuing NULL pointer dereferences by simply checking whether the Nth switch has previously set "ds->setup = true" for the switch which is currently shutting down. The entire setup is serialized under dsa2_mutex which we already hold.
Modified: 2025-03-25
CVE-2022-49196
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix use after free in remove_phb_dynamic() In remove_phb_dynamic() we use &phb->io_resource, after we've called device_unregister(&host_bridge->dev). But the unregister may have freed phb, because pcibios_free_controller_deferred() is the release function for the host_bridge. If there are no outstanding references when we call device_unregister() then phb will be freed out from under us. This has gone mainly unnoticed, but with slub_debug and page_poison enabled it can lead to a crash: PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30 Data SLB Access [380] exception frame: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2 [NIP : release_resource+56] [LR : release_resource+48] #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable) #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868 #12 [c0000000e4f07c70] new_sync_write at c00000000054339c #13 [c0000000e4f07d10] vfs_write at c000000000546624 #14 [c0000000e4f07d60] ksys_write at c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168 To avoid it, we can take a reference to the host_bridge->dev until we're done using phb. Then when we drop the reference the phb will be freed.
Modified: 2025-09-23
CVE-2022-49197
In the Linux kernel, the following vulnerability has been resolved: af_netlink: Fix shift out of bounds in group mask calculation When a netlink message is received, netlink_recvmsg() fills in the address of the sender. One of the fields is the 32-bit bitfield nl_groups, which carries the multicast group on which the message was received. The least significant bit corresponds to group 1, and therefore the highest group that the field can represent is 32. Above that, the UB sanitizer flags the out-of-bounds shift attempts. Which bits end up being set in such case is implementation defined, but it's either going to be a wrong non-zero value, or zero, which is at least not misleading. Make the latter choice deterministic by always setting to 0 for higher-numbered multicast groups. To get information about membership in groups >= 32, userspace is expected to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO socket option. [0] https://lwn.net/Articles/147608/ The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridge Which produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'
- https://git.kernel.org/stable/c/0caf6d9922192dd1afa8dc2131abfb4df1443b9f
- https://git.kernel.org/stable/c/41249fff507387c3323b198d0052faed08b14de4
- https://git.kernel.org/stable/c/7409ff6393a67ff9838d0ae1bd102fb5f020d07a
- https://git.kernel.org/stable/c/ac5883a8890a11c00b32a19949a25d4afeaa2f5a
- https://git.kernel.org/stable/c/b0898362188e05b2202656058cc32d98fabf3bac
- https://git.kernel.org/stable/c/e1c5d46f05aa23d740daae5cd3a6472145afac42
- https://git.kernel.org/stable/c/e23e1e981247feb3c7d0236fe58aceb685f234ae
- https://git.kernel.org/stable/c/e8aaf3134bc5e943048eefe9f2ddaabf41d92b1a
- https://git.kernel.org/stable/c/f75f4abeec4c04b600a15b50c89a481f1e7435ee
Modified: 2025-09-23
CVE-2022-49198
In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix crash due to tcp_tsorted_anchor was initialized before release skb Got crash when doing pressure test of mptcp: =========================================================================== dst_release: dst:ffffa06ce6e5c058 refcnt:-1 kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle kernel paging request at ffffa06ce6e5c058 PGD 190a01067 P4D 190a01067 PUD 43fffb067 PMD 22e403063 PTE 8000000226e5c063 Oops: 0011 [#1] SMP PTI CPU: 7 PID: 7823 Comm: kworker/7:0 Kdump: loaded Tainted: G E Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.2.1 04/01/2014 Call Trace: ? skb_release_head_state+0x68/0x100 ? skb_release_all+0xe/0x30 ? kfree_skb+0x32/0xa0 ? mptcp_sendmsg_frag+0x57e/0x750 ? __mptcp_retrans+0x21b/0x3c0 ? __switch_to_asm+0x35/0x70 ? mptcp_worker+0x25e/0x320 ? process_one_work+0x1a7/0x360 ? worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 ? kthread+0x112/0x130 ? kthread_flush_work_fn+0x10/0x10 ? ret_from_fork+0x35/0x40 =========================================================================== In __mptcp_alloc_tx_skb skb was allocated and skb->tcp_tsorted_anchor will be initialized, in under memory pressure situation sk_wmem_schedule will return false and then kfree_skb. In this case skb->_skb_refdst is not null because_skb_refdst and tcp_tsorted_anchor are stored in the same mem, and kfree_skb will try to release dst and cause crash.
Modified: 2025-10-21
CVE-2022-49199
In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: Prevent underflow in nldev_stat_set_counter_dynamic_doit() This code checks "index" for an upper bound but it does not check for negatives. Change the type to unsigned to prevent underflows.
Modified: 2025-09-23
CVE-2022-49200
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt Fix the following kernel oops in btmtksdio_interrrupt [ 14.339134] btmtksdio_interrupt+0x28/0x54 [ 14.339139] process_sdio_pending_irqs+0x68/0x1a0 [ 14.339144] sdio_irq_work+0x40/0x70 [ 14.339154] process_one_work+0x184/0x39c [ 14.339160] worker_thread+0x228/0x3e8 [ 14.339168] kthread+0x148/0x3ac [ 14.339176] ret_from_fork+0x10/0x30 That happened because hdev->power_on is already called before sdio_set_drvdata which btmtksdio_interrupt handler relies on is not properly set up. The details are shown as the below: hci_register_dev would run queue_work(hdev->req_workqueue, &hdev->power_on) as WQ_HIGHPRI workqueue_struct to complete the power-on sequeunce and thus hci_power_on may run before sdio_set_drvdata is done in btmtksdio_probe. The hci_dev_do_open in hci_power_on would initialize the device and enable the interrupt and thus it is possible that btmtksdio_interrupt is being called right before sdio_set_drvdata is filled out. When btmtksdio_interrupt is being called and sdio_set_drvdata is not filled , the kernel oops is going to happen because btmtksdio_interrupt access an uninitialized pointer.
- https://git.kernel.org/stable/c/4d3d1f2c35a19988d3c5f0ee86038b525e830840
- https://git.kernel.org/stable/c/6d7be5afbb41c918d2f12f857f8c7efa50500be2
- https://git.kernel.org/stable/c/70a6cf749d9ff9f463490248322e5343199bc267
- https://git.kernel.org/stable/c/770a97d3f34b801de1b04737b43e02c55118c41a
- https://git.kernel.org/stable/c/874eca93966a786eace87fa6dfb206c2dd9519b1
- https://git.kernel.org/stable/c/b062a0b9c1dc1ff63094337dccfe1568d5b62023
Modified: 2025-10-01
CVE-2022-49201
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: fix race between xmit and reset There is a race between reset and the transmit paths that can lead to ibmvnic_xmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c The immediate cause of the crash is the access of tx_scrq in the following snippet during a reset, where the tx_scrq can be either NULL or an address that will soon be invalid: ibmvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } But beyond that, the call to ibmvnic_xmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvnic_cleanup(). However just after the queue was stopped, an in-flight ibmvnic_complete_tx() could have restarted the queue even as the reset is progressing. Since the queue was restarted we could get a call to ibmvnic_xmit() which can then access the bad tx_scrq (or other fields). We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts. IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active. So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open() ->resetting = true ->tx_queues_active = false disable tx queues ... ->tx_queues_active = true start tx queues B. Tx interrupt in ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); To ensure that ->tx_queues_active and state of the queues are consistent, we need a lock which: - must also be taken in the interrupt path (ibmvnic_complete_tx()) - shared across the multiple ---truncated---
Modified: 2025-09-22
CVE-2022-49202
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: add missing NULL check in h5_enqueue Syzbot hit general protection fault in __pm_runtime_resume(). The problem was in missing NULL check. hu->serdev can be NULL and we should not blindly pass &serdev->dev somewhere, since it will cause GPF.
Modified: 2025-10-21
CVE-2022-49204
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix more uncharged while msg has more_data
In tcp_bpf_send_verdict(), if msg has more data after
tcp_bpf_sendmsg_redir():
tcp_bpf_send_verdict()
tosend = msg->sg.size //msg->sg.size = 22220
case __SK_REDIRECT:
sk_msg_return() //uncharged msg->sg.size(22220) sk->sk_forward_alloc
tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000
goto more_data;
tosend = msg->sg.size //msg->sg.size = 11000
case __SK_REDIRECT:
sk_msg_return() //uncharged msg->sg.size(11000) to sk->sk_forward_alloc
The msg->sg.size(11000) has been uncharged twice, to fix we can charge the
remaining msg->sg.size before goto more data.
This issue can cause the following info:
WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
- https://git.kernel.org/stable/c/168ff181f5b6e7fce684c98a30d35da1dbf8f82a
- https://git.kernel.org/stable/c/244ce90c8d0bd10ebf957da02c6f3fcd5d920bdf
- https://git.kernel.org/stable/c/7b812a369e6416ab06d83cdd39d8e3f752781dd0
- https://git.kernel.org/stable/c/84472b436e760ba439e1969a9e3c5ae7c86de39d
- https://git.kernel.org/stable/c/87d532d41ef937e16f61b3d2094f3a2ac49be365
- https://git.kernel.org/stable/c/abb4caa477a5450817d2aa1198edce66450aecf8
Modified: 2025-09-22
CVE-2022-49205
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix double uncharge the mem of sk_msg
If tcp_bpf_sendmsg is running during a tear down operation, psock may be
freed.
tcp_bpf_sendmsg()
tcp_bpf_send_verdict()
sk_msg_return()
tcp_bpf_sendmsg_redir()
unlikely(!psock))
sk_msg_free()
The mem of msg has been uncharged in tcp_bpf_send_verdict() by
sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock
is null, we can simply returning an error code, this would then trigger
the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have
the side effect of throwing an error up to user space. This would be a
slight change in behavior from user side but would look the same as an
error if the redirect on the socket threw an error.
This issue can cause the following info:
WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
- https://git.kernel.org/stable/c/223f3c51ab163852dd4819d357dcf33039929434
- https://git.kernel.org/stable/c/2486ab434b2c2a14e9237296db00b1e1b7ae3273
- https://git.kernel.org/stable/c/94c6ac22abcdede72bfaa0f4c22fb370891f4002
- https://git.kernel.org/stable/c/ac3ecb7760c750c8e4fc09c719241d8e6e88028c
- https://git.kernel.org/stable/c/cb6f141ae705af0101e819065a79e6d029f6e393
- https://git.kernel.org/stable/c/cd84ea3920aef936c559b63099ef0013ce6b2325
Modified: 2025-10-01
CVE-2022-49206
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix memory leak in error flow for subscribe event routine In case the second xa_insert() fails, the obj_event is not released. Fix the error unwind flow to free that memory to avoid a memory leak.
- https://git.kernel.org/stable/c/0174a89663a5ef83617da15bf24c0af2f62b6c7f
- https://git.kernel.org/stable/c/087f9c3f2309ed183f7e4b85ae57121d8663224d
- https://git.kernel.org/stable/c/414b4e8738484379f18d6c4e780787c80dbf8a2c
- https://git.kernel.org/stable/c/8dd392e352d3269938fea32061a74655a613f929
- https://git.kernel.org/stable/c/c98d903ff9e79c210beddea4e6bc15ac38e25aa5
- https://git.kernel.org/stable/c/d66498507801fd9a20307a15a0814a0a016c3cde
Modified: 2025-10-01
CVE-2022-49207
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in sk_psock_queue_msg
If tcp_bpf_sendmsg is running during a tear down operation we may enqueue
data on the ingress msg queue while tear down is trying to free it.
sk1 (redirect sk2) sk2
------------------- ---------------
tcp_bpf_sendmsg()
tcp_bpf_send_verdict()
tcp_bpf_sendmsg_redir()
bpf_tcp_ingress()
sock_map_close()
lock_sock()
lock_sock() ... blocking
sk_psock_stop
sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED);
release_sock(sk);
lock_sock()
sk_mem_charge()
get_page()
sk_psock_queue_msg()
sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED);
drop_sk_msg()
release_sock()
While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge
and has sg pages need to put. To fix we use sk_msg_free() and then kfee()
msg.
This issue can cause the following info:
WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0
Call Trace:
Modified: 2025-10-01
CVE-2022-49208
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent some integer underflows My static checker complains that: drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init() warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'? It appears that "info->dev->hmc_fpm_misc.max_ceqs" comes from the firmware in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could be zero. Even if we trust the firmware, it's easy enough to change the condition just as a hardenning measure.
Modified: 2025-10-01
CVE-2022-49209
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.
This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
- https://git.kernel.org/stable/c/6d03722c34d9603df325f67c6d30dc1b7b3c6067
- https://git.kernel.org/stable/c/9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8
- https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047
- https://git.kernel.org/stable/c/d0b85dfc6f01d26808e2576c6537c131b590e270
- https://git.kernel.org/stable/c/de3a8d8fab0710186f7864ec812836d8d70da3c9
- https://git.kernel.org/stable/c/f677328f05f52d535cbdc15cb04476db49477eb4
Modified: 2025-10-01
CVE-2022-49210
In the Linux kernel, the following vulnerability has been resolved: MIPS: pgalloc: fix memory leak caused by pgd_free() pgd page is freed by generic implementation pgd_free() since commit f9cb654cb550 ("asm-generic: pgalloc: provide generic pgd_free()"), however, there are scenarios that the system uses more than one page as the pgd table, in such cases the generic implementation pgd_free() won't be applicable anymore. For example, when PAGE_SIZE_4KB is enabled and MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER" will be set as "1", which will cause allocating two pages as the pgd table. Well, at the same time, the generic implementation pgd_free() just free one pgd page, which will result in the memory leak. The memory leak can be easily detected by executing shell command: "while true; do ls > /dev/null; grep MemFree /proc/meminfo; done"
- https://git.kernel.org/stable/c/1bf0d78c8cc3cf615a6e7bf33ada70b73592f0a1
- https://git.kernel.org/stable/c/2bc5bab9a763d520937e4f3fe8df51c6a1eceb97
- https://git.kernel.org/stable/c/5a8501d34b261906e4c76ec9da679f2cb4d309ed
- https://git.kernel.org/stable/c/d29cda15cab086d82d692de016f7249545d4b6b4
- https://git.kernel.org/stable/c/fa3d44424579972cc7c4fac3d9cf227798ebdfa0
Modified: 2025-10-01
CVE-2022-49211
In the Linux kernel, the following vulnerability has been resolved: mips: cdmm: Fix refcount leak in mips_cdmm_phys_base The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount.
- https://git.kernel.org/stable/c/4528668ca331f7ce5999b7746657b46db5b3b785
- https://git.kernel.org/stable/c/4680c2ac9aabda82acd23ebbd1f900fb6a889cd3
- https://git.kernel.org/stable/c/69155dc2e04777aa94207a73a8b10f12b8428a68
- https://git.kernel.org/stable/c/721ab4be20d4448dd04c2cc8ed99cd4f3e45f765
- https://git.kernel.org/stable/c/ef1728e3cb9e43f38ed10cde705a7ba2b4ad2d35
Modified: 2025-10-01
CVE-2022-49212
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init The reference counting issue happens in several error handling paths on a refcounted object "nc->dmac". In these paths, the function simply returns the error code, forgetting to balance the reference count of "nc->dmac", increased earlier by dma_request_channel(), which may cause refcount leaks. Fix it by decrementing the refcount of specific object in those error paths.
- https://git.kernel.org/stable/c/0856bf27057561f42b37df111603cf5a0d040294
- https://git.kernel.org/stable/c/8baea2b96fa90af8d0f937caf4cf2105ee094d93
- https://git.kernel.org/stable/c/9843c9c98f26c6ad843260b19bfdaa2598f2ae1e
- https://git.kernel.org/stable/c/9b08d211db4c447eb1a07df65e45e0aa772e0fa6
- https://git.kernel.org/stable/c/a3587259ae553e41d1ce8c7435351a5d6b299a11
- https://git.kernel.org/stable/c/f1694169f3674cdf7553aed06864254635679878
- https://git.kernel.org/stable/c/fe0e2ce5c87e9c0b9485ff566362030aa55972cf
- https://git.kernel.org/stable/c/fecbd4a317c95d73c849648c406bcf1b6a0ec1cf
Modified: 2025-10-01
CVE-2022-49213
In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix error handling in ath10k_setup_msa_resources The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error path.
- https://git.kernel.org/stable/c/315772133a4b960859e4f5efe0e738e347188cdc
- https://git.kernel.org/stable/c/32939187f254171a5666badc058bc3787fe454af
- https://git.kernel.org/stable/c/4ed37d611ea5d222c3ecb3549e4c2d34b8f3c335
- https://git.kernel.org/stable/c/74b1d41e1b6410eed5c76d00eedb262036e9eff5
- https://git.kernel.org/stable/c/9747a78d5f758a5284751a10aee13c30d02bd5f1
Modified: 2025-09-22
CVE-2022-49214
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Don't use DSISR for SLB faults Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data is read or write.") we use page_fault_is_write(regs->dsisr) in __bad_page_fault() to determine if the fault is for a read or write, and change the message printed accordingly. But SLB faults, aka Data Segment Interrupts, don't set DSISR (Data Storage Interrupt Status Register) to a useful value. All ISA versions from v2.03 through v3.1 specify that the Data Segment Interrupt sets DSISR "to an undefined value". As far as I can see there's no mention of SLB faults setting DSISR in any BookIV content either. This manifests as accesses that should be a read being incorrectly reported as writes, for example, using the xmon "dump" command: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000 [359526.415611][ C6] Faulting instruction address: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 If we disassemble the PC, we see a load instruction: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) We can also see in exceptions-64s.S that the data_access_slb block doesn't set IDSISR=1, which means it doesn't load DSISR into pt_regs. So the value we're using to determine if the fault is a read/write is some stale value in pt_regs from a previous page fault. Rework the printing logic to separate the SLB fault case out, and only print read/write in the cases where we can determine it. The result looks like eg: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000 [ 721.779697][ C6] Faulting instruction address: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] BUG: Kernel NULL pointer dereference at 0x00000000 [ 742.793316][ C6] Faulting instruction address: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]
Modified: 2025-10-01
CVE-2022-49215
In the Linux kernel, the following vulnerability has been resolved:
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
Modified: 2025-10-01
CVE-2022-49216
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix reference leak in tegra_dsi_ganged_probe The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add put_device() call to fix this.
- https://git.kernel.org/stable/c/0e2f4e434e71dffd1085c3dccd676514bd71d316
- https://git.kernel.org/stable/c/1e06710c43a090f14bb67714265a01cd1d7a37c5
- https://git.kernel.org/stable/c/221e3638feb8bc42143833c9a704fa89b6c366bb
- https://git.kernel.org/stable/c/2d6ae8b747fe55f54de4a4441d636974aa53f56a
- https://git.kernel.org/stable/c/5e8fdb6392d945d33fef959eab73f8c34bc0a63b
- https://git.kernel.org/stable/c/852c1f5f3119a38ee68e319bab10277fc1ab06b7
- https://git.kernel.org/stable/c/a725070701883fe62266ee6d2f31d67e6cdd31df
- https://git.kernel.org/stable/c/cd78b74031cbc94133965f1017deb822657fc1a6
- https://git.kernel.org/stable/c/f3c99c686e098300c246e5e8a1474133e3dacb05
Modified: 2025-10-21
CVE-2022-49217
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix abort all task initialization
In pm80xx_send_abort_all(), the n_elem field of the ccb used is not
initialized to 0. This missing initialization sometimes lead to the task
completion path seeing the ccb with a non-zero n_elem resulting in the
execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),
causing a crash such as:
[ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280
[ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012
[ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0
[ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0
[ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b
[ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000
[ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000
[ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000
[ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0
[ 197.762656] Call Trace:
[ 197.765127]
- https://git.kernel.org/stable/c/16cd02e0951b520bef324adb9a35afcc92501caf
- https://git.kernel.org/stable/c/1824a21b2cedc5774a5adfa74f5f7b90472d8677
- https://git.kernel.org/stable/c/279f318bd7d6e04e6e0bc7b8cd8e190da8fa37a4
- https://git.kernel.org/stable/c/326d894adf89f3c707b7784becbe241830daaab6
- https://git.kernel.org/stable/c/765674e3b30121782a2b792684554baa48c61f5e
- https://git.kernel.org/stable/c/7f12845c8389855dbcc67baa068b6832dc4a396e
- https://git.kernel.org/stable/c/9914461db82caee6c519acfbe10a86fe11bcdeca
- https://git.kernel.org/stable/c/c8db786858d895ac58342f67767b4999ae6538fa
- https://git.kernel.org/stable/c/d6ec4471550cc53e96485a7124c5891e6a38d1c3
Modified: 2025-10-01
CVE-2022-49218
In the Linux kernel, the following vulnerability has been resolved: drm/dp: Fix OOB read when handling Post Cursor2 register The link_status array was not large enough to read the Adjust Request Post Cursor2 register, so remove the common helper function to avoid an OOB read, found with a -Warray-bounds build: drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds] 59 | return link_status[r - DP_LANE0_1_STATUS]; | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status' 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Replace the only user of the helper with an open-coded fetch and decode, similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
Modified: 2025-11-03
CVE-2022-49219
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: fix memory leak during D3hot to D0 transition If 'vfio_pci_core_device::needs_pm_restore' is set (PCI device does not have No_Soft_Reset bit set in its PMCSR config register), then the current PCI state will be saved locally in 'vfio_pci_core_device::pm_save' during D0->D3hot transition and same will be restored back during D3hot->D0 transition. For saving the PCI state locally, pci_store_saved_state() is being used and the pci_load_and_free_saved_state() will free the allocated memory. But for reset related IOCTLs, vfio driver calls PCI reset-related API's which will internally change the PCI power state back to D0. So, when the guest resumes, then it will get the current state as D0 and it will skip the call to vfio_pci_set_power_state() for changing the power state to D0 explicitly. In this case, the memory pointed by 'pm_save' will never be freed. In a malicious sequence, the state changing to D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be run in a loop and it can cause an OOM situation. This patch frees the earlier allocated memory first before overwriting 'pm_save' to prevent the mentioned memory leak.
- https://git.kernel.org/stable/c/26ddd196e9eb264da8e1bdc4df8a94d62581c8b5
- https://git.kernel.org/stable/c/4319f17fb8264ba39352b611dfa913a4d8c1d1a0
- https://git.kernel.org/stable/c/c8a1f8bd586ee31020614b8d48b702ece3e2ae44
- https://git.kernel.org/stable/c/da426ad86027b849b877d4628b277ffbbd2f5325
- https://git.kernel.org/stable/c/eadf88ecf6ac7d6a9f47a76c6055d9a1987a8991
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-10-21
CVE-2022-49220
In the Linux kernel, the following vulnerability has been resolved: dax: make sure inodes are flushed before destroy cache A bug can be triggered by following command $ modprobe nd_pmem && modprobe -r nd_pmem [ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown() [ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node) [ 10.062433] Call Trace: [ 10.062673] dump_stack_lvl+0x34/0x44 [ 10.062865] slab_err+0x90/0xd0 [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0 [ 10.063848] kmem_cache_destroy+0x4a/0x110 [ 10.064058] __x64_sys_delete_module+0x265/0x300 This is caused by dax_fs_exit() not flushing inodes before destroy cache. To fix this issue, call rcu_barrier() before destroy cache.
- https://git.kernel.org/stable/c/770d42fff12d8595adda9025a0b92091f543e775
- https://git.kernel.org/stable/c/a7e8de822e0b1979f08767c751f6c8a9c1d4ad86
- https://git.kernel.org/stable/c/b786abe7c67c6ef71410c8e23292b3091d616ad1
- https://git.kernel.org/stable/c/e2951eaa9398415ac054b7bd80b8163b6838ead4
- https://git.kernel.org/stable/c/ec376f5c11c88c0215d173599db8449cd4196759
- https://git.kernel.org/stable/c/f2a1e0eb70c2d954176c07d75d28742bde30e9f3
Modified: 2025-10-01
CVE-2022-49221
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: populate connector of struct dp_panel
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
connector is stored in struct msm_dp::connector. When we run compliance
testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid
edid set in struct dp_panel::edid so we'll try to use the connectors
real_edid_checksum and hit a NULL pointer dereference error because the
connector pointer is never assigned.
Changes in V2:
-- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps()
Changes in V3:
-- remove unhelpful kernel crash trace commit text
-- remove renaming dp_display parameter to dp
Changes in V4:
-- add more details to commit text
Changes in v10:
-- group into one series
Changes in v11:
-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read
Signee-off-by: Kuogee Hsieh
- https://git.kernel.org/stable/c/104074ebc0c3f358dd1ee944fbcde92c6e5a21dd
- https://git.kernel.org/stable/c/413c62697b61226a236c8b1f5cd64dcf42bcc12f
- https://git.kernel.org/stable/c/5e602f5156910c7b19661699896cb6e3fb94fab9
- https://git.kernel.org/stable/c/9525b8bcae8b99188990b56484799cf4b1b43786
- https://git.kernel.org/stable/c/fbba600f432a360b42452fee79d1fb35d3aa8aeb
Modified: 2025-09-22
CVE-2022-49222
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: anx7625: Fix overflow issue on reading EDID The length of EDID block can be longer than 256 bytes, so we should use `int` instead of `u8` for the `edid_pos` variable.
Modified: 2025-03-25
CVE-2022-49223
In the Linux kernel, the following vulnerability has been resolved:
cxl/port: Hold port reference until decoder release
KASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free in
cxl_decoder_release() where it goes to reference its parent, a cxl_port,
to free its id back to port->decoder_ida.
BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core]
Read of size 8 at addr ffff888119270908 by task kworker/35:2/379
CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: events kobject_delayed_cleanup
Call Trace:
Modified: 2025-10-01
CVE-2022-49224
In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add(): If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put().
- https://git.kernel.org/stable/c/19aa3c98ed7b2616e105946cec804f897837ab84
- https://git.kernel.org/stable/c/261041097ab3470f1120b7733cbf472712304d1e
- https://git.kernel.org/stable/c/31cdf7897dba1f096b74f69d840f0575b8cdb9ae
- https://git.kernel.org/stable/c/41ed61364285ff38bbbe9ca8a45c8372ba72921d
- https://git.kernel.org/stable/c/6a4760463dbc6b603690938c468839985189ce0a
- https://git.kernel.org/stable/c/879356a6a05559582b0a7895d86d2d4359745c08
- https://git.kernel.org/stable/c/c32f6b6196b6efc1c68990dfeaac36fb8eb3b8e1
- https://git.kernel.org/stable/c/db3a61ef8e6aef3b888baa6a85926c2230c2cc56
- https://git.kernel.org/stable/c/ffb8e92b4cef92bd25563cf3d8b4489eb22bc61f
Modified: 2025-10-21
CVE-2022-49226
In the Linux kernel, the following vulnerability has been resolved: net: asix: add proper error handling of usb read errors Syzbot once again hit uninit value in asix driver. The problem still the same -- asix_read_cmd() reads less bytes, than was requested by caller. Since all read requests are performed via asix_read_cmd() let's catch usb related error there and add __must_check notation to be sure all callers actually check return value. So, this patch adds sanity check inside asix_read_cmd(), that simply checks if bytes read are not less, than was requested and adds missing error handling of asix_read_cmd() all across the driver code.
Modified: 2025-10-21
CVE-2022-49227
In the Linux kernel, the following vulnerability has been resolved:
igc: avoid kernel warning when changing RX ring parameters
Calling ethtool changing the RX ring parameters like this:
$ ethtool -G eth0 rx 1024
on igc triggers kernel warnings like this:
[ 225.198467] ------------[ cut here ]------------
[ 225.198473] Missing unregister, handled but fix driver
[ 225.198485] WARNING: CPU: 7 PID: 959 at net/core/xdp.c:168
xdp_rxq_info_reg+0x79/0xd0
[...]
[ 225.198601] Call Trace:
[ 225.198604]
Modified: 2025-09-22
CVE-2022-49228
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix a btf decl_tag bug when tagging a function
syzbot reported a btf decl_tag bug with stack trace below:
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline]
RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910
...
Call Trace:
Modified: 2025-10-21
CVE-2022-49229
In the Linux kernel, the following vulnerability has been resolved: ptp: unregister virtual clocks when unregistering physical clock. When unregistering a physical clock which has some virtual clocks, unregister the virtual clocks with it. This fixes the following oops, which can be triggered by unloading a driver providing a PTP clock when it has enabled virtual clocks: BUG: unable to handle page fault for address: ffffffffc04fc4d8 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ptp_vclock_read+0x31/0xb0 Call Trace: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Modified: 2025-10-01
CVE-2022-49230
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix possible memory leak in mt7915_mcu_add_sta Free allocated skb in mt7915_mcu_add_sta routine in case of failures.
Modified: 2025-10-01
CVE-2022-49232
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() is assigned to mode and is passed to drm_mode_probed_add() directly after that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and there is a dereference of it in list_add_tail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode(). Fix this by adding a NULL check of mode. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code.
- https://git.kernel.org/stable/c/19a7eba284790cfbba2945deb2363cf03ce41648
- https://git.kernel.org/stable/c/2c729dec8c1e3e2892fde5ce8181553860914e74
- https://git.kernel.org/stable/c/57f4ad5e286fe4599c8fc63cf89f85f9eec7f9c9
- https://git.kernel.org/stable/c/588a70177df3b1777484267584ef38ab2ca899a2
- https://git.kernel.org/stable/c/639b3b9def0a6a3f316a195d705d14113236e89c
- https://git.kernel.org/stable/c/bdc7429708a0772d90c208975694f7c2133b1202
- https://git.kernel.org/stable/c/f4eaa999fec78dec2a9c2d797438e05cbffb125b
Modified: 2025-09-22
CVE-2022-49234
In the Linux kernel, the following vulnerability has been resolved: net: dsa: Avoid cross-chip syncing of VLAN filtering Changes to VLAN filtering are not applicable to cross-chip notifications. On a system like this: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1. In this scenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.
Modified: 2025-10-01
CVE-2022-49235
In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix uninit value bugs Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing field initialization. In htc_connect_service() svc_meta_len and pad are not initialized. Based on code it looks like in current skb there is no service data, so simply initialize svc_meta_len to 0. htc_issue_send() does not initialize htc_frame_hdr::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happy Fail logs: BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 4-7 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 16-17 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00
- https://git.kernel.org/stable/c/0b700f7d06492de34964b6f414120043364f8191
- https://git.kernel.org/stable/c/11f11ac281f0c0b363d2940204f28bae0422ed71
- https://git.kernel.org/stable/c/4d244b731188e0b63fc40a9d2dec72e9181fb37c
- https://git.kernel.org/stable/c/5abf2b761b998063f5e2bae93fd4ab10e2a80f10
- https://git.kernel.org/stable/c/5c2a6a8daa17a3f65b38b9a5574bb362c13fa1d9
- https://git.kernel.org/stable/c/7da6169b6ebb75816b57be3beb829afa74f3b4b6
- https://git.kernel.org/stable/c/d1e0df1c57bd30871dd1c855742a7c346dbca853
- https://git.kernel.org/stable/c/e352acdd378e9263cc4c6018e588f2dac7161d07
- https://git.kernel.org/stable/c/ee4222052a76559c20e821bc3519cefb58b6d3e9
Modified: 2025-03-25
CVE-2022-49236
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF due to race between btf_try_get_module and load_module While working on code to populate kfunc BTF ID sets for module BTF from its initcall, I noticed that by the time the initcall is invoked, the module BTF can already be seen by userspace (and the BPF verifier). The existing btf_try_get_module calls try_module_get which only fails if mod->state == MODULE_STATE_GOING, i.e. it can increment module reference when module initcall is happening in parallel. Currently, BTF parsing happens from MODULE_STATE_COMING notifier callback. At this point, the module initcalls have not been invoked. The notifier callback parses and prepares the module BTF, allocates an ID, which publishes it to userspace, and then adds it to the btf_modules list allowing the kernel to invoke btf_try_get_module for the BTF. However, at this point, the module has not been fully initialized (i.e. its initcalls have not finished). The code in module.c can still fail and free the module, without caring for other users. However, nothing stops btf_try_get_module from succeeding between the state transition from MODULE_STATE_COMING to MODULE_STATE_LIVE. This leads to a use-after-free issue when BPF program loads successfully in the state transition, load_module's do_init_module call fails and frees the module, and BPF program fd on close calls module_put for the freed module. Future patch has test case to verify we don't regress in this area in future. There are multiple points after prepare_coming_module (in load_module) where failure can occur and module loading can return error. We illustrate and test for the race using the last point where it can practically occur (in module __init function). An illustration of the race: CPU 0 CPU 1 load_module notifier_call(MODULE_STATE_COMING) btf_parse_module btf_alloc_id // Published to userspace list_add(&btf_mod->list, btf_modules) mod->init(...) ... ^ bpf_check | check_pseudo_btf_id | btf_try_get_module | returns true | ... ... | module __init in progress return prog_fd | ... ... V if (ret < 0) free_module(mod) ... close(prog_fd) ... bpf_prog_free_deferred module_put(used_btf.mod) // use-after-free We fix this issue by setting a flag BTF_MODULE_F_LIVE, from the notifier callback when MODULE_STATE_LIVE state is reached for the module, so that we return NULL from btf_try_get_module for modules that are not fully formed. Since try_module_get already checks that module is not in MODULE_STATE_GOING state, and that is the only transition a live module can make before being removed from btf_modules list, this is enough to close the race and prevent the bug. A later selftest patch crafts the race condition artifically to verify that it has been fixed, and that verifier fails to load program (with ENXIO). Lastly, a couple of comments: 1. Even if this race didn't exist, it seems more appropriate to only access resources (ksyms and kfuncs) of a fully formed module which has been initialized completely. 2. This patch was born out of need for synchronization against module initcall for the next patch, so it is needed for correctness even without the aforementioned race condition. The BTF resources initialized by module initcall are set up once and then only looked up, so just waiting until the initcall has finished ensures correct behavior.
Modified: 2025-10-01
CVE-2022-49239
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd934x: Add missing of_node_put() in wcd934x_codec_parse_data The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This is similar to commit 64b92de9603f ("ASoC: wcd9335: fix a leaked reference by adding missing of_node_put")
- https://git.kernel.org/stable/c/1f24716e38220fc9e52e208d20591d2bc9b7f020
- https://git.kernel.org/stable/c/2f44eca78cc6d4e1779eb95765ec79e433accab4
- https://git.kernel.org/stable/c/9531a631379169d57756b2411178c6238655df88
- https://git.kernel.org/stable/c/f3793eeb7b94a5eeed6f5c7a44bce403c6681a12
- https://git.kernel.org/stable/c/f8e89d84ea83c51ba3ba97ff154f7aa679326760
Modified: 2025-10-01
CVE-2022-49241
In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Fix error handling in sam9x5_wm8731_driver_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error path.
- https://git.kernel.org/stable/c/14228225091a0854b1de23e5b4fe8bdeeca9683b
- https://git.kernel.org/stable/c/740dc3e846537c3743da98bf106f376023fd085c
- https://git.kernel.org/stable/c/90ac679aa6a01841da90ec5a4aaa4b5e0badddf0
- https://git.kernel.org/stable/c/f43ad5dc43240289f4cf13c16cc506f4f7087931
- https://git.kernel.org/stable/c/f589063b585ac6dd2081bde6c145411cf48d8d92
Modified: 2025-10-01
CVE-2022-49242
In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs: Fix error handling in mxs_sgtl5000_probe This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. For example, when codec_np is NULL, saif_np[0] and saif_np[1] are not NULL, it will cause leaks. of_node_put() will check if the node pointer is NULL, so we can call it directly to release the refcount of regular pointers.
- https://git.kernel.org/stable/c/44acdaf7acb60054d872bed18ce0e7db8ce900ce
- https://git.kernel.org/stable/c/67e12f1cb2f97468c12b59e21975eaa0f332e7d2
- https://git.kernel.org/stable/c/6ae0a4d8fec551ec581d620f0eb1fe31f755551c
- https://git.kernel.org/stable/c/790d2628e3fcc819d8f5572eb5615113fb2e727a
- https://git.kernel.org/stable/c/86b6cf989437e694fd0a15782b5a513853a739e0
- https://git.kernel.org/stable/c/8d880226c86f37624e2a5f3c6d92ac0ec3375f96
- https://git.kernel.org/stable/c/d2923b48d99fe663cb93d8b481c93299fcd68656
- https://git.kernel.org/stable/c/f16ad2c0e22687f80e5981c67374023f51c204b9
- https://git.kernel.org/stable/c/f8d38056bcd220ea6f0802a5586d1a12ebcce849
Modified: 2025-10-21
CVE-2022-49243
In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Add missing of_node_put() in at91sam9g20ek_audio_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/0325193cf40dc3a6e27d55a5b98680936deebcd0
- https://git.kernel.org/stable/c/32e6ceb05f36432811753852c674a301f944a24b
- https://git.kernel.org/stable/c/4793a02deb31b71b3984abc67bf1011a03c13b18
- https://git.kernel.org/stable/c/662ee5ac6b451aa5a27b8eebd397f2f5c7f42cec
- https://git.kernel.org/stable/c/81f266396237cea09a8c6322a6a78535f06ed345
- https://git.kernel.org/stable/c/a0bc36b247dcf4d21bf820bfc4bcbaf7f6cf19b5
- https://git.kernel.org/stable/c/b0c56a0071116a37c24df998166c22a7e4684626
- https://git.kernel.org/stable/c/f590797fa3c1bccdd19e55441592a23b46aef449
- https://git.kernel.org/stable/c/f8b7b9a0594715ecfbe6f18db2328d992242654a
Modified: 2025-09-22
CVE-2022-49244
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192-mt6359: Fix error handling in mt8192_mt6359_dev_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too.
Modified: 2025-09-22
CVE-2022-49245
In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: Fix PM usage reference of rockchip_i2s_tdm_resume pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced.
Modified: 2025-09-22
CVE-2022-49246
In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Fix error handling in snd_proto_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too.
Modified: 2025-10-21
CVE-2022-49247
In the Linux kernel, the following vulnerability has been resolved: media: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUED If the callback 'start_streaming' fails, then all queued buffers in the driver should be returned with state 'VB2_BUF_STATE_QUEUED'. Currently, they are returned with 'VB2_BUF_STATE_ERROR' which is wrong. Fix this. This also fixes the warning: [ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6 [ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14 [ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT) [ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common] [ 65.592395] sp : ffff800012bc3ad0 [ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8 [ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612 [ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0 [ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff [ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78 [ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce [ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228 [ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78 [ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880 [ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0 [ 65.598940] Call trace: [ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common] [ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2] [ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2] [ 65.601103] v4l_streamon+0x3c/0x50 [videodev] [ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev] [ 65.601977] video_usercopy+0x320/0x828 [videodev] [ 65.602419] video_ioctl2+0x3c/0x58 [videodev] [ 65.602830] v4l2_ioctl+0x60/0x90 [videodev] [ 65.603227] __arm64_sys_ioctl+0xa8/0xe0 [ 65.603576] invoke_syscall+0x54/0x118 [ 65.603911] el0_svc_common.constprop.3+0x84/0x100 [ 65.604332] do_el0_svc+0x34/0xa0 [ 65.604625] el0_svc+0x1c/0x50 [ 65.604897] el0t_64_sync_handler+0x88/0xb0 [ 65.605264] el0t_64_sync+0x16c/0x170 [ 65.605587] ---[ end trace 578e0ba07742170d ]---
- https://git.kernel.org/stable/c/03054f22d5abd80ad89547512c2bfbfb2714d3ed
- https://git.kernel.org/stable/c/2874122ca4ca74adec72d6d6bf8828228ec20f15
- https://git.kernel.org/stable/c/3cc050df73e3d973f1870a8dc0e177e77670bc7f
- https://git.kernel.org/stable/c/4d68603cc4382174bc1e7d532e10675c48c6b257
- https://git.kernel.org/stable/c/a09e9882800fdfc5aab93f77c3f0132071d2191b
- https://git.kernel.org/stable/c/f04a520a422222fc921bf035dc67414c500a286a
- https://git.kernel.org/stable/c/f66e6fd1488d26229f11d86616de1b658c70fa8a
- https://git.kernel.org/stable/c/fbe04b49a54e31f4321d632270207f0e6304cd16
Modified: 2025-09-22
CVE-2022-49248
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction
AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA:
firewire-lib: Add support for deferred transaction") while 'deferrable'
flag can be uninitialized for non-control/notify AV/C transactions.
UBSAN reports it:
kernel: ================================================================================
kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9
kernel: load of value 158 is not a valid value for type '_Bool'
kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu
kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019
kernel: Call Trace:
kernel:
- https://git.kernel.org/stable/c/39d2c4a33dc1b4402cec68a3c8f82c6588b6edce
- https://git.kernel.org/stable/c/60e5d391805d70458a01998de00d0c28cba40bf3
- https://git.kernel.org/stable/c/7025f40690a235a118c87674cfb93072694aa66d
- https://git.kernel.org/stable/c/7e6f5786621df060f8296f074efd275eaf20361a
- https://git.kernel.org/stable/c/99582e4b19f367fa95bdd150b3034d7ce8113342
- https://git.kernel.org/stable/c/b2b65c9013dc28836d82e25d0f0c94d794a14aba
- https://git.kernel.org/stable/c/bf0cd60b7e33cf221fbe1114e4acb2c828b0af0d
- https://git.kernel.org/stable/c/d07e4bbaff6fbba6f70c04b092ea7d9afcdf392e
- https://git.kernel.org/stable/c/eab74c41612083bd627b60da650e19234e4f1051
Modified: 2025-09-22
CVE-2022-49249
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wc938x: fix accessing array out of bounds for enum type Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes. Fix this by using enumerated items instead of integers.
Modified: 2025-09-22
CVE-2022-49250
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: rx-macro: fix accessing compander for aux AUX interpolator does not have compander, so check before accessing compander data for this. Without this checkan array of out bounds access will be made in comp_enabled[] array.
Modified: 2025-09-22
CVE-2022-49251
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: va-macro: fix accessing array out of bounds for enum type Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes.
Modified: 2025-09-22
CVE-2022-49252
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes.
Modified: 2025-09-22
CVE-2022-49253
In the Linux kernel, the following vulnerability has been resolved: media: usb: go7007: s2250-board: fix leak in probe() Call i2c_unregister_device(audio) on this error path.
- https://git.kernel.org/stable/c/14cd5a8e61c654828a1f1056d56f0b0a524d2c69
- https://git.kernel.org/stable/c/44973633b0064c46083833b55dd0a45e6235f8ca
- https://git.kernel.org/stable/c/67e4550ecd6164bfbdff54c169e5bbf9ccfaf14d
- https://git.kernel.org/stable/c/895364fa97e60749855f789bc4568883fc7a8b39
- https://git.kernel.org/stable/c/948ad5e5624487079c24cb5c81c74ddd02832440
- https://git.kernel.org/stable/c/a97130cd5b0c00eec169b10a16d922b9ea67324a
- https://git.kernel.org/stable/c/b5470f3efa530b10296257bb578ce4b1769e9a04
- https://git.kernel.org/stable/c/b7dd177225355da55f8d80d8e568928e0eec3608
- https://git.kernel.org/stable/c/bbdd0e15738336e6b1208304ae98525117877bbd
Modified: 2025-09-22
CVE-2022-49254
In the Linux kernel, the following vulnerability has been resolved: media: ti-vpe: cal: Fix a NULL pointer dereference in cal_ctx_v4l2_init_formats() In cal_ctx_v4l2_init_formats(), devm_kzalloc() is assigned to ctx->active_fmt and there is a dereference of it after that, which could lead to NULL pointer dereference on failure of devm_kzalloc(). Fix this bug by adding a NULL check of ctx->active_fmt. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code.
Modified: 2025-10-21
CVE-2022-49255
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix missing free nid in f2fs_handle_failed_inode
This patch fixes xfstests/generic/475 failure.
[ 293.680694] F2FS-fs (dm-1): May loss orphan inode, run fsck to fix.
[ 293.685358] Buffer I/O error on dev dm-1, logical block 8388592, async page read
[ 293.691527] Buffer I/O error on dev dm-1, logical block 8388592, async page read
[ 293.691764] sh (7615): drop_caches: 3
[ 293.691819] sh (7616): drop_caches: 3
[ 293.694017] Buffer I/O error on dev dm-1, logical block 1, async page read
[ 293.695659] sh (7618): drop_caches: 3
[ 293.696979] sh (7617): drop_caches: 3
[ 293.700290] sh (7623): drop_caches: 3
[ 293.708621] sh (7626): drop_caches: 3
[ 293.711386] sh (7628): drop_caches: 3
[ 293.711825] sh (7627): drop_caches: 3
[ 293.716738] sh (7630): drop_caches: 3
[ 293.719613] sh (7632): drop_caches: 3
[ 293.720971] sh (7633): drop_caches: 3
[ 293.727741] sh (7634): drop_caches: 3
[ 293.730783] sh (7636): drop_caches: 3
[ 293.732681] sh (7635): drop_caches: 3
[ 293.732988] sh (7637): drop_caches: 3
[ 293.738836] sh (7639): drop_caches: 3
[ 293.740568] sh (7641): drop_caches: 3
[ 293.743053] sh (7640): drop_caches: 3
[ 293.821889] ------------[ cut here ]------------
[ 293.824654] kernel BUG at fs/f2fs/node.c:3334!
[ 293.826226] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 293.828713] CPU: 0 PID: 7653 Comm: umount Tainted: G OE 5.17.0-rc1-custom #1
[ 293.830946] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 293.832526] RIP: 0010:f2fs_destroy_node_manager+0x33f/0x350 [f2fs]
[ 293.833905] Code: e8 d6 3d f9 f9 48 8b 45 d0 65 48 2b 04 25 28 00 00 00 75 1a 48 81 c4 28 03 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b
[ 293.837783] RSP: 0018:ffffb04ec31e7a20 EFLAGS: 00010202
[ 293.839062] RAX: 0000000000000001 RBX: ffff9df947db2eb8 RCX: 0000000080aa0072
[ 293.840666] RDX: 0000000000000000 RSI: ffffe86c0432a140 RDI: ffffffffc0b72a21
[ 293.842261] RBP: ffffb04ec31e7d70 R08: ffff9df94ca85780 R09: 0000000080aa0072
[ 293.843909] R10: ffff9df94ca85700 R11: ffff9df94e1ccf58 R12: ffff9df947db2e00
[ 293.845594] R13: ffff9df947db2ed0 R14: ffff9df947db2eb8 R15: ffff9df947db2eb8
[ 293.847855] FS: 00007f5a97379800(0000) GS:ffff9dfa77c00000(0000) knlGS:0000000000000000
[ 293.850647] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 293.852940] CR2: 00007f5a97528730 CR3: 000000010bc76005 CR4: 0000000000370ef0
[ 293.854680] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 293.856423] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 293.858380] Call Trace:
[ 293.859302]
- https://git.kernel.org/stable/c/005f9cdab70c915702254c5eb67a8efced80e821
- https://git.kernel.org/stable/c/1a11a873749c6375bb668953fa1a196d8538d26b
- https://git.kernel.org/stable/c/2fef99b8372c1ae3d8445ab570e888b5a358dbe9
- https://git.kernel.org/stable/c/8579b413af100ec5f3592bd6cf11559312b380c0
- https://git.kernel.org/stable/c/aa80bf73e3b3fb7026d343c77b3ddc849e26a095
- https://git.kernel.org/stable/c/d1eaaf6cadedf638e17017b0a04d56308405ac10
Modified: 2025-09-22
CVE-2022-49256
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Actually free the watch
free_watch() does everything barring actually freeing the watch object. Fix
this by adding the missing kfree.
kmemleak produces a report something like the following. Note that as an
address can be seen in the first word, the watch would appear to have gone
through call_rcu().
BUG: memory leak
unreferenced object 0xffff88810ce4a200 (size 96):
comm "syz-executor352", pid 3605, jiffies 4294947473 (age 13.720s)
hex dump (first 32 bytes):
e0 82 48 0d 81 88 ff ff 00 00 00 00 00 00 00 00 ..H.............
80 a2 e4 0c 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/31824613a42aacdcbeb325bf07a1c8247a11ebe2
- https://git.kernel.org/stable/c/3d8dcf278b1ee1eff1e90be848fa2237db4c07a7
- https://git.kernel.org/stable/c/7e8c9b0df07a77f0d072603b8ced2677e30e1893
- https://git.kernel.org/stable/c/9d92be1a09fbb3dd65600dbfe7eedb40e7228e4b
- https://git.kernel.org/stable/c/f69aecb49968e14196366bbe896eab0a904229f5
Modified: 2025-09-22
CVE-2022-49257
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix NULL dereference in error cleanup
In watch_queue_set_size(), the error cleanup code doesn't take account of
the fact that __free_page() can't handle a NULL pointer when trying to free
up buffer pages that did get allocated.
Fix this by only calling __free_page() on the pages actually allocated.
Without the fix, this can lead to something like the following:
BUG: KASAN: null-ptr-deref in __free_pages+0x1f/0x1b0 mm/page_alloc.c:5473
Read of size 4 at addr 0000000000000034 by task syz-executor168/3599
...
Call Trace:
- https://git.kernel.org/stable/c/112a2f9b0a8457794095a0450598f150724ec456
- https://git.kernel.org/stable/c/5ae75b4ed30322b42abaa75ef1b784addfdb7dc9
- https://git.kernel.org/stable/c/695c47cea02b9101e2fc2e7d36d552128592b347
- https://git.kernel.org/stable/c/a635415a064e77bcfbf43da413fd9dfe0bbed9cb
- https://git.kernel.org/stable/c/b6f5ad3e45d19f9c4ee3e8a2aff829f28d68591d
Modified: 2025-03-25
CVE-2022-49258
In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - Fix use after free in cc_cipher_exit() kfree_sensitive(ctx_p->user.key) will free the ctx_p->user.key. But ctx_p->user.key is still used in the next line, which will lead to a use after free. We can call kfree_sensitive() after dev_dbg() to avoid the uaf.
- https://git.kernel.org/stable/c/25c358efee5153dfd240d4e0d3169d5bebe9cacd
- https://git.kernel.org/stable/c/335bf1fc74f775a8255257aa3e33763f2257b676
- https://git.kernel.org/stable/c/3d950c34074ed74d2713c3856ba01264523289e6
- https://git.kernel.org/stable/c/c93017c8d5ebf55a4e453ac7c84cc84cf92ab570
- https://git.kernel.org/stable/c/cffb5382bd8d3cf21b874ab5b84bf7618932286b
Modified: 2025-10-21
CVE-2022-49259
In the Linux kernel, the following vulnerability has been resolved: block: don't delete queue kobject before its children kobjects aren't supposed to be deleted before their child kobjects are deleted. Apparently this is usually benign; however, a WARN will be triggered if one of the child kobjects has a named attribute group: sysfs group 'modes' not found for kobject 'crypto' WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80 ... Call Trace: sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312 __kobject_del+0x20/0x80 lib/kobject.c:611 kobject_cleanup+0xa4/0x140 lib/kobject.c:696 kobject_release lib/kobject.c:736 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x53/0x70 lib/kobject.c:753 blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159 blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962 del_gendisk+0x117/0x250 block/genhd.c:610 Fix this by moving the kobject_del() and the corresponding kobject_uevent() to the correct place.
- https://git.kernel.org/stable/c/0b5924a14d64487ebd51127b0358d06066ef5384
- https://git.kernel.org/stable/c/0f69288253e9fc7c495047720e523b9f1aba5712
- https://git.kernel.org/stable/c/3d7e32c8da45957326f56937e0471c686d1a7711
- https://git.kernel.org/stable/c/84fe3ca6e7910beb47ec13509d484f84fa2a41ad
- https://git.kernel.org/stable/c/b2001eb10f59363da930cdd6e086a2861986fa18
- https://git.kernel.org/stable/c/cf0cb8686e55d9c022944bc6ba9e19e832889e83
- https://git.kernel.org/stable/c/efaa0e969261e97c1fdd8e0338e5dd3ba5b9219c
Modified: 2025-10-21
CVE-2022-49260
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - fix the aead software fallback for engine Due to the subreq pointer misuse the private context memory. The aead soft crypto occasionally casues the OS panic as setting the 64K page. Here is fix it.
Modified: 2025-09-22
CVE-2022-49261
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: add missing boundary check in vm_access
A missing bounds check in vm_access() can lead to an out-of-bounds read
or write in the adjacent memory area, since the len attribute is not
validated before the memcpy later in the function, potentially hitting:
[ 183.637831] BUG: unable to handle page fault for address: ffffc90000c86000
[ 183.637934] #PF: supervisor read access in kernel mode
[ 183.637997] #PF: error_code(0x0000) - not-present page
[ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0
[ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI
[ 183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G D 5.17.0-rc6-ci-drm-11296+ #1
[ 183.638298] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 05/30/2019
[ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10
[ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246
[ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc
[ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004
[ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000
[ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 0000000000001000
[ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000
[ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000
[ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0
[ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 183.650142] Call Trace:
[ 183.650988]
- https://git.kernel.org/stable/c/312d3d4f49e12f97260bcf972c848c3562126a18
- https://git.kernel.org/stable/c/3886a86e7e6cc6ce2ce93c440fecd8f42aed0ce7
- https://git.kernel.org/stable/c/5f6e560e3e86ac053447524224e411034f41f5c7
- https://git.kernel.org/stable/c/89ddcc81914ab58cc203acc844f27d55ada8ec0e
- https://git.kernel.org/stable/c/8f0ebea8f6e8c474264ed97d7a64c9c09ed4f5aa
Modified: 2025-09-22
CVE-2022-49262
In the Linux kernel, the following vulnerability has been resolved: crypto: octeontx2 - remove CONFIG_DM_CRYPT check No issues were found while using the driver with dm-crypt enabled. So CONFIG_DM_CRYPT check in the driver can be removed. This also fixes the NULL pointer dereference in driver release if CONFIG_DM_CRYPT is enabled. ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... Call trace: crypto_unregister_alg+0x68/0xfc crypto_unregister_skciphers+0x44/0x60 otx2_cpt_crypto_exit+0x100/0x1a0 otx2_cptvf_remove+0xf8/0x200 pci_device_remove+0x3c/0xd4 __device_release_driver+0x188/0x234 device_release_driver+0x2c/0x4c ...
Modified: 2025-09-22
CVE-2022-49263
In the Linux kernel, the following vulnerability has been resolved: brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that the CLM blob is released in the device remove path.
- https://git.kernel.org/stable/c/0347bdfdb1529994ac3a4cb425087c477a74eb2c
- https://git.kernel.org/stable/c/4e0b507597e1a86e9b4c056ab274c427223cf8ea
- https://git.kernel.org/stable/c/5e90f0f3ead014867dade7a22f93958119f5efab
- https://git.kernel.org/stable/c/a88337a06966f2d733ad9a97714b874469133f14
- https://git.kernel.org/stable/c/d0ab87f8dcdfe72dc1d763be3392c1fc51a1ace2
- https://git.kernel.org/stable/c/f3820ddaf4f3ac80c7401ccc6a42e663c9317f31
Modified: 2025-10-21
CVE-2022-49264
In the Linux kernel, the following vulnerability has been resolved: exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0 [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/
- https://git.kernel.org/stable/c/1290eb4412aa0f0e9f3434b406dc8e255da85f9e
- https://git.kernel.org/stable/c/1fe82bfd9e4ce93399d815ca458b58505191c3e8
- https://git.kernel.org/stable/c/27a6f495b63a1804cc71be45911065db7757a98c
- https://git.kernel.org/stable/c/41f6ea5b9aaa28b740d47ffe995a5013211fdbb0
- https://git.kernel.org/stable/c/98e0c7c702894987732776736c99b85ade6fba45
- https://git.kernel.org/stable/c/a8054d3fa5deb84b215d6be1b910a978f3cb840d
- https://git.kernel.org/stable/c/b50fb8dbc8b81aaa126387de428f4c42a7c72a73
- https://git.kernel.org/stable/c/cfbfff8ce5e3d674947581f1eb9af0a1b1807950
- https://git.kernel.org/stable/c/dcd46d897adb70d63e025f175a00a89797d31a43
Modified: 2025-10-21
CVE-2022-49265
In the Linux kernel, the following vulnerability has been resolved: PM: domains: Fix sleep-in-atomic bug caused by genpd_debug_remove() When a genpd with GENPD_FLAG_IRQ_SAFE gets removed, the following sleep-in-atomic bug will be seen, as genpd_debug_remove() will be called with a spinlock being held. [ 0.029183] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1460 [ 0.029204] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0 [ 0.029219] preempt_count: 1, expected: 0 [ 0.029230] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc4+ #489 [ 0.029245] Hardware name: Thundercomm TurboX CM2290 (DT) [ 0.029256] Call trace: [ 0.029265] dump_backtrace.part.0+0xbc/0xd0 [ 0.029285] show_stack+0x3c/0xa0 [ 0.029298] dump_stack_lvl+0x7c/0xa0 [ 0.029311] dump_stack+0x18/0x34 [ 0.029323] __might_resched+0x10c/0x13c [ 0.029338] __might_sleep+0x4c/0x80 [ 0.029351] down_read+0x24/0xd0 [ 0.029363] lookup_one_len_unlocked+0x9c/0xcc [ 0.029379] lookup_positive_unlocked+0x10/0x50 [ 0.029392] debugfs_lookup+0x68/0xac [ 0.029406] genpd_remove.part.0+0x12c/0x1b4 [ 0.029419] of_genpd_remove_last+0xa8/0xd4 [ 0.029434] psci_cpuidle_domain_probe+0x174/0x53c [ 0.029449] platform_probe+0x68/0xe0 [ 0.029462] really_probe+0x190/0x430 [ 0.029473] __driver_probe_device+0x90/0x18c [ 0.029485] driver_probe_device+0x40/0xe0 [ 0.029497] __driver_attach+0xf4/0x1d0 [ 0.029508] bus_for_each_dev+0x70/0xd0 [ 0.029523] driver_attach+0x24/0x30 [ 0.029534] bus_add_driver+0x164/0x22c [ 0.029545] driver_register+0x78/0x130 [ 0.029556] __platform_driver_register+0x28/0x34 [ 0.029569] psci_idle_init_domains+0x1c/0x28 [ 0.029583] do_one_initcall+0x50/0x1b0 [ 0.029595] kernel_init_freeable+0x214/0x280 [ 0.029609] kernel_init+0x2c/0x13c [ 0.029622] ret_from_fork+0x10/0x20 It doesn't seem necessary to call genpd_debug_remove() with the lock, so move it out from locking to fix the problem.
Modified: 2025-10-21
CVE-2022-49266
In the Linux kernel, the following vulnerability has been resolved: block: fix rq-qos breakage from skipping rq_qos_done_bio() a647a524a467 ("block: don't call rq_qos_ops->done_bio if the bio isn't tracked") made bio_endio() skip rq_qos_done_bio() if BIO_TRACKED is not set. While this fixed a potential oops, it also broke blk-iocost by skipping the done_bio callback for merged bios. Before, whether a bio goes through rq_qos_throttle() or rq_qos_merge(), rq_qos_done_bio() would be called on the bio on completion with BIO_TRACKED distinguishing the former from the latter. rq_qos_done_bio() is not called for bios which wenth through rq_qos_merge(). This royally confuses blk-iocost as the merged bios never finish and are considered perpetually in-flight. One reliably reproducible failure mode is an intermediate cgroup geting stuck active preventing its children from being activated due to the leaf-only rule, leading to loss of control. The following is from resctl-bench protection scenario which emulates isolating a web server like workload from a memory bomb run on an iocost configuration which should yield a reasonable level of protection. # cat /sys/block/nvme2n1/device/model Samsung SSD 970 PRO 512GB # cat /sys/fs/cgroup/io.cost.model 259:0 ctrl=user model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025 # cat /sys/fs/cgroup/io.cost.qos 259:0 enable=1 ctrl=user rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 min=60.00 max=100.00 # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Memory Hog Summary ================== IO Latency: R p50=242u:336u/2.5m p90=794u:1.4m/7.5m p99=2.7m:8.0m/62.5m max=8.0m:36.4m/350m W p50=221u:323u/1.5m p90=709u:1.2m/5.5m p99=1.5m:2.5m/9.5m max=6.9m:35.9m/350m Isolation and Request Latency Impact Distributions: min p01 p05 p10 p25 p50 p75 p90 p95 p99 max mean stdev isol% 15.90 15.90 15.90 40.05 57.24 59.07 60.01 74.63 74.63 90.35 90.35 58.12 15.82 lat-imp% 0 0 0 0 0 4.55 14.68 15.54 233.5 548.1 548.1 53.88 143.6 Result: isol=58.12:15.82% lat_imp=53.88%:143.6 work_csv=100.0% missing=3.96% The isolation result of 58.12% is close to what this device would show without any IO control. Fix it by introducing a new flag BIO_QOS_MERGED to mark merged bios and calling rq_qos_done_bio() on them too. For consistency and clarity, rename BIO_TRACKED to BIO_QOS_THROTTLED. The flag checks are moved into rq_qos_done_bio() so that it's next to the code paths that set the flags. With the patch applied, the above same benchmark shows: # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Memory Hog Summary ================== IO Latency: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m max=11.1m:36.0m/350m W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m max=7.9m:5.9m/26.5m Isolation and Request Latency Impact Distributions: min p01 p05 p10 p25 p50 p75 p90 p95 p99 max mean stdev isol% 84.91 84.91 89.51 90.73 92.31 94.49 96.36 98.04 98.71 100.0 100.0 94.42 2.81 lat-imp% 0 0 0 0 0 2.81 5.73 11.11 13.92 17.53 22.61 4.10 4.68 Result: isol=94.42:2.81% lat_imp=4.10%:4.68 work_csv=58.34% missing=0%
Modified: 2025-09-22
CVE-2022-49268
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: Fix NULL ptr dereference when ENOMEM
Do not call snd_dma_free_pages() when snd_dma_alloc_pages() returns
-ENOMEM because it leads to a NULL pointer dereference bug.
The dmesg says:
[ T1387] sof-audio-pci-intel-tgl 0000:00:1f.3: error: memory alloc failed: -12
[ T1387] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ T1387] #PF: supervisor read access in kernel mode
[ T1387] #PF: error_code(0x0000) - not-present page
[ T1387] PGD 0 P4D 0
[ T1387] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ T1387] CPU: 6 PID: 1387 Comm: alsa-sink-HDA A Tainted: G W 5.17.0-rc4-superb-owl-00055-g80d47f5de5e3
[ T1387] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 09/15/2021
[ T1387] RIP: 0010:dma_free_noncontiguous+0x37/0x80
[ T1387] Code: [... snip ...]
[ T1387] RSP: 0000:ffffc90002b87770 EFLAGS: 00010246
[ T1387] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ T1387] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888101db30d0
[ T1387] RBP: 00000000fffffff4 R08: 0000000000000000 R09: 0000000000000000
[ T1387] R10: 0000000000000000 R11: ffffc90002b874d0 R12: 0000000000000001
[ T1387] R13: 0000000000058000 R14: ffff888105260c68 R15: ffff888105260828
[ T1387] FS: 00007f42e2ffd640(0000) GS:ffff888466b80000(0000) knlGS:0000000000000000
[ T1387] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ T1387] CR2: 0000000000000000 CR3: 000000014acf0003 CR4: 0000000000770ee0
[ T1387] PKRU: 55555554
[ T1387] Call Trace:
[ T1387]
- https://git.kernel.org/stable/c/01df5f7627f1624d6bb0b8c0870a569b32adfbf8
- https://git.kernel.org/stable/c/09eca322d4118dc26570ca6100fa34e59e5a5143
- https://git.kernel.org/stable/c/0c307349fe060971625b856c92f0361b8ea9a120
- https://git.kernel.org/stable/c/67f7bd9ff9079c1ee2de58e024fb582905c74c16
- https://git.kernel.org/stable/c/b6094744e261083d3790c3def770ebf5060d383b
- https://git.kernel.org/stable/c/b7fb0ae09009d076964afe4c1a2bde1ee2bd88a9
Modified: 2025-10-21
CVE-2022-49269
In the Linux kernel, the following vulnerability has been resolved: can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks.
- https://git.kernel.org/stable/c/3ea566422cbde9610c2734980d1286ab681bb40e
- https://git.kernel.org/stable/c/7b4652fc71dcec043977a6def80ef5034c913615
- https://git.kernel.org/stable/c/cf522d741f5301223cc94b978eb1603c7590d65e
- https://git.kernel.org/stable/c/d72866a7f5326160d2a9d945a33eb6ef1883e25d
- https://git.kernel.org/stable/c/f343dbe82314ab457153c9afd970be4e9e553020
Modified: 2025-03-25
CVE-2022-49270
In the Linux kernel, the following vulnerability has been resolved:
dm: fix use-after-free in dm_cleanup_zoned_dev()
dm_cleanup_zoned_dev() uses queue, so it must be called
before blk_cleanup_disk() starts its killing:
blk_cleanup_disk->blk_cleanup_queue()->kobject_put()->blk_release_queue()->
->...RCU...->blk_free_queue_rcu()->kmem_cache_free()
Otherwise, RCU callback may be executed first and
dm_cleanup_zoned_dev() will touch free'd memory:
BUG: KASAN: use-after-free in dm_cleanup_zoned_dev+0x33/0xd0
Read of size 8 at addr ffff88805ac6e430 by task dmsetup/681
CPU: 4 PID: 681 Comm: dmsetup Not tainted 5.17.0-rc2+ #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
Modified: 2025-09-22
CVE-2022-49271
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent bad output lengths in smb2_ioctl_query_info()
When calling smb2_ioctl_query_info() with
smb_query_info::flags=PASSTHRU_FSCTL and
smb_query_info::output_buffer_length=0, the following would return
0x10
buffer = memdup_user(arg + sizeof(struct smb_query_info),
qi.output_buffer_length);
if (IS_ERR(buffer)) {
kfree(vars);
return PTR_ERR(buffer);
}
rather than a valid pointer thus making IS_ERR() check fail. This
would then cause a NULL ptr deference in @buffer when accessing it
later in smb2_ioctl_query_ioctl(). While at it, prevent having a
@buffer smaller than 8 bytes to correctly handle SMB2_SET_INFO
FileEndOfFileInformation requests when
smb_query_info::flags=PASSTHRU_SET_INFO.
Here is a small C reproducer which triggers a NULL ptr in @buffer when
passing an invalid smb_query_info::flags
#include
- https://git.kernel.org/stable/c/7529fbee10d82493c5cb109e51788bf74816d1c0
- https://git.kernel.org/stable/c/9963ccea6087268e1275b992dca5d0dd4b938765
- https://git.kernel.org/stable/c/b92e358757b91c2827af112cae9af513f26a3f34
- https://git.kernel.org/stable/c/f143f8334fb9eb2f6c7c15b9da1472d9c965fd84
- https://git.kernel.org/stable/c/fadddfc1dc3c6f79b21cff4a7e9a6c40b84fbc53
Modified: 2025-10-01
CVE-2022-49273
In the Linux kernel, the following vulnerability has been resolved: rtc: pl031: fix rtc features null pointer dereference When there is no interrupt line, rtc alarm feature is disabled. The clearing of the alarm feature bit was being done prior to allocations of ldata->rtc device, resulting in a null pointer dereference. Clear RTC_FEATURE_ALARM after the rtc device is allocated.
Modified: 2025-09-22
CVE-2022-49274
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix crash when mount with quota enabled There is a reported crash when mounting ocfs2 with quota enabled. RIP: 0010:ocfs2_qinfo_lock_res_init+0x44/0x50 [ocfs2] Call Trace: ocfs2_local_read_info+0xb9/0x6f0 [ocfs2] dquot_load_quota_sb+0x216/0x470 dquot_load_quota_inode+0x85/0x100 ocfs2_enable_quotas+0xa0/0x1c0 [ocfs2] ocfs2_fill_super.cold+0xc8/0x1bf [ocfs2] mount_bdev+0x185/0x1b0 legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 path_mount+0x465/0xac0 __x64_sys_mount+0x103/0x140 It is caused by when initializing dqi_gqlock, the corresponding dqi_type and dqi_sb are not properly initialized. This issue is introduced by commit 6c85c2c72819, which wants to avoid accessing uninitialized variables in error cases. So make global quota info properly initialized.
Modified: 2025-03-25
CVE-2022-49275
In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_tx_handler(): fix use after free of skb can_put_echo_skb() will clone skb then free the skb. Move the can_put_echo_skb() for the m_can version 3.0.x directly before the start of the xmit in hardware, similar to the 3.1.x branch.
- https://git.kernel.org/stable/c/08d90846e438ac22dc56fc49ec0b0d195831c5ed
- https://git.kernel.org/stable/c/2e8e79c416aae1de224c0f1860f2e3350fa171f8
- https://git.kernel.org/stable/c/31417073493f302d26ab66b3abc098d43227b835
- https://git.kernel.org/stable/c/4db7d6f481990dd179a9ee7126dc7aa31ea4fff3
- https://git.kernel.org/stable/c/7728d937ec403a1ceff9483023252d2cb8777f81
- https://git.kernel.org/stable/c/869016a2938ac44f7b2fb7fc22c89edad99eb9b3
- https://git.kernel.org/stable/c/d3892a747ab16b1eb6593a19d29f62c3b3f020ac
- https://git.kernel.org/stable/c/d93ed9aff64968f4cdad690712eb4f48ae537bde
- https://git.kernel.org/stable/c/f43e64076ff1b1dcb893fb77ad1204105f710a29
Modified: 2025-10-01
CVE-2022-49276
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_scan_medium
If an error is returned in jffs2_scan_eraseblock() and some memory
has been added to the jffs2_summary *s, we can observe the following
kmemleak report:
--------------------------------------------
unreferenced object 0xffff88812b889c40 (size 64):
comm "mount", pid 692, jiffies 4294838325 (age 34.288s)
hex dump (first 32 bytes):
40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.
00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................
backtrace:
[
- https://git.kernel.org/stable/c/455f4a23490bfcbedc8e5c245c463a59b19e5ddd
- https://git.kernel.org/stable/c/51dbb5e36d59f62e34d462b801c1068248149cfe
- https://git.kernel.org/stable/c/52ba0ab4f0a606f02a6163493378989faa1ec10a
- https://git.kernel.org/stable/c/82462324bf35b6b553400af1c1aa265069cee28f
- https://git.kernel.org/stable/c/9b0c69182f09b70779817af4dcf89780955d5c4c
- https://git.kernel.org/stable/c/9cdd3128874f5fe759e2c4e1360ab7fb96a8d1df
- https://git.kernel.org/stable/c/b26bbc0c122cad038831f226a4cb4de702225e16
- https://git.kernel.org/stable/c/b36bccb04e14cc0c1e2d0e92d477fe220314fad6
- https://git.kernel.org/stable/c/e711913463af916d777a4873068f415f1fe2ad33
Modified: 2025-10-01
CVE-2022-49277
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_mount_fs
If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,
we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff88811b25a640 (size 64):
comm "mount", pid 691, jiffies 4294957728 (age 71.952s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/0978e9af4559a171ac7a74a1b3ef21804b0a0fa9
- https://git.kernel.org/stable/c/2a9d8184458562e6bf2f40d0e677fc85e2dd3834
- https://git.kernel.org/stable/c/4392e8aeebc5a4f8073620bccba7de1b1f6d7c88
- https://git.kernel.org/stable/c/5f34310d1376ca5b2ed798258def2c2ab3cc6699
- https://git.kernel.org/stable/c/607d3aab7349f18e0d9dba4100d09d16fe27caca
- https://git.kernel.org/stable/c/9a0f6610c7daedd2eace430beeb08a8b7ac80699
- https://git.kernel.org/stable/c/c94128470e6fe53d9bd9d16d2d3271813f9d37af
- https://git.kernel.org/stable/c/d051cef784de4d54835f6b6836d98a8f6935772c
- https://git.kernel.org/stable/c/dbe0d0521eaa6a3d235517319266c539bb5c5112
Modified: 2025-09-22
CVE-2022-49278
In the Linux kernel, the following vulnerability has been resolved: remoteproc: Fix count check in rproc_coredump_write() Check count for 0, to avoid a potential underflow. Make the check the same as the one in rproc_recovery_write().
- https://git.kernel.org/stable/c/11572dad9fbadbd9269a2550f7e236b5b8c2d80c
- https://git.kernel.org/stable/c/34afac3c75fa08d6fabbab4c93f0a90618afaaa6
- https://git.kernel.org/stable/c/a8c3e53517985d69040a1b36a269e85f99cf0cea
- https://git.kernel.org/stable/c/b97b305656a7013690e7b6e310f0e827e0bbff90
- https://git.kernel.org/stable/c/f89672cc3681952f2d06314981a6b45f8b0045d1
Modified: 2025-10-01
CVE-2022-49279
In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent integer overflow on 32 bit systems On a 32 bit system, the "len * sizeof(*p)" operation can have an integer overflow.
- https://git.kernel.org/stable/c/23a9dbbe0faf124fc4c139615633b9d12a3a89ef
- https://git.kernel.org/stable/c/303cd6173dce0a28d26526c77814eb90a41bd898
- https://git.kernel.org/stable/c/3a2789e8ccb4a3e2a631f6817a2d3bb98b8c4fd8
- https://git.kernel.org/stable/c/79b1c54fc6ce09ee0d5fe088bb3de26ae2150e3c
- https://git.kernel.org/stable/c/7af164fa2f1abc577d357d22d83a2f3490875d7e
- https://git.kernel.org/stable/c/ce1aa09cc14ed625104acc2d487bd92b9a88efe2
- https://git.kernel.org/stable/c/e4195d27306ea468a6dc3a27af6f586709951229
Modified: 2025-12-23
CVE-2022-49280
In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent underflow in nfssvc_decode_writeargs() Smatch complains: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() warn: no lower bound on 'args->len' Change the type to unsigned to prevent this issue.
Modified: 2025-10-21
CVE-2022-49281
In the Linux kernel, the following vulnerability has been resolved: cifs: fix handlecache and multiuser In multiuser each individual user has their own tcon structure for the share and thus their own handle for a cached directory. When we umount such a share we much make sure to release the pinned down dentry for each such tcon and not just the master tcon. Otherwise we will get nasty warnings on umount that dentries are still in use: [ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\ (2) [unmount of cifs cifs] ... [ 3459.590492] Call Trace: [ 3459.590500] d_walk+0x61/0x2a0 [ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0 [ 3459.590526] shrink_dcache_for_umount+0x49/0x110 [ 3459.590535] generic_shutdown_super+0x1a/0x110 [ 3459.590542] kill_anon_super+0x14/0x30 [ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs] [ 3459.590773] deactivate_locked_super+0x36/0xa0 [ 3459.590782] cleanup_mnt+0x131/0x190 [ 3459.590789] task_work_run+0x5c/0x90 [ 3459.590798] exit_to_user_mode_loop+0x151/0x160 [ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0 [ 3459.590818] syscall_exit_to_user_mode+0x12/0x30 [ 3459.590828] do_syscall_64+0x48/0x90 [ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae
Modified: 2025-10-01
CVE-2022-49282
In the Linux kernel, the following vulnerability has been resolved: f2fs: quota: fix loop condition at f2fs_quota_sync() cnt should be passed to sb_has_quota_active() instead of type to check active quota properly. Moreover, when the type is -1, the compiler with enough inline knowledge can discard sb_has_quota_active() check altogether, causing a NULL pointer dereference at the following inode_lock(dqopt->files[cnt]): [ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 2.796024] Mem abort info: [ 2.796025] ESR = 0x96000005 [ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.796029] SET = 0, FnV = 0 [ 2.796031] EA = 0, S1PTW = 0 [ 2.796032] Data abort info: [ 2.796034] ISV = 0, ISS = 0x00000005 [ 2.796035] CM = 0, WnR = 0 [ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000 [ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000 [ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1 [ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT) [ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 2.796065] pc : down_write+0x28/0x70 [ 2.796070] lr : f2fs_quota_sync+0x100/0x294 [ 2.796071] sp : ffffffa3f48ffc30 [ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000 [ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80 [ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001 [ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000 [ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110 [ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038 [ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0 [ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0 [ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000 [ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948 [ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0 [ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a [ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d [ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001 [ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0 [ 2.796098] Call trace: [ 2.796100] down_write+0x28/0x70 [ 2.796102] f2fs_quota_sync+0x100/0x294 [ 2.796104] block_operations+0x120/0x204 [ 2.796106] f2fs_write_checkpoint+0x11c/0x520 [ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34 [ 2.796109] issue_checkpoint_thread+0x6c/0xb8 [ 2.796112] kthread+0x138/0x414 [ 2.796114] ret_from_fork+0x10/0x18 [ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02) [ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]--- [ 2.800116] Kernel panic - not syncing: Fatal exception [ 2.800120] SMP: stopping secondary CPUs
- https://git.kernel.org/stable/c/680af5b824a52faa819167628665804a14f0e0df
- https://git.kernel.org/stable/c/724469814d805820cd37ea789769dba94123ff1a
- https://git.kernel.org/stable/c/e58ee6bd939b773675240f5d0f5b88a367c037c4
- https://git.kernel.org/stable/c/e9ebf1e8fc50b6a9336f9aea1082d7845e568d0e
- https://git.kernel.org/stable/c/f1d5946d47c0827bae39e1537959ce8d6f0224c5
- https://git.kernel.org/stable/c/f9156db0987f1b426015d56505e2c58dee70c90d
Modified: 2025-09-22
CVE-2022-49283
In the Linux kernel, the following vulnerability has been resolved: firmware: sysfb: fix platform-device leak in error path Make sure to free the platform device also in the unlikely event that registration fails.
Modified: 2025-10-01
CVE-2022-49284
In the Linux kernel, the following vulnerability has been resolved: coresight: syscfg: Fix memleak on registration failure in cscfg_create_device device_register() calls device_initialize(), according to doc of device_initialize: Use put_device() to give up your reference instead of freeing * @dev directly once you have called this function. To prevent potential memleak, use put_device() for error handling.
Modified: 2025-09-22
CVE-2022-49285
In the Linux kernel, the following vulnerability has been resolved: iio: accel: mma8452: use the correct logic to get mma8452_data The original logic to get mma8452_data is wrong, the *dev point to the device belong to iio_dev. we can't use this dev to find the correct i2c_client. The original logic happen to work because it finally use dev->driver_data to get iio_dev. Here use the API to_i2c_client() is wrong and make reader confuse. To correct the logic, it should be like this struct mma8452_data *data = iio_priv(dev_get_drvdata(dev)); But after commit 8b7651f25962 ("iio: iio_device_alloc(): Remove unnecessary self drvdata"), the upper logic also can't work. When try to show the avialable scale in userspace, will meet kernel dump, kernel handle NULL pointer dereference. So use dev_to_iio_dev() to correct the logic. Dual fixes tags as the second reflects when the bug was exposed, whilst the first reflects when the original bug was introduced.
Modified: 2025-09-22
CVE-2022-49286
In the Linux kernel, the following vulnerability has been resolved: tpm: use try_get_ops() in tpm-space.c As part of the series conversion to remove nested TPM operations: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ exposure of the chip->tpm_mutex was removed from much of the upper level code. In this conversion, tpm2_del_space() was missed. This didn't matter much because it's usually called closely after a converted operation, so there's only a very tiny race window where the chip can be removed before the space flushing is done which causes a NULL deref on the mutex. However, there are reports of this window being hit in practice, so fix this by converting tpm2_del_space() to use tpm_try_get_ops(), which performs all the teardown checks before acquring the mutex.
- https://git.kernel.org/stable/c/476ddd23f818fb94cf86fb5617f3bb9a7c92113d
- https://git.kernel.org/stable/c/5b1d2561a03e534064b51c50c774657833d3d2cf
- https://git.kernel.org/stable/c/95193d12f10a8a088843b25e0f5fe1d83ec6b079
- https://git.kernel.org/stable/c/ba84f9a48366dcc3cdef978599433efe101dd5bd
- https://git.kernel.org/stable/c/eda1662cce964c8a65bb86321f8d9cfa6e9ceaab
- https://git.kernel.org/stable/c/fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9
Modified: 2025-03-25
CVE-2022-49287
In the Linux kernel, the following vulnerability has been resolved:
tpm: fix reference counting for struct tpm_chip
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
refcount_t: addition on 0; use-after-free.
Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac
sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4
brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes
raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm
snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]
CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2
Hardware name: BCM2711
[
- https://git.kernel.org/stable/c/290e05f346d1829e849662c97e42d5ad984f5258
- https://git.kernel.org/stable/c/2f928c0d5c02dbab49e8c19d98725c822f6fc409
- https://git.kernel.org/stable/c/473a66f99cb8173c14138c5a5c69bfad04e8f9ac
- https://git.kernel.org/stable/c/662893b4f6bd466ff9e1cd454c44c26d32d554fe
- https://git.kernel.org/stable/c/6e7baf84149fb43950631415de231b3a41915aa3
- https://git.kernel.org/stable/c/7e0438f83dc769465ee663bb5dcf8cc154940712
- https://git.kernel.org/stable/c/a27ed2f3695baf15f9b34d2d7a1f9fc105539a81
- https://git.kernel.org/stable/c/cb64bd038beacb4331fe464a36c8b5481e8f51e2
Modified: 2025-03-25
CVE-2022-49288
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix races among concurrent prealloc proc writes We have no protection against concurrent PCM buffer preallocation changes via proc files, and it may potentially lead to UAF or some weird problem. This patch applies the PCM open_mutex to the proc write operation for avoiding the racy proc writes and the PCM stream open (and further operations).
- https://git.kernel.org/stable/c/37b12c16beb6f6c1c3c678c1aacbc46525c250f7
- https://git.kernel.org/stable/c/51fce708ab8986a9879ee5da946a2cc120f1036d
- https://git.kernel.org/stable/c/5ed8f8e3c4e59d0396b9ccf2e639711e24295bb6
- https://git.kernel.org/stable/c/69534c48ba8ce552ce383b3dfdb271ffe51820c3
- https://git.kernel.org/stable/c/a21d2f323b5a978dedf9ff1d50f101f85e39b3f2
- https://git.kernel.org/stable/c/b560d670c87d7d40b3cf6949246fa4c7aa65a00a
- https://git.kernel.org/stable/c/e14dca613e0a6ddc2bf6e360f16936a9f865205b
- https://git.kernel.org/stable/c/e7786c445bb67a9a6e64f66ebd6b7215b153ff7d
Modified: 2025-09-22
CVE-2022-49289
In the Linux kernel, the following vulnerability has been resolved: uaccess: fix integer overflow on access_ok() Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not. Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.
Modified: 2025-10-01
CVE-2022-49290
In the Linux kernel, the following vulnerability has been resolved: mac80211: fix potential double free on mesh join While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") fixed a memory leak on mesh leave / teardown it introduced a potential memory corruption caused by a double free when rejoining the mesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); This double free / kernel panics can be reproduced by using wpa_supplicant with an encrypted mesh (if set up without encryption via "iw" then ifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Note that typically these commands are not used / working when using wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids the memory corruption, too. The issue was first observed in an application which was not using wpa_supplicant but "Senf" instead, which implements its own calls to nl80211. Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh join function and leaving it solely up to the mesh leave to free the mesh IE.
- https://git.kernel.org/stable/c/12e407a8ef17623823fd0c066fbd7f103953d28d
- https://git.kernel.org/stable/c/273ebddc5fda2967492cb0b6cdd7d81cfb821b76
- https://git.kernel.org/stable/c/3bbd0000d012f92aec423b224784fbf0f7bf40f8
- https://git.kernel.org/stable/c/46bb87d40683337757a2f902fcd4244b32bb4e86
- https://git.kernel.org/stable/c/4a2d4496e15ea5bb5c8e83b94ca8ca7fb045e7d3
- https://git.kernel.org/stable/c/582d8c60c0c053684f7138875e8150d5749ffc17
- https://git.kernel.org/stable/c/5d3ff9542a40ce034416bca03864709540a36016
- https://git.kernel.org/stable/c/615716af8644813355e014314a0bc1e961250f5a
- https://git.kernel.org/stable/c/c1d9c3628ef0a0ca197595d0f9e01cd3b5dda186
Modified: 2025-03-25
CVE-2022-49291
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix races among concurrent hw_params and hw_free calls Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity.
- https://git.kernel.org/stable/c/0090c13cbbdffd7da079ac56f80373a9a1be0bf8
- https://git.kernel.org/stable/c/0f6947f5f5208f6ebd4d76a82a4757e2839a23f8
- https://git.kernel.org/stable/c/1bbf82d9f961414d6c76a08f7f843ea068e0ab7b
- https://git.kernel.org/stable/c/33061d0fba51d2bf70a2ef9645f703c33fe8e438
- https://git.kernel.org/stable/c/92ee3c60ec9fe64404dc035e7c41277d74aa26cb
- https://git.kernel.org/stable/c/9cb6c40a6ebe4a0cfc9d6a181958211682cffea9
- https://git.kernel.org/stable/c/a42aa926843acca96c0dfbde2e835b8137f2f092
- https://git.kernel.org/stable/c/fbeb492694ce0441053de57699e1e2b7bc148a69
Modified: 2025-09-22
CVE-2022-49292
In the Linux kernel, the following vulnerability has been resolved: ALSA: oss: Fix PCM OSS buffer allocation overflow We've got syzbot reports hitting INT_MAX overflow at vmalloc() allocation that is called from snd_pcm_plug_alloc(). Although we apply the restrictions to input parameters, it's based only on the hw_params of the underlying PCM device. Since the PCM OSS layer allocates a temporary buffer for the data conversion, the size may become unexpectedly large when more channels or higher rates is given; in the reported case, it went over INT_MAX, hence it hits WARN_ON(). This patch is an attempt to avoid such an overflow and an allocation for too large buffers. First off, it adds the limit of 1MB as the upper bound for period bytes. This must be large enough for all use cases, and we really don't want to handle a larger temporary buffer than this size. The size check is performed at two places, where the original period bytes is calculated and where the plugin buffer size is calculated. In addition, the driver uses array_size() and array3_size() for multiplications to catch overflows for the converted period size and buffer bytes.
- https://git.kernel.org/stable/c/0c4190b41a69990666b4000999e27f8f1b2a426b
- https://git.kernel.org/stable/c/5ce74ff7059341d8b2f4d01c3383491df63d1898
- https://git.kernel.org/stable/c/7a40cbf3579a8e14849ba7ce46309c1992658d2b
- https://git.kernel.org/stable/c/a63af1baf0a5e11827db60e3127f87e437cab6e5
- https://git.kernel.org/stable/c/e74a069c6a7bb505f3ade141dddf85f4b0b5145a
- https://git.kernel.org/stable/c/efb6402c3c4a7c26d97c92d70186424097b6e366
- https://git.kernel.org/stable/c/fb08bf99195a87c798bc8ae1357337a981faeade
Modified: 2025-10-21
CVE-2022-49293
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: initialize registers in nft_do_chain() Initialize registers to avoid stack leak into userspace.
- https://git.kernel.org/stable/c/06f0ff82c70241a766a811ae1acf07d6e2734dcb
- https://git.kernel.org/stable/c/2c74374c2e88c7b7992bf808d9f9391f7452f9d9
- https://git.kernel.org/stable/c/4c905f6740a365464e91467aa50916555b28213d
- https://git.kernel.org/stable/c/4d28522acd1c4415c85f6b33463713a268f68965
- https://git.kernel.org/stable/c/64f24c76dd0ce53d0fa3a0bfb9aeea507c769485
- https://git.kernel.org/stable/c/88791b79a1eb2ba94e95d039243e28433583a67b
- https://git.kernel.org/stable/c/a3cc32863b175168283cb0a5fde08de6a1e27df9
- https://git.kernel.org/stable/c/dd03640529204ef4b8189fbdea08217d8d98271f
- https://git.kernel.org/stable/c/fafb904156fbb8f1dd34970cd5223e00b47c33be
Modified: 2025-02-13
CVE-2023-1872
A use-after-free vulnerability in the Linux Kernel io_uring system can be exploited to achieve local privilege escalation. The io_file_get_fixed function lacks the presence of ctx->uring_lock which can lead to a Use-After-Free vulnerability due a race condition with fixed files getting unregistered. We recommend upgrading past commit da24142b1ef9fd5d36b76e36bab328a5b27523e8.
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=08681391b84da27133deefaaddefd0acfa90c2be
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=da24142b1ef9fd5d36b76e36bab328a5b27523e8
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://security.netapp.com/advisory/ntap-20230601-0002/
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=08681391b84da27133deefaaddefd0acfa90c2be
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=da24142b1ef9fd5d36b76e36bab328a5b27523e8
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://security.netapp.com/advisory/ntap-20230601-0002/
Modified: 2025-05-05
CVE-2023-22995
In the Linux kernel before 5.17, an error path in dwc3_qcom_acpi_register_core in drivers/usb/dwc3/dwc3-qcom.c lacks certain platform_device_put and kfree calls.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17
- https://github.com/torvalds/linux/commit/fa0ef93868a6062babe1144df2807a8b1d4924d2
- https://security.netapp.com/advisory/ntap-20230331-0004/
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17
- https://github.com/torvalds/linux/commit/fa0ef93868a6062babe1144df2807a8b1d4924d2
- https://security.netapp.com/advisory/ntap-20230331-0004/
Modified: 2025-03-20
CVE-2023-22996
In the Linux kernel before 5.17.2, drivers/soc/qcom/qcom_aoss.c does not release an of_find_device_by_node reference after use, e.g., with put_device.
Modified: 2025-03-20
CVE-2023-23000
In the Linux kernel before 5.17, drivers/phy/tegra/xusb.c mishandles the tegra_xusb_find_port_node return value. Callers expect NULL in the error case, but an error pointer is used.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17
- https://github.com/torvalds/linux/commit/045a31b95509c8f25f5f04ec5e0dec5cd09f2c5f
- https://security.netapp.com/advisory/ntap-20230331-0004/
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17
- https://github.com/torvalds/linux/commit/045a31b95509c8f25f5f04ec5e0dec5cd09f2c5f
- https://security.netapp.com/advisory/ntap-20230331-0004/
Modified: 2025-06-25
CVE-2023-3439
A flaw was found in the MCTP protocol in the Linux kernel. The function mctp_unregister() reclaims the device's relevant resource when a netcard detaches. However, a running routine may be unaware of this and cause the use-after-free of the mdev->addrs object, potentially leading to a denial of service.
- http://www.openwall.com/lists/oss-security/2023/07/02/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2217915
- https://github.com/torvalds/linux/commit/b561275d633bcd8e0e8055ab86f1a13df75a0269
- http://www.openwall.com/lists/oss-security/2023/07/02/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2217915
- https://github.com/torvalds/linux/commit/b561275d633bcd8e0e8055ab86f1a13df75a0269
Modified: 2024-11-21
CVE-2023-4389
A flaw was found in btrfs_get_root_ref in fs/btrfs/disk-io.c in the btrfs filesystem in the Linux Kernel due to a double decrement of the reference count. This issue may allow a local attacker with user privilege to crash the system or may lead to leaked internal kernel information.
- https://access.redhat.com/security/cve/CVE-2023-4389
- https://bugzilla.redhat.com/show_bug.cgi?id=2219271
- https://patchwork.kernel.org/project/linux-btrfs/patch/20220324134454.15192-1-baijiaju1990@gmail.com/
- https://access.redhat.com/security/cve/CVE-2023-4389
- https://bugzilla.redhat.com/show_bug.cgi?id=2219271
- https://patchwork.kernel.org/project/linux-btrfs/patch/20220324134454.15192-1-baijiaju1990@gmail.com/
Modified: 2025-11-03
CVE-2024-39474
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") includes support for __GFP_NOFAIL, but it presents a conflict with commit dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A possible scenario is as follows: process-a __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) __vmalloc_area_node() vm_area_alloc_pages() --> oom-killer send SIGKILL to process-a if (fatal_signal_pending(current)) break; --> return NULL; To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() if __GFP_NOFAIL set. This issue occurred during OPLUS KASAN TEST. Below is part of the log -> oom-killer sends signal to process [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198 [65731.259685] [T32454] Call trace: [65731.259698] [T32454] dump_backtrace+0xf4/0x118 [65731.259734] [T32454] show_stack+0x18/0x24 [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c [65731.259781] [T32454] dump_stack+0x18/0x38 [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump] [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc [65731.260047] [T32454] notify_die+0x114/0x198 [65731.260073] [T32454] die+0xf4/0x5b4 [65731.260098] [T32454] die_kernel_fault+0x80/0x98 [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8 [65731.260146] [T32454] do_bad_area+0x68/0x148 [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 [65731.260204] [T32454] el1_abort+0x3c/0x5c [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 [65731.260248] [T32454] el1h_64_sync+0x68/0x6c [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 --> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); kernel panic by NULL pointer dereference. erofs assume kvmalloc with __GFP_NOFAIL never return NULL. [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 [65731.260339] [T32454] read_pages+0x170/0xadc [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 [65731.260437] [T32454] __do_fault+0xd0/0x33c [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0 [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 [65731.260509] [T32454] el0_da+0x44/0x94 [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 [65731.260553] [T32454] el0t_64_sync+0x198/0x19c
- https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91
- https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4
- https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc
- https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da
- https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91
- https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4
- https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc
- https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-42073
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems
The following two shared buffer operations make use of the Shared Buffer
Status Register (SBSR):
# devlink sb occupancy snapshot pci/0000:01:00.0
# devlink sb occupancy clearmax pci/0000:01:00.0
The register has two masks of 256 bits to denote on which ingress /
egress ports the register should operate on. Spectrum-4 has more than
256 ports, so the register was extended by cited commit with a new
'port_page' field.
However, when filling the register's payload, the driver specifies the
ports as absolute numbers and not relative to the first port of the port
page, resulting in memory corruptions [1].
Fix by specifying the ports relative to the first port of the port page.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0
Read of size 1 at addr ffff8881068cb00f by task devlink/1566
[...]
Call Trace:
- https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36
- https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a
- https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e
- https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13
- https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36
- https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a
- https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e
- https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Closed vulnerabilities
Modified: 2024-04-17
BDU:2022-02695
Уязвимость функции evdev_log_msg библиотеки libinput реализации протоколов серверов отображения X.Org и Wayland, позволяющая нарушителю выполнить произвольный код с повышенными привилегиями
Modified: 2024-11-21
CVE-2022-1215
A format string vulnerability was found in libinput
Closed bugs
rdiff: Library does not support trace.
