ALT-PU-2022-3364-23
Package kernel-image-rpi-un updated to version 6.1.0-alt1 for branch sisyphus in task 311832.
Closed vulnerabilities
Modified: 2025-01-29
BDU:2022-06407
Уязвимость интерфейса асинхронного ввода/вывода io_uring ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2023-12-26
BDU:2022-06459
Уязвимость функций unix_sock_destructor() и unix_release_sock() подсистемы BPF ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2022-06550
Уязвимость функции l2cap_conn_del() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-06564
Уязвимость функции l2cap_reassemble_sdu() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-06620
Уязвимость функции del_timer компонента drivers/isdn/mISDN/l1oip_core.c ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-07074
Уязвимость функций l2cap_connect и l2cap_le_connect_req (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-07218
Уязвимость функции l2cap_config_req (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2022-07336
Уязвимость функции __do_proc_dointvec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-08-19
BDU:2022-07343
Уязвимость функции intr_callback() (drivers/net/usb/r8152.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2023-12-12
BDU:2022-07347
Уязвимость компонента drivers/char/pcmcia/scr24x_cs.c ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-06-07
BDU:2022-07505
Уязвимость драйвера беспроводной сети WILC1000 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-06-07
BDU:2022-07506
Уязвимость драйвера беспроводной сети WILC1000 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2022-07507
Уязвимость драйвера беспроводной сети WILC1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить уровень привилегий
Modified: 2024-06-07
BDU:2022-07508
Уязвимость драйвера беспроводной сети WILC1000 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2023-00061
Уязвимость драйвера GPU i915 ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2024-09-13
BDU:2023-00457
Уязвимость файла fs/io_uring.c подсистемы io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-00626
Уязвимость функции qdisc_graft (net/sched/sch_api.c) подсистемы управления трафиком ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-13
BDU:2023-00627
Уязвимость функции io_install_fixed_file() модуля io_uring/filetable.c подсистемы io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-08
BDU:2023-00646
Уязвимость драйвера DVB (drivers/media/dvb-core/dvb_frontend.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии.
Modified: 2025-08-19
BDU:2023-00647
Уязвимость драйвера DVB (drivers/media/dvb-core/dvbdev.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-08-19
BDU:2023-00670
Уязвимость подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2023-00946
Уязвимость функции follow_page_pte файла mm/gup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-30
BDU:2023-00976
Уязвимость функции ntfs_attr_find() (fs/ntfs/attrib.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2023-01192
Уязвимость функции drm_gem_shmem_get_sg_table (drivers/gpu/drm/virtio/virtgpu_object.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2024-03-01
BDU:2023-01274
Уязвимость функции cifs_put_tcp_session() (fs/cifs/connect.c) подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-01285
Уязвимость реализации протокола TIPC (Transparent Inter Process Communication) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-01299
Уязвимость подсистемы KVM AMD для поддержки вложенной виртуализации SVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-13
BDU:2023-02406
Уязвимость функции io_install_fixed_file() подсистемы io_uring ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02527
Уязвимость функции can_rcv_filter() в модуле net/can/af_can.c ядра операционной системы Linux в функции can_rcv_filter(), позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-01-09
BDU:2023-02604
Уязвимость функции rxrpc_unbundle_conn() ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-01-09
BDU:2023-03643
Уязвимость функции amd_sfh_hid_client_init() драйвера AMD Sensor Fusion Hub (SFH) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-04-27
BDU:2023-03666
Уязвимость функции submit_lookup_cmds() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2023-04465
Уязвимость функции tun_napi_alloc_frags() в модуле drivers/net/tun.c драйвера TUN/TAP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
BDU:2023-04895
Уязвимость драйвера PCMCIA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
BDU:2023-04896
Уязвимость драйвера PCMCIA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
Modified: 2025-08-19
BDU:2023-05191
Уязвимость компонента drivers/media/usb/ttusb-dec/ttusb_dec.c ядра операционной системы Linux, позволяющая нарушителю выполнить атаку типа «отказ в обслуживании»
Modified: 2024-09-12
BDU:2023-05194
Уязвимость компонента driver/char/xillybus/xilliusb.c ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе.
Modified: 2025-01-29
BDU:2024-03764
Уязвимость функции sess_free_buffer() в модуле fs/cifs/sess.c файловой системы SMB операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-08-26
BDU:2024-04149
Уязвимость функции spl2sw_nvmem_get_mac_address() в модуле drivers/net/ethernet/sunplus/spl2sw_driver.c драйвера sp7012 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
BDU:2024-09780
Уязвимость функции perf_pending_task() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-09781
Уязвимость функции ip6_fragment() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
BDU:2024-09782
Уязвимость функции hix5hd2_rx() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
BDU:2024-09783
Уязвимость функции hisi_femac_rx() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-09784
Уязвимость функции ravb_rx_gbeth() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-09785
Уязвимость функции amdgpu_job_free_cb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-19
BDU:2024-09786
Уязвимость функции ibmpex_register_bmc() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-13
BDU:2024-10087
Уязвимость функции qeth_l2_br2dev_worker() ядра операционной системы Linux на платформе s390, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10088
Уязвимость функции tun_detach() драйвера tun ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10089
Уязвимость функции hsr_deliver_master() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10090
Уязвимость функции tipc_crypto_rcv_complete() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10091
Уязвимость функции mlx5_eswitch_add_termtbl_rule() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10092
Уязвимость функции e100_xmit_prepare() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-10099
Уязвимость функции memcg_write_event_control() подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-09
BDU:2025-01680
Уязвимость функции gup_pud_range() в модуле mm/gup.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01681
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01682
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01683
Уязвимость компонента HID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01684
Уязвимость компонента gpiolib ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-02-26
BDU:2025-01685
Уязвимость компонента mac802154 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01686
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01689
Уязвимость компонента octeontx2-pf ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-02-26
BDU:2025-01690
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-02-26
BDU:2025-01691
Уязвимость компонента rtc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-01692
Уязвимость компонента AsoC ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-02-26
BDU:2025-01693
Уязвимость компонента igb ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2025-01694
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-26
BDU:2025-01695
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-26
BDU:2025-01696
Уязвимость компонента NFC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-09
BDU:2025-01697
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01698
Уязвимость компонентов gpio/rockchip ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01699
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01700
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-02-26
BDU:2025-01701
Уязвимость компонента ethernet ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-03-18
BDU:2025-01702
Уязвимость компонента udf ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-26
BDU:2025-01704
Уязвимость компонента io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01705
Уязвимость компонентов drm/shmem-helper ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01706
Уязвимость компонента can ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01707
Уязвимость компонента gpio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01708
Уязвимость компонента dpaa2-switch ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-03-18
BDU:2025-01709
Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01710
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-02-26
BDU:2025-01711
Уязвимость компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01712
Уязвимость компонента xen-netfront ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01976
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01978
Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-03-18
BDU:2025-01979
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01982
Уязвимость компонента libbpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-09
BDU:2025-01985
Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03130
Уязвимость функции nfs4_state_shutdown_net() в модуле fs/nfsd/nfs4state.c компонента nfsd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-04347
Уязвимость функции efi_init() модуля arch/riscv/include/asm/efi.h на процессорах с архитектурой RISC-V ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04348
Уязвимость определения структуры vba_vars_st{} модуля drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.h - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-04350
Уязвимость функции mptcp_subflow_queue_clean() модуля net/mptcp/subflow.c реализации протокола MPTCP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04352
Уязвимость функции afs_put_server() модуля fs/afs/server.c поддержки файловой системы Andrew (AFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04428
Уязвимость функции sctp_stream_outq_migrate() в модуле net/sctp/stream.c реализации протокола SCTP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04435
Уязвимость функции iavf_init_module() модуля drivers/net/ethernet/intel/iavf/iavf_main.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
BDU:2025-04436
Уязвимость функции p9_socket_open() модуля net/9p/trans_fd.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04437
Уязвимость функции adjust_tjmax() модуля drivers/hwmon/coretemp.c - драйвера мониторинга оборудования ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-04438
Уязвимость функции snd_soc_put_volsw_sx() модуля sound/soc/soc-ops.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04439
Уязвимость функции slcan_close() модуля drivers/net/can/slcan/slcan-core.c - драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04440
Уязвимость функции ipc_mux_init() модуля drivers/net/wwan/iosm/iosm_ipc_mux.c - драйвера поддержки сетевых адаптеров ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-07469
Уязвимость функции retract_page_tables() модуля mm/khugepaged.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-07470
Уязвимость функции bpf_jit_build_prologue() модуля arch/powerpc/net/bpf_jit_comp32.c поддержки сети на платформе PowerPC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-07471
Уязвимость функции ieee80211_get_rate_duration() модуля net/mac80211/airtime.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-07472
Уязвимость функции cfg80211_gen_new_ie() модуля net/wireless/scan.c поддержки беспроводной связи ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-07497
Уязвимость функции fib_nh_match() модуля net/ipv4/fib_semantics.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07502
Уязвимость функции get_overflow_stack() модуля arch/riscv/kernel/traps.c подсистемы управления модулями платформы с архитектурой RISC-V ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-07504
Уязвимость функции dyn_event_release() модуля kernel/trace/trace_dynevent.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-10252
Уязвимость функции bpf_prog_test_run_skb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-10253
Уязвимость функции snd_soc_exit() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-10254
Уязвимость функции udf_find_entry() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10255
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после ее освобождения, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-12487
Уязвимость ядра операционной системы Linux, связанная с некорректной проверкой количества данных на входе, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2025-12806
Уязвимость функции __split_huge_page_tail() в модуле mm/huge_memory.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-09
BDU:2025-12807
Уязвимость функции send_args() в модуле fs/dlm/lock.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-12808
Уязвимость функции hpd_rx_irq_create_workqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12810
Уязвимость функции ext4_fc_record_regions() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12812
Уязвимость функции rtw_init_cmd_priv() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14264
Уязвимость функции nf_conntrack_hash_check_insert() модуля net/netfilter/nf_conntrack_core.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14265
Уязвимость функции flow_offload_queue_work() модуля net/netfilter/nf_flow_table_offload.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14266
Уязвимость функции dpcm_be_reparent() модуля sound/soc/soc-pcm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14267
Уязвимость функции snd_seq_expand_var_event() модуля sound/core/seq/seq_memory.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14268
Уязвимость функции raydium_i2c_send() модуля drivers/input/touchscreen/raydium_i2c_ts.c драйвера поддержки сенсорного экрана ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14269
Уязвимость функции damon_sysfs_mk_scheme() модуля mm/damon/sysfs.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14270
Уязвимость функции has_external_pci() модуля drivers/iommu/intel/iommu.c драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14271
Уязвимость функции dmar_dev_scope_init() модуля drivers/iommu/dmar.c драйвера поддержки IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14272
Уязвимость функции nilfs_dat_commit_free() модуля fs/nilfs2/dat.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14273
Уязвимость функции can327_feed_frame_to_netdev() модуля drivers/net/can/can327.c драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14274
Уязвимость функции asus_ec_probe() модуля drivers/hwmon/asus-ec-sensors.c драйвера мониторинга оборудования ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14275
Уязвимость функции coretemp_remove_core() модуля drivers/hwmon/coretemp.c драйвера мониторинга оборудования ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14276
Уязвимость функции fwnode_mdiobus_register_phy() модуля drivers/net/mdio/fwnode_mdio.c драйвера сетевых устройств шины MDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14277
Уязвимость функции nixge_hw_dma_bd_release() модуля drivers/net/ethernet/ni/nixge.c драйвера поддержки сетевых адаптеров National Instruments ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14278
Уязвимость функции phy_attach_direct() модуля drivers/net/phy/phy_device.c драйвера поддержки сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14279
Уязвимость функции m_can_pci_probe() модуля drivers/net/can/m_can/m_can_pci.c драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14280
Уязвимость функции ixgbevf_init_module() модуля drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14570
Уязвимость функции tpm_pm_suspend() модуля drivers/char/tpm/tpm-interface.c драйвера поддержки алфавитно-цифровых устройств с TPM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14603
Уязвимость функции set_bit() модуля include/trace/events/fscache.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15380
Уязвимость функции nvme_ns_remove() модуля drivers/nvme/host/core.c - драйвера поддержки NVME ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01283
Уязвимость функции btrfs_quota_enable() модуля fs/btrfs/qgroup.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01285
Уязвимость функции kernfs_remove_by_name_ns() модуля fs/kernfs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01343
Уязвимость функции l2cap_connect_create_rsp() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01507
Уязвимость функции ntfs_read_inode_mount() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01509
Уязвимость функций nilfs_relax_pressure_in_lock() и nilfs_construct_segment() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01629
Уязвимость функции efivar_ssdt_load() модуля drivers/firmware/efi/efi.c драйвера прошивок ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01631
Уязвимость функции nouveau_gem_prime_import_sg_table() модуля drivers/gpu/drm/nouveau/nouveau_prime.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2026-02050
Уязвимость функции airspy_probe() модуля drivers/media/usb/airspy/airspy.c драйвера мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02052
Уязвимость функции SMB2_sess_auth_rawntlmssp_negotiate() модуля fs/cifs/smb2pdu.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02173
Уязвимость функции nfsd4_close_open_stateid() в модуле fs/nfsd/nfs4state.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02177
Уязвимость функции sata_pmp_init_links() в модуле drivers/ata/libata-pmp.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02178
Уязвимость функции fpdt_process_subtable() в модуле drivers/acpi/acpi_fpdt.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02179
Уязвимость функции jbd2_fc_wait_bufs() в модуле fs/jbd2/journal.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02181
Уязвимость функции brcmf_netdev_start_xmit() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02182
Уязвимость функции nfsd_proc_read() в модуле fs/nfsd/nfsproc.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02258
Уязвимость функции ext4_fc_replay_scan() в модуле fs/ext4/fast_commit.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02259
Уязвимость функции rapl_compute_time_window_core() в модуле drivers/powercap/intel_rapl_common.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02268
Уязвимость функции dcn30_clock_source_create() в модуле drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02280
Уязвимость функции jsm_probe_one() модуля drivers/tty/serial/jsm/jsm_driver.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02285
Уязвимость функции iomap_writepage_map() модуля fs/iomap/buffered-io.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02339
Уязвимость функции sk_stream_wait_memory() в модуле net/core/stream.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02342
Уязвимость функции lpfc_cmpl_ct_cmd_gft_id() в модуле drivers/scsi/lpfc/lpfc_ct.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02367
Уязвимость функции nbd_start_device_ioctl() в модуле drivers/block/nbd.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02372
Уязвимость функции msm_dsi_modeset_init() модуля drivers/gpu/drm/msm/dsi/dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02433
Уязвимость функции ge_b850v3_lvds_remove() модуля drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02434
Уязвимость функции hnae_ae_register() модуля drivers/net/ethernet/hisilicon/hns/hnae.c драйвера сетевых адаптеров Ethernet Hisilicon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02435
Уязвимость функции sfb_reset() модуля net/sched/sch_sfb.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02436
Уязвимость функции lpuart_dma_shutdown() модуля drivers/tty/serial/fsl_lpuart.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02441
Уязвимость функции hci_conn_add_sysfs() модуля net/bluetooth/hci_sysfs.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02630
Уязвимость функции ntfs_attr_find() в модуле fs/ntfs/attrib.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02631
Уязвимость функций p9_conn_cancel() и p9_read_work() в модуле net/9p/trans_fd.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02632
Уязвимость функции p9_fd_open() модуля net/9p/trans_fd.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02633
Уязвимость функции gfs2_check_sb() в модуле fs/gfs2/ops_fstype.c файловой системы GFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02634
Уязвимость функции snd_usbmidi_output_open() в модуле sound/usb/midi.c поддержки звуковых устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02635
Уязвимость функции hugetlbfs_error_remove_page() в модуле fs/hugetlbfs/inode.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02636
Уязвимость функции btrfs_init_devices_late() в модуле fs/btrfs/volumes.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02637
Уязвимость функции add_widget_node() в модуле sound/hda/hdac_sysfs.c звуковой подсистнмы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02638
Уязвимость функции make_indexed_dir() в модуле fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02639
Уязвимость функции ext4_ext_migrate() в модуле fs/ext4/migrate.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03108
Уязвимость функции p9_conn_cancel() модуля net/9p/trans_fd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03250
Уязвимость функций drm_sched_entity_kill_jobs_cb() и drm_sched_entity_kill_jobs() модуля drivers/gpu/drm/scheduler/sched_entity.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03269
Уязвимость функций list_version_get_needed() и __list_versions() модуля drivers/md/dm-ioctl.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03270
Уязвимость функции adv7511_remove() модуля drivers/gpu/drm/bridge/adv7511/adv7511_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03325
Уязвимость функций dlm_lowcomms_new_msg() и dlm_lowcomms_commit_msg() модуля fs/dlm/lowcomms.c поддержки распределенного менеджера блокировок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03345
Уязвимость функции amdgpu_vm_sdma_update() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03639
Уязвимость функции ip_vs_app_net_cleanup() модуля net/netfilter/ipvs/ip_vs_app.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03715
Уязвимость функций tcp_cdg_init() и tcp_cdg_release() модуля net/ipv4/tcp_cdg.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03717
Уязвимость функции pte_user_accessible_page() модуля arch/arm64/include/asm/pgtable.h поддержки платформы ARM 64бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03718
Уязвимость функции __unregister_kprobe_top() модуля kernel/kprobes.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03719
Уязвимость функции tcm_loop_setup_hba_bus() модуля drivers/target/loopback/tcm_loop.c драйвера TCM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03721
Уязвимость функции zfcp_fsf_req_send() модуля drivers/s390/scsi/zfcp_fsf.c драйвера устройств SCSI на платформе S390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03722
Уязвимость функции mp2629_read_raw() модуля drivers/iio/adc/mp2629_adc.c драйвера различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03723
Уязвимость функции ena_init() модуля drivers/net/ethernet/amazon/ena/ena_netdev.c драйвера сетевых адаптеров Ethernet Amazon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03724
Уязвимость функции kcm_splice_read() модуля net/kcm/kcmsock.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03725
Уязвимость функции mISDN_dsp_element_register() модуля drivers/isdn/mISDN/dsp_pipeline.c драйвера ISDN адаптеров ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03726
Уязвимость функции siox_device_add() модуля drivers/siox/siox-core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03727
Уязвимость функции setup_bootmem() модуля arch/riscv/mm/init.c подсистемы управления модулями платформы с архитектурой RISCV ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03728
Уязвимость модуля include/uapi/linux/capability.h ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03730
Уязвимость функции piix4_probe() модуля drivers/i2c/busses/i2c-piix4.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03731
Уязвимость функций l2cap_rx_state_recv() и l2cap_rx() модуля net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03732
Уязвимость функций test_no_shared_qgroup() и test_multiple_refs() модуля fs/btrfs/tests/qgroup-tests.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03733
Уязвимость функций prelim_release() и find_parent_nodes() модуля fs/btrfs/backref.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03767
Уязвимость функции cifs_create() модуля fs/cifs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03770
Уязвимость функции dwc3_probe() модуля drivers/usb/dwc3/core.c драйвера контроллера на базе DesignWare USB3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03771
Уязвимость функции bridge_platform_create() модуля arch/mips/sgi-ip27/ip27-xtalk.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03774
Уязвимость функции __cld_pipe_inprogress_downcall() модуля fs/nfsd/nfs4recover.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03775
Уязвимость функции addrconf_init_net() модуля net/ipv6/addrconf.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03776
Уязвимость функции mgmt_init_hdev() модуля net/bluetooth/mgmt.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03828
Уязвимость функции tipc_topsrv_kern_subscr() модуля net/tipc/topsrv.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03838
Уязвимость функции cifs_flock() модуля fs/cifs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03840
Уязвимость функции rpmsg_chrdev_eptdev_destroy() модуля drivers/rpmsg/rpmsg_char.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03843
Уязвимость функции pl353_smc_probe() модуля drivers/memory/pl353-smc.c драйвера контроллера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03879
Уязвимость функции read_reply() модуля drivers/infiniband/sw/rxe/rxe_resp.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03909
Уязвимость функции ata_tport_add() модуля drivers/ata/libata-transport.c драйвера SATA/PATA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03916
Уязвимость функций rsm_load_state_32() и rsm_load_state_64() модуля arch/x86/kvm/emulate.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03917
Уязвимость функции register_synth_event() модуля kernel/trace/trace_events_synth.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03938
Уязвимость функции wwan_hwsim_dev_new() модуля drivers/net/wwan/wwan_hwsim.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03939
Уязвимость функции __unset_online() модуля drivers/s390/cio/css.c драйвера платформы S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03940
Уязвимость функции skb_append_pagefrags() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03962
Уязвимость функции smc_init() модуля net/smc/af_smc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03963
Уязвимость функции kvm_xen_init_vcpu() модуля arch/x86/kvm/xen.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03964
Уязвимость функции cifs_mount() модуля fs/cifs/connect.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03965
Уязвимость функций test_gen_synth_cmd() и test_empty_synth_event() модуля kernel/trace/synth_event_gen_test.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03966
Уязвимость функций qp_notify_peer_local() и qp_notify_peer() модуля drivers/misc/vmw_vmci/vmci_queue_pair.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03967
Уязвимость функции eprobe_trigger_func() модуля kernel/trace/trace_eprobe.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03968
Уязвимость функции amd_pmu_handle_irq() модуля arch/x86/events/amd/core.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03969
Уязвимость функции amd_probe() модуля drivers/mmc/host/sdhci-pci-core.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03970
Уязвимость функций i8042_probe() и i8042_remove() модуля drivers/input/serio/i8042.c драйвера устройств ввода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03975
Уязвимость функции __mdiobus_register() модуля drivers/net/phy/mdio_bus.c драйвера сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03976
Уязвимость функции dsa_switch_teardown() модуля net/dsa/dsa2.c поддержки коммутаторов с распределенной архитектурой ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03977
Уязвимость функции lapbeth_open() модуля drivers/net/wan/lapbether.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03978
Уязвимость функции __get_wchan() модуля arch/s390/include/asm/processor.h поддержки платформы S390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03981
Уязвимость функции iio_sysfs_trigger_remove() модуля drivers/iio/trigger/iio-trig-sysfs.c драйвера различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03982
Уязвимость функции iforce_init_device() модуля drivers/input/joystick/iforce/iforce-main.c драйвера устройств ввода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04052
Уязвимость функции snd_ac97_dev_register() модуля sound/pci/ac97/ac97_codec.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04055
Уязвимость функции i2sbus_add_dev() модуля sound/aoa/soundbus/i2sbus/core.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04059
Уязвимость функции tegra210_clock_init() модуля drivers/clk/tegra/clk-tegra210.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04060
Уязвимость функции tegra20_clock_init() модуля drivers/clk/tegra/clk-tegra20.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04086
Уязвимость функции mipi_dsi_remove_device_fn() модуля drivers/gpu/drm/drm_mipi_dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04093
Уязвимость функции blk_mq_clear_rq_mapping() модуля block/blk-mq.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04115
Уязвимость функции adm_slave_config() модуля drivers/dma/qcom/qcom_adm.c драйвера движка DMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04383
Уязвимость функции msm_dp_modeset_init() модуля drivers/gpu/drm/msm/dp/dp_display.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04409
Уязвимость функции smp_execute_task_sg() модуля drivers/scsi/libsas/sas_expander.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04484
Уязвимость функции optc314_set_odm_bypass() модуля drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04498
Уязвимость функции __bpf_trace_run() модуля kernel/trace/bpf_trace.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04500
Уязвимость функции netlink_ack() модуля net/netlink/af_netlink.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04513
Уязвимость функции gbaudio_dapm_free_controls() модуля drivers/staging/greybus/audio_helper.c драйвера устройств линейки Greybus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04555
Уязвимость функции ceph_update_snap_trace() модуля fs/ceph/snap.c поддержки распределенной файловой системы Ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04858
Уязвимость функции xhci_alloc_stream_info() модуля drivers/usb/host/xhci-mem.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04862
Уязвимость функции show_cpuinfo() модуля arch/um/kernel/um_arch.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04864
Уязвимость функции ext4_write_info() модуля fs/ext4/super.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04868
Уязвимость функции buffer_prepare() модуля drivers/media/pci/cx88/cx88-video.c драйвера мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04903
Уязвимость функции clone_fs_devices() модуля fs/btrfs/volumes.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05626
Уязвимость функции ip6addrlbl_putmsg() в модуле net/ipv6/addrlabel.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-05735
Уязвимость функции alloc_huge_page() модуля mm/hugetlb.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05769
Уязвимость подсистемы switchdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05770
Уязвимость функции mhi_net_dellink() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05771
Уязвимость функции nsim_dev_trap_fa_cookie_write компонента netdevsim ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05772
Уязвимость функции ata_tdev_add() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05773
Уязвимость функции ata_tport_add() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05774
Уязвимость функции drm_dev_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05775
Уязвимость функции pinctrl_dt_to_map() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05776
Уязвимость функции can_rx_register() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05777
Уязвимость функции napi_get_frags() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05778
Уязвимость функции cortex_a76_erratum_1463225_debug_handler() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05779
Уязвимость функций test_gen_kprobe/kretprobe_cmd() и test_gen_kprobe_cmd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05780
Уязвимость функций __ip_vs_cleanup_batch() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05782
Уязвимость функции blk_mq_init_allocated_queue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05783
Уязвимость функции xprt_switch sysfs() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05807
Уязвимость компонента macvlan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05808
Уязвимость функции kprobe_event_gen_test_exit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05809
Уязвимость функции tracing_read_pipe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05810
Уязвимость функции ftrace_add_mod() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05811
Уязвимость функции xas_retry() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05812
Уязвимость функции ata_tlink_add() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05813
Уязвимость функции sctp_sched_fcfs_dequeue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05814
Уязвимость функции imx_uart_freeze() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05841
Уязвимость функции j1939_send_one() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05842
Уязвимость компонента octeontx2-pf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05843
Уязвимость функции free_netdev() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05844
Уязвимость функции mousevsc_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05845
Уязвимость функции query_regdb_file() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05846
Уязвимость компонента ibmvnic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05847
Уязвимость функции mISDN_register_device() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05848
Уязвимость функции red_enqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05855
Уязвимость функции i2c_dw_xfer_msg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05856
Уязвимость функции percpu_init_rwsem() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05858
Уязвимость функции of_lpddr3_get_ddr_timings() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05860
Уязвимость функции des3_ede_encrypt() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05862
Уязвимость функции getpeername() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05940
Уязвимость функции fpu_clone() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05941
Уязвимость драйвера uncore ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-05942
Уязвимость функции blkcg_css_online() компонента blk-cgroup ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-05943
Уязвимость компонента io_uring ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-05944
Уязвимость функции nvmet_auth_set_key() ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-05945
Уязвимость функции xas_retry() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05946
Уязвимость функции octep_device_setup() ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-05947
Уязвимость компонента CAN ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05948
Уязвимость функции am65_cpsw_nuss_phylink_cleanup() драйвера am65-cpsw ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05949
Уязвимость функции mhi_mbim_dellink() драйвера MHI ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05950
Уязвимость функции unix_gc() модуля fnet/unix/garbage.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05952
Уязвимость функции of_get_ddr_timings() модуля drivers/memory/of_memory.c драйвера контроллера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05953
Уязвимость функций trace_string() и trace_event_raw_event_synth() модуля kernel/trace/trace_events_synth.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05956
Уязвимость функций vhost_vsock_alloc_pkt() (drivers/vhost/vsock.c) и virtio_transport_free_pkt() (net/vmw_vsock/virtio_transport_common.c) драйвера общей реализации IOTLB для vhost и vringh ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05978
Уязвимость функции hinic_init_cmdqs() модуля drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05982
Уязвимость функции ieee80211_rx_mgmt_assoc_resp() модуля net/mac80211/mlme.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05985
Уязвимость функции ath11k_mhi_register() модуля drivers/net/wireless/ath/ath11k/mhi.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06031
Уязвимость функции alloc_sk_msg() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06050
Уязвимость функции sc_disable() ядра операционных систем Linux, позволяющая нарушителю вызвать сбой ядра
BDU:2026-06051
Уязвимость функции nf_flow_table_free() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06052
Уязвимость функции rcu_barrier() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06053
Уязвимость функции remove() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06054
Уязвимость функции cxl_port_attach_region() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06055
Уязвимость функции unregister_region() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06056
Уязвимость функции sk_stream_kill_queues() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06057
Уязвимость функции devm_cxl_add_region() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06058
Уязвимость функции ieee80211_subif_start_xmit() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06068
Уязвимость функции nfsd_init_dirlist_pages() в модуле fs/nfsd/nfsproc.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06069
Уязвимость функции qcom_cpufreq_probe() в модуле drivers/cpufreq/qcom-cpufreq-nvmem.c драйвера масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06077
Уязвимость функции io_msg_send_fd() в модуле io_uring/msg_ring.c интерфейса асинхронного ввода/вывода ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06079
Уязвимость функции dump_zones() в модуле drivers/md/raid0.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06081
Уязвимость функции __copy_xstate_to_uabi_buf() в модуле arch/x86/kernel/fpu/xstate.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06083
Уязвимость функции ext4_dio_write_iter() в модуле fs/ext4/file.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06084
Уязвимость функции hinic_dbg_get_func_table() в модуле drivers/net/ethernet/huawei/hinic/hinic_debugfs.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06088
Уязвимость функции __unmap_hugepage_range() в модуле mm/hugetlb.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06089
Уязвимость функции cake_dequeue() в модуле net/sched/sch_cake.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06092
Уязвимость функции load_elf_binary() в модуле fs/binfmt_elf.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2022-2602
io_uring UAF, Unix SCM garbage collection
- http://packetstormsecurity.com/files/176533/Linux-Broken-Unix-GC-Interaction-Use-After-Free.html
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2602
- https://ubuntu.com/security/notices/USN-5691-1
- https://ubuntu.com/security/notices/USN-5692-1
- https://ubuntu.com/security/notices/USN-5693-1
- https://ubuntu.com/security/notices/USN-5700-1
- https://ubuntu.com/security/notices/USN-5752-1
- http://packetstormsecurity.com/files/176533/Linux-Broken-Unix-GC-Interaction-Use-After-Free.html
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2602
- https://ubuntu.com/security/notices/USN-5691-1
- https://ubuntu.com/security/notices/USN-5692-1
- https://ubuntu.com/security/notices/USN-5693-1
- https://ubuntu.com/security/notices/USN-5700-1
- https://ubuntu.com/security/notices/USN-5752-1
Modified: 2025-05-07
CVE-2022-3344
A flaw was found in the KVM's AMD nested virtualization (SVM). A malicious L1 guest could purposely fail to intercept the shutdown of a cooperative nested guest (L2), possibly leading to a page fault and kernel panic in the host (L0).
Modified: 2024-11-21
CVE-2022-3541
A vulnerability classified as critical has been found in Linux Kernel. This affects the function spl2sw_nvmem_get_mac_address of the file drivers/net/ethernet/sunplus/spl2sw_driver.c of the component BPF. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211041 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=12aece8b01507a2d357a1861f470e83621fbb6f2
- https://security.netapp.com/advisory/ntap-20221228-0001/
- https://vuldb.com/?id.211041
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=12aece8b01507a2d357a1861f470e83621fbb6f2
- https://security.netapp.com/advisory/ntap-20221228-0001/
- https://vuldb.com/?id.211041
Modified: 2024-11-21
CVE-2022-3543
A vulnerability, which was classified as problematic, has been found in Linux Kernel. This issue affects the function unix_sock_destructor/unix_release_sock of the file net/unix/af_unix.c of the component BPF. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211043.
Modified: 2024-11-21
CVE-2022-3564
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211087.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
Modified: 2024-11-21
CVE-2022-3565
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function del_timer of the file drivers/isdn/mISDN/l1oip_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211088.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211088
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211088
Modified: 2024-11-21
CVE-2022-3594
A vulnerability was found in Linux Kernel. It has been declared as problematic. Affected by this vulnerability is the function intr_callback of the file drivers/net/usb/r8152.c of the component BPF. The manipulation leads to logging of excessive data. The attack can be launched remotely. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211363.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93e2be344a7db169b7119de21ac1bf253b8c6907
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211363
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93e2be344a7db169b7119de21ac1bf253b8c6907
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211363
Modified: 2024-11-21
CVE-2022-3595
A vulnerability was found in Linux Kernel. It has been rated as problematic. Affected by this issue is the function sess_free_buffer of the file fs/cifs/sess.c of the component CIFS Handler. The manipulation leads to double free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211364.
Modified: 2024-11-21
CVE-2022-3623
A vulnerability was found in Linux Kernel. It has been declared as problematic. Affected by this vulnerability is the function follow_page_pte of the file mm/gup.c of the component BPF. The manipulation leads to race condition. The attack can be launched remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-211921 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://vuldb.com/?id.211921
- https://www.debian.org/security/2023/dsa-5324
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://vuldb.com/?id.211921
- https://www.debian.org/security/2023/dsa-5324
Modified: 2024-11-21
CVE-2022-3640
A vulnerability, which was classified as critical, was found in Linux Kernel. Affected is the function l2cap_conn_del of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211944.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
Modified: 2025-03-07
CVE-2022-3707
A double-free memory flaw was found in the Linux kernel. The Intel GVT-g graphics driver triggers VGA card system resource overload, causing a fail in the intel_gvt_dma_map_guest_page function. This issue could allow a local user to crash the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2137979
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20221007013708.1946061-1-zyytlz.wz%40163.com/
- https://bugzilla.redhat.com/show_bug.cgi?id=2137979
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20221007013708.1946061-1-zyytlz.wz%40163.com/
Modified: 2025-03-28
CVE-2022-4139
An incorrect TLB flush issue was found in the Linux kernel’s GPU i915 kernel driver, potentially leading to random memory corruption or data leaks. This flaw could allow a local user to crash the system or escalate their privileges on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2147572
- https://security.netapp.com/advisory/ntap-20230309-0004/
- https://www.openwall.com/lists/oss-security/2022/11/30/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2147572
- https://security.netapp.com/advisory/ntap-20230309-0004/
- https://www.openwall.com/lists/oss-security/2022/11/30/1
Modified: 2024-11-21
CVE-2022-42896
There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim. We recommend upgrading past commit https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url
Modified: 2025-04-10
CVE-2022-4378
A stack overflow flaw was found in the Linux kernel's SYSCTL subsystem in how a user changes certain kernel parameters and variables. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2152548
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-get_proc_long.patch
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-proc_skip_spaces-shouldn-t-think-it-is-working-on-c-strings.patch
- https://seclists.org/oss-sec/2022/q4/178
- http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2152548
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-get_proc_long.patch
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-proc_skip_spaces-shouldn-t-think-it-is-working-on-c-strings.patch
- https://seclists.org/oss-sec/2022/q4/178
Modified: 2024-11-21
CVE-2022-44032
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4000_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cmm_open() and cm4000_detach().
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/
- https://lore.kernel.org/lkml/20220919040701.GA302806%40ubuntu/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/
- https://lore.kernel.org/lkml/20220919040701.GA302806%40ubuntu/
Modified: 2024-11-21
CVE-2022-44033
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4040_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cm4040_open() and reader_detach().
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/
- https://lore.kernel.org/lkml/20220919040457.GA302681%40ubuntu/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/
- https://lore.kernel.org/lkml/20220919040457.GA302681%40ubuntu/
Modified: 2024-11-21
CVE-2022-44034
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/scr24x_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between scr24x_open() and scr24x_remove().
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220916050333.GA188358%40ubuntu/
- https://lore.kernel.org/lkml/20220919101825.GA313940%40ubuntu/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220916050333.GA188358%40ubuntu/
- https://lore.kernel.org/lkml/20220919101825.GA313940%40ubuntu/
Modified: 2025-04-24
CVE-2022-45869
A race condition in the x86 KVM subsystem in the Linux kernel through 6.1-rc6 allows guest OS users to cause a denial of service (host OS crash or host OS memory corruption) when nested virtualisation and the TDP MMU are enabled.
Modified: 2024-11-21
CVE-2022-45884
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvbdev.c has a use-after-free, related to dvb_register_device dynamically allocating fops.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=627bb528b086b4136315c25d6a447a98ea9448d3
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-4-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=627bb528b086b4136315c25d6a447a98ea9448d3
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-4-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
Modified: 2025-04-29
CVE-2022-45885
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_frontend.c has a race condition that can cause a use-after-free when a device is disconnected.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-2-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-2-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
Modified: 2025-04-25
CVE-2022-45887
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/usb/ttusb-dec/ttusb_dec.c has a memory leak because of the lack of a dvb_frontend_detach call.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=517a281338322ff8293f988771c98aaa7205e457
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-5-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=517a281338322ff8293f988771c98aaa7205e457
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-5-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
Modified: 2025-11-03
CVE-2022-45888
An issue was discovered in the Linux kernel through 6.0.9. drivers/char/xillybus/xillyusb.c has a race condition and use-after-free during physical removal of a USB device.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=282a4b71816b6076029017a7bab3a9dcee12a920
- https://lore.kernel.org/all/20221022175404.GA375335%40ubuntu/
- https://security.netapp.com/advisory/ntap-20230113-0006/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=282a4b71816b6076029017a7bab3a9dcee12a920
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lore.kernel.org/all/20221022175404.GA375335%40ubuntu/
- https://security.netapp.com/advisory/ntap-20230113-0006/
Modified: 2025-04-29
CVE-2022-45934
An issue was discovered in the Linux kernel through 6.0.10. l2cap_config_req in net/bluetooth/l2cap_core.c has an integer wraparound via L2CAP_CONF_REQ packets.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NDAKCGDW6CQ6G3RZWYZJO454R3L5CTQB/
- https://security.netapp.com/advisory/ntap-20230113-0008/
- https://www.debian.org/security/2023/dsa-5324
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NDAKCGDW6CQ6G3RZWYZJO454R3L5CTQB/
- https://security.netapp.com/advisory/ntap-20230113-0008/
- https://www.debian.org/security/2023/dsa-5324
Modified: 2025-04-17
CVE-2022-47518
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of the number of channels in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when copying the list of operating channels from Wi-Fi management frames.
- https://github.com/torvalds/linux/commit/0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-5-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
- https://github.com/torvalds/linux/commit/0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-5-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
Modified: 2025-04-17
CVE-2022-47519
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_OPER_CHANNEL in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger an out-of-bounds write when parsing the channel list attribute from Wi-Fi management frames.
- https://github.com/torvalds/linux/commit/051ae669e4505abbe05165bebf6be7922de11f41
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-3-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
- https://github.com/torvalds/linux/commit/051ae669e4505abbe05165bebf6be7922de11f41
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-3-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
Modified: 2025-04-17
CVE-2022-47520
An issue was discovered in the Linux kernel before 6.0.11. Missing offset validation in drivers/net/wireless/microchip/wilc1000/hif.c in the WILC1000 wireless driver can trigger an out-of-bounds read when parsing a Robust Security Network (RSN) information element from a Netlink packet.
- https://github.com/torvalds/linux/commit/cd21d99e595ec1d8721e1058dcdd4f1f7de1d793
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-2-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
- https://github.com/torvalds/linux/commit/cd21d99e595ec1d8721e1058dcdd4f1f7de1d793
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-2-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
Modified: 2025-04-17
CVE-2022-47521
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_CHANNEL_LIST in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when parsing the operating channel attribute from Wi-Fi management frames.
- https://github.com/torvalds/linux/commit/f9b62f9843c7b0afdaecabbcebf1dbba18599408
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-4-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
- https://github.com/torvalds/linux/commit/f9b62f9843c7b0afdaecabbcebf1dbba18599408
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lore.kernel.org/r/20221123153543.8568-4-philipturnbull%40github.com
- https://security.netapp.com/advisory/ntap-20230113-0007/
Modified: 2024-10-25
CVE-2022-48946
In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.
- https://git.kernel.org/stable/c/12a88f572d6d94b5c0b72e2d1782cc2e96ac06cf
- https://git.kernel.org/stable/c/1a075f4a549481ce6e8518d8379f193ccec6b746
- https://git.kernel.org/stable/c/4d835efd561dfb9bf5409f11f4ecd428d5d29226
- https://git.kernel.org/stable/c/63dbbd8f1499b0a161e701a04aa50148d60bd1f7
- https://git.kernel.org/stable/c/72f651c96c8aadf087fd782d551bf7db648a8c2e
- https://git.kernel.org/stable/c/7665857f88557c372da35534165721156756f77f
- https://git.kernel.org/stable/c/ae56d9a017724f130cf1a263dd82a78d2a6e3852
- https://git.kernel.org/stable/c/c8b6fa4511a7900db9fb0353b630d4d2ed1ba99c
- https://git.kernel.org/stable/c/cfe4c1b25dd6d2f056afc00b7c98bcb3dd0b1fc3
Modified: 2024-10-25
CVE-2022-48947
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@...
- https://git.kernel.org/stable/c/19a78143961a197de8502f4f29c453b913dc3c29
- https://git.kernel.org/stable/c/49d5867819ab7c744852b45509e8469839c07e0e
- https://git.kernel.org/stable/c/5550bbf709c323194881737fd290c4bada9e6ead
- https://git.kernel.org/stable/c/95f1847a361c7b4bf7d74c06ecb6968455082c1a
- https://git.kernel.org/stable/c/9fdc79b571434af7bc742da40a3405f038b637a7
- https://git.kernel.org/stable/c/ad528fde0702903208d0a79d88d5a42ae3fc235b
- https://git.kernel.org/stable/c/bcd70260ef56e0aee8a4fc6cd214a419900b0765
- https://git.kernel.org/stable/c/f3fe6817156a2ad4b06f01afab04638a34d7c9a6
Modified: 2024-10-29
CVE-2022-48948
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes.
- https://git.kernel.org/stable/c/06fd17ee92c8f1704c7e54ec0fd50ae0542a49a5
- https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35
- https://git.kernel.org/stable/c/4c92670b16727365699fe4b19ed32013bab2c107
- https://git.kernel.org/stable/c/6b41a35b41f77821db24f2d8f66794b390a585c5
- https://git.kernel.org/stable/c/7b1f773277a72f9756d47a41b94e43506cce1954
- https://git.kernel.org/stable/c/b8fb1cba934ea122b50f13a4f9d6fc4fdc43d2be
- https://git.kernel.org/stable/c/bc8380fe5768c564f921f7b4eaba932e330b9e4b
- https://git.kernel.org/stable/c/c79538f32df12887f110dcd6b9c825b482905f24
- https://git.kernel.org/stable/c/d1a92bb8d697f170d93fe922da763d7d156b8841
Modified: 2024-10-29
CVE-2022-48949
In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.
- https://git.kernel.org/stable/c/367e1e3399dbc56fc669740c4ab60e35da632b0e
- https://git.kernel.org/stable/c/51fd5ede7ed42f272682a0c33d6f0767b3484a3d
- https://git.kernel.org/stable/c/a6629659af3f5c6a91e3914ea62554c975ab77f4
- https://git.kernel.org/stable/c/c383c7c35c7bc15e07a04eefa060a8a80cbeae29
- https://git.kernel.org/stable/c/c581439a977545d61849a72e8ed631cfc8a2a3c1
- https://git.kernel.org/stable/c/de5dc44370fbd6b46bd7f1a1e00369be54a041c8
- https://git.kernel.org/stable/c/ef1d739dd1f362aec081278ff92f943c31eb177a
- https://git.kernel.org/stable/c/f2479c3daaabccbac6c343a737615d0c595c6dc4
Modified: 2024-10-25
CVE-2022-48950
In the Linux kernel, the following vulnerability has been resolved: perf: Fix perf_pending_task() UaF Per syzbot it is possible for perf_pending_task() to run after the event is free()'d. There are two related but distinct cases: - the task_work was already queued before destroying the event; - destroying the event itself queues the task_work. The first cannot be solved using task_work_cancel() since perf_release() itself might be called from a task_work (____fput), which means the current->task_works list is already empty and task_work_cancel() won't be able to find the perf_pending_task() entry. The simplest alternative is extending the perf_event lifetime to cover the task_work. The second is just silly, queueing a task_work while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATE_DEAD and ensuring it goes through STATE_OFF on the way down.
Modified: 2024-10-25
CVE-2022-48951
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks.
- https://git.kernel.org/stable/c/1798b62d642e7b3d4ea3403914c3caf4e438465d
- https://git.kernel.org/stable/c/18a168d85eadcfd45f015b5ecd2a97801b959e43
- https://git.kernel.org/stable/c/50b5f6d4d9d2d69a7498c44fd8b26e13d73d3d98
- https://git.kernel.org/stable/c/56288987843c3cb343e81e5fa51549cbaf541bd0
- https://git.kernel.org/stable/c/9796d07c753164b7e6b0d7ef23fb4482840a9ef8
- https://git.kernel.org/stable/c/97eea946b93961fffd29448dcda7398d0d51c4b2
- https://git.kernel.org/stable/c/cf1c225f1927891ae388562b78ced7840c3723b9
- https://git.kernel.org/stable/c/cf611d786796ec33da09d8c83d7d7f4e557b27de
Modified: 2024-10-25
CVE-2022-48952
In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel.
Modified: 2024-10-25
CVE-2022-48953
In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit.
Modified: 2024-10-24
CVE-2022-48954
In the Linux kernel, the following vulnerability has been resolved: s390/qeth: fix use-after-free in hsci KASAN found that addr was dereferenced after br2dev_event_work was freed. ================================================================== BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0 Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Hardware name: IBM 8561 T01 703 (LPAR) Workqueue: 0.0.8000_event qeth_l2_br2dev_worker Call Trace: [<000000016944d4ce>] dump_stack_lvl+0xc6/0xf8 [<000000016942cd9c>] print_address_description.constprop.0+0x34/0x2a0 [<000000016942d118>] print_report+0x110/0x1f8 [<0000000167a7bd04>] kasan_report+0xfc/0x128 [<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0 [<00000001673edd1e>] process_one_work+0x76e/0x1128 [<00000001673ee85c>] worker_thread+0x184/0x1098 [<000000016740718a>] kthread+0x26a/0x310 [<00000001672c606a>] __ret_from_fork+0x8a/0xe8 [<00000001694711da>] ret_from_fork+0xa/0x40 Allocated by task 108338: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 __kasan_kmalloc+0xa0/0xc0 qeth_l2_switchdev_event+0x25a/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Freed by task 540: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 kasan_save_free_info+0x4c/0x68 ____kasan_slab_free+0x14e/0x1a8 __kasan_slab_free+0x24/0x30 __kmem_cache_free+0x168/0x338 qeth_l2_br2dev_worker+0x154/0x6b0 process_one_work+0x76e/0x1128 worker_thread+0x184/0x1098 kthread+0x26a/0x310 __ret_from_fork+0x8a/0xe8 ret_from_fork+0xa/0x40 Last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 insert_work+0x56/0x2e8 __queue_work+0x4ce/0xd10 queue_work_on+0xf4/0x100 qeth_l2_switchdev_event+0x520/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Second to last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 kvfree_call_rcu+0xb2/0x760 kernfs_unlink_open_file+0x348/0x430 kernfs_fop_release+0xc2/0x320 __fput+0x1ae/0x768 task_work_run+0x1bc/0x298 exit_to_user_mode_prepare+0x1a0/0x1a8 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 The buggy address belongs to the object at 00000000fdcea400 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 64 bytes inside of 96-byte region [00000000fdcea400, 00000000fdcea460) The buggy address belongs to the physical page: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea380: fb fb fb fb fb fb f ---truncated---
Modified: 2024-10-24
CVE-2022-48955
In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: fix memory leak in tbnet_open() When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in tb_xdomain_alloc_out_hopid() is not released. Add tb_xdomain_release_out_hopid() to the error path to release ida.
Modified: 2024-10-24
CVE-2022-48956
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid use-after-free in ip6_fragment()
Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.
It seems to not be always true, at least for UDP stack.
syzbot reported:
BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]
BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618
CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/6b6d3be3661bff2746cab26147bd629aa034e094
- https://git.kernel.org/stable/c/7390c70bd431cbfa6951477e2c80a301643e284b
- https://git.kernel.org/stable/c/7e0dcd5f3ade221a6126278aca60c8ab4cc3bce9
- https://git.kernel.org/stable/c/803e84867de59a1e5d126666d25eb4860cfd2ebe
- https://git.kernel.org/stable/c/8208d7e56b1e579320b9ff3712739ad2e63e1f86
- https://git.kernel.org/stable/c/9b1a468a455d8319041528778d0e684a4c062792
- https://git.kernel.org/stable/c/b3d7ff8c04a83279fb7641fc4d5aa82a602df7c0
Modified: 2024-10-24
CVE-2022-48957
In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove() The cmd_buff needs to be freed when error happened in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove().
Modified: 2024-10-24
CVE-2022-48958
In the Linux kernel, the following vulnerability has been resolved: ethernet: aeroflex: fix potential skb leak in greth_init_rings() The greth_init_rings() function won't free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it. Compile tested only.
- https://git.kernel.org/stable/c/063a932b64db3317ec020c94466fe52923a15f60
- https://git.kernel.org/stable/c/223654e2e2c8d05347cd8e300f8d1ec6023103dd
- https://git.kernel.org/stable/c/87277bdf2c370ab2d07cfe77dfa9b37f82bbe1e5
- https://git.kernel.org/stable/c/99669d94ce145389f1d6f197e6e18ed50d43fb76
- https://git.kernel.org/stable/c/bfaa8f6c5b84b295dd73b0138b57c5555ca12b1c
- https://git.kernel.org/stable/c/c7adcbd0fd3fde1b19150c3e955fb4a30c5bd9b7
- https://git.kernel.org/stable/c/cb1e293f858e5e1152b8791047ed4bdaaf392189
- https://git.kernel.org/stable/c/dd62867a6383f78f75f07039394aac25924a3307
Modified: 2024-10-24
CVE-2022-48959
In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions() When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(), priv->regions is not released.
Modified: 2024-10-24
CVE-2022-48960
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hix5hd2_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.
- https://git.kernel.org/stable/c/179499e7a240b2ef590f05eb379c810c26bbc8a4
- https://git.kernel.org/stable/c/1b6360a093ab8969c91a30bb58b753282e2ced4c
- https://git.kernel.org/stable/c/3a4eddd1cb023a71df4152fcc76092953e6fe95a
- https://git.kernel.org/stable/c/433c07a13f59856e4585e89e86b7d4cc59348fab
- https://git.kernel.org/stable/c/8067cd244cea2c332f8326842fd10158fa2cb64f
- https://git.kernel.org/stable/c/93aaa4bb72e388f6a4887541fd3d18b84f1b5ddc
- https://git.kernel.org/stable/c/b6307f7a2fc1c5407b6176f2af34a95214a8c262
- https://git.kernel.org/stable/c/b8ce0e6f9f88a6bb49d291498377e61ea27a5387
Modified: 2024-10-24
CVE-2022-48961
In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix unbalanced fwnode reference count in mdio_device_release() There is warning report about of_node refcount leak while probing mdio device: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4 In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly. After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.
Modified: 2024-10-24
CVE-2022-48962
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hisi_femac_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.
- https://git.kernel.org/stable/c/196e12671cb629d9f3b77b4d8bec854fc445533a
- https://git.kernel.org/stable/c/296a50aa8b2982117520713edc1375777a9f8506
- https://git.kernel.org/stable/c/3501da8eb6d0f5f114a09ec953c54423f6f35885
- https://git.kernel.org/stable/c/4640177049549de1a43e9bc49265f0cdfce08cfd
- https://git.kernel.org/stable/c/6f4798ac9c9e98f41553c4f5e6c832c8860a6942
- https://git.kernel.org/stable/c/8595a2db8eb0ffcbb466eb9f4a7507a5ba06ebb9
- https://git.kernel.org/stable/c/aceec8ab752428d8e151321479e82cc1a40fee2e
- https://git.kernel.org/stable/c/e71a46cc8c9ad75f3bb0e4b361e81f79c0214cca
Modified: 2024-10-24
CVE-2022-48963
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_mux_init() When failed to alloc ipc_mux->ul_adb.pp_qlt in ipc_mux_init(), ipc_mux is not released.
Modified: 2024-10-24
CVE-2022-48964
In the Linux kernel, the following vulnerability has been resolved: ravb: Fix potential use-after-free in ravb_rx_gbeth() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.
Modified: 2024-10-25
CVE-2022-48965
In the Linux kernel, the following vulnerability has been resolved: gpio/rockchip: fix refcount leak in rockchip_gpiolib_register() The node returned by of_get_parent() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the end of of_pinctrl_get().
Modified: 2024-10-25
CVE-2022-48966
In the Linux kernel, the following vulnerability has been resolved: net: mvneta: Prevent out of bounds read in mvneta_config_rss() The pp->indir[0] value comes from the user. It is passed to: if (cpu_online(pp->rxq_def)) inside the mvneta_percpu_elect() function. It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap.
- https://git.kernel.org/stable/c/146ebee8fcdb349d7ec0e49915e6cdafb92544ae
- https://git.kernel.org/stable/c/3ceffb8f410b93553fb16fe7e84aa0d35b3ba79b
- https://git.kernel.org/stable/c/47a1a2f6cd5ec3a4f8a2d9bfa1e0605347cdb92c
- https://git.kernel.org/stable/c/5a142486a0db6b0b85031f22d69acd0cdcf8f72b
- https://git.kernel.org/stable/c/6ca0a506dddc3e1d636935eef339576b263bf3d8
- https://git.kernel.org/stable/c/a6b30598fec84f8809f5417cde73071ca43e8471
- https://git.kernel.org/stable/c/e8b4fc13900b8e8be48debffd0dfd391772501f7
- https://git.kernel.org/stable/c/eec1fc21edc2bb99c9e66cf66f0b5d4d643fbb50
Modified: 2024-10-25
CVE-2022-48967
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.
- https://git.kernel.org/stable/c/27eb2d7a1b9987b6d0429b7716b1ff3b82c4ffc9
- https://git.kernel.org/stable/c/6778434706940b8fad7ef35f410d2b9929f256d2
- https://git.kernel.org/stable/c/6b37f0dc0638d13a006f2f24d2f6ca61e83bc714
- https://git.kernel.org/stable/c/908b2da426fe9c3ce74cf541ba40e7a4251db191
- https://git.kernel.org/stable/c/cff35329070b96b4484d23f9f48a5ca2c947e750
- https://git.kernel.org/stable/c/dbdcfb9f6748218a149f62468d6297ce3f014e9c
- https://git.kernel.org/stable/c/e329e71013c9b5a4535b099208493c7826ee4a64
- https://git.kernel.org/stable/c/f41547546db9af99da2c34e3368664d7a79cefae
Modified: 2024-10-25
CVE-2022-48968
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential memory leak in otx2_init_tc() In otx2_init_tc(), if rhashtable_init() failed, it does not free tc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap().
Modified: 2024-10-25
CVE-2022-48969
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time
- https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd
- https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9
- https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a
- https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050
- https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda
- https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84
Modified: 2024-10-25
CVE-2022-48970
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Get user_ns from in_skb in unix_diag_get_exact().
Wei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed
the root cause: in unix_diag_get_exact(), the newly allocated skb does not
have sk. [2]
We must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to
sk_diag_fill().
[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000270
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:sk_user_ns include/net/sock.h:920 [inline]
RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]
RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170
Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8
54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b
9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d
RSP: 0018:ffffc90000d67968 EFLAGS: 00010246
RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d
RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270
RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000
R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800
R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940
FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/575a6266f63dbb3b8eb1da03671451f0d81b8034
- https://git.kernel.org/stable/c/5c014eb0ed6c8c57f483e94cc6e90f34ce426d91
- https://git.kernel.org/stable/c/9c1d6f79a2c7b8221dcec27defc6dc461052ead4
- https://git.kernel.org/stable/c/b3abe42e94900bdd045c472f9c9be620ba5ce553
- https://git.kernel.org/stable/c/c66d78aee55dab72c92020ebfbebc464d4f5dd2a
Modified: 2024-10-25
CVE-2022-48971
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix not cleanup led when bt_init fails
bt_init() calls bt_leds_init() to register led, but if it fails later,
bt_leds_cleanup() is not called to unregister it.
This can cause panic if the argument "bluetooth-power" in text is freed
and then another led_trigger_register() tries to access it:
BUG: unable to handle page fault for address: ffffffffc06d3bc0
RIP: 0010:strcmp+0xc/0x30
Call Trace:
- https://git.kernel.org/stable/c/2c6cf0afc3856359e620e96edd952457d258e16c
- https://git.kernel.org/stable/c/2f3957c7eb4e07df944169a3e50a4d6790e1c744
- https://git.kernel.org/stable/c/5ecf7cd6fde5e72c87122084cf00d63e35d8dd9f
- https://git.kernel.org/stable/c/8a66c3a94285552f6a8e45d73b34ebbad11d388b
- https://git.kernel.org/stable/c/e7b950458156d410509a08c41930b75e72985938
- https://git.kernel.org/stable/c/edf7284a98296369dd0891a0457eec37df244873
Modified: 2024-10-25
CVE-2022-48972
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()
Kernel fault injection test reports null-ptr-deref as follows:
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114
Call Trace:
- https://git.kernel.org/stable/c/1831d4540406708e48239cf38fd9c3b7ea98e08f
- https://git.kernel.org/stable/c/42c319635c0cf7eb36eccac6cda76532f47b61a3
- https://git.kernel.org/stable/c/623918f40fa68e3bb21312a3fafb90f491bf5358
- https://git.kernel.org/stable/c/7410f4d1221bb182510b7778ab6eefa8b9b7102d
- https://git.kernel.org/stable/c/9980a3ea20de40c83817877106c909cb032692d2
- https://git.kernel.org/stable/c/a110287ef4a423980309490df632e1c1e73b3dc9
- https://git.kernel.org/stable/c/b3d72d3135d2ef68296c1ee174436efd65386f04
- https://git.kernel.org/stable/c/f00c84fb1635c27ba24ec5df65d5bd7d7dc00008
Modified: 2024-10-25
CVE-2022-48973
In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit().
- https://git.kernel.org/stable/c/4271515f189bd5fe2ec86b4089dab7cb804625d2
- https://git.kernel.org/stable/c/45fecdb9f658d9c82960c98240bc0770ade19aca
- https://git.kernel.org/stable/c/4749c5cc147c9860b96db1e71cc36d1de1bd3f59
- https://git.kernel.org/stable/c/48bd5d3801f6b67cc144449d434abbd5043a6d37
- https://git.kernel.org/stable/c/5ee6413d3dd972930af787b2c0c7aaeb379fa521
- https://git.kernel.org/stable/c/71d591ef873f9ebb86cd8d053b3caee785b2de6a
- https://git.kernel.org/stable/c/b2bc053ebbba57a06fa655db5ea796de2edce445
- https://git.kernel.org/stable/c/e364ce04d8f840478b09eee57b614de7cf1e743e
Modified: 2024-10-25
CVE-2022-48974
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: fix using __this_cpu_add in preemptible
Currently in nf_conntrack_hash_check_insert(), when it fails in
nf_ct_ext_valid_pre/post(), NF_CT_STAT_INC() will be called in the
preemptible context, a call trace can be triggered:
BUG: using __this_cpu_add() in preemptible [00000000] code: conntrack/1636
caller is nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]
Call Trace:
Modified: 2024-10-25
CVE-2022-48975
In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable.
Modified: 2024-10-25
CVE-2022-48976
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable_offload: fix using __this_cpu_add in preemptible
flow_offload_queue_work() can be called in workqueue without
bh disabled, like the call trace showed in my act_ct testing,
calling NF_FLOW_TABLE_STAT_INC() there would cause a call
trace:
BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u4:0/138560
caller is flow_offload_queue_work+0xec/0x1b0 [nf_flow_table]
Workqueue: act_ct_workqueue tcf_ct_flow_table_cleanup_work [act_ct]
Call Trace:
Modified: 2024-10-25
CVE-2022-48977
In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()") we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") the check for dev->type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly.
- https://git.kernel.org/stable/c/0acc442309a0a1b01bcdaa135e56e6398a49439c
- https://git.kernel.org/stable/c/3982652957e8d79ac32efcb725450580650a8644
- https://git.kernel.org/stable/c/c142cba37de29f740a3852f01f59876af8ae462a
- https://git.kernel.org/stable/c/c42221efb1159d6a3c89e96685ee38acdce86b6f
- https://git.kernel.org/stable/c/fcc63f2f7ee3038d53216edd0d8291e57c752557
Modified: 2024-10-25
CVE-2022-48978
In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix shift-out-of-bounds in hid_report_raw_event
Syzbot reported shift-out-of-bounds in hid_report_raw_event.
microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/151493fe5a6ed1a88decc929a7368a3f2a246914
- https://git.kernel.org/stable/c/2b3b4d7aadaa1b6b58d0f34823bf86cfe8a31b4d
- https://git.kernel.org/stable/c/809783f8b4b600c7fb3bccb10fefef822601ea3b
- https://git.kernel.org/stable/c/8e14f20e12224ee2429f75a5c9418a700e26a8d3
- https://git.kernel.org/stable/c/bc03f809da78fc79e4aee132d4e5c6a2b3aeec73
- https://git.kernel.org/stable/c/db1ed1b3fb4ec0d19080a102956255769bc45c79
- https://git.kernel.org/stable/c/ec61b41918587be530398b0d1c9a0d16619397e5
- https://git.kernel.org/stable/c/f755d11c55b29049b77da5cd9ab2faae96eb33c3
Modified: 2024-10-25
CVE-2022-48979
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix array index out of bound error in DCN32 DML [Why&How] LinkCapacitySupport array is indexed with the number of voltage states and not the number of max DPPs. Fix the error by changing the array declaration to use the correct (larger) array size of total number of voltage states.
Modified: 2024-10-25
CVE-2022-48980
In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing() The SJA1105 family has 45 L2 policing table entries (SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110 (SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but accounting for the difference in port count (5 in SJA1105 vs 10 in SJA1110) does not fully explain the difference. Rather, the SJA1110 also has L2 ingress policers for multicast traffic. If a packet is classified as multicast, it will be processed by the policer index 99 + SRCPORT. The sja1105_init_l2_policing() function initializes all L2 policers such that they don't interfere with normal packet reception by default. To have a common code between SJA1105 and SJA1110, the index of the multicast policer for the port is calculated because it's an index that is out of bounds for SJA1105 but in bounds for SJA1110, and a bounds check is performed. The code fails to do the proper thing when determining what to do with the multicast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast" index will be equal to 45, which is also equal to table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes through the check. But at the same time, SJA1105 doesn't have multicast policers. So the code programs the SHARINDX field of an out-of-bounds element in the L2 Policing table of the static config. The comparison between index 45 and 45 entries should have determined the code to not access this policer index on SJA1105, since its memory wasn't even allocated. With enough bad luck, the out-of-bounds write could even overwrite other valid kernel data, but in this case, the issue was detected using KASAN. Kernel log: sja1105 spi5.0: Probed switch chip: SJA1105Q ================================================================== BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340 Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8 ... Workqueue: events_unbound deferred_probe_work_func Call trace: ... sja1105_setup+0x1cbc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... Allocated by task 8: ... sja1105_setup+0x1bcc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ...
Modified: 2024-10-25
CVE-2022-48981
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove errant put in error path drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free.
- https://git.kernel.org/stable/c/24013314be6ee4ee456114a671e9fa3461323de8
- https://git.kernel.org/stable/c/585a07b820059462e0c93b76c7de2cd946b26b40
- https://git.kernel.org/stable/c/586847b98e20ab02212ca5c1fc46680384e68a28
- https://git.kernel.org/stable/c/6a4da05acd062ae7774b6b19cef2b7d922902d36
- https://git.kernel.org/stable/c/83e3da8bb92fcfa7a1d232cf55f9e6c49bb84942
Modified: 2025-09-08
CVE-2022-48982
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix crash when replugging CSR fake controllers
It seems fake CSR 5.0 clones can cause the suspend notifier to be
registered twice causing the following kernel panic:
[ 71.986122] Call Trace:
[ 71.986124]
Modified: 2024-10-25
CVE-2022-48983
In the Linux kernel, the following vulnerability has been resolved:
io_uring: Fix a null-ptr-deref in io_tctx_exit_cb()
Syzkaller reports a NULL deref bug as follows:
BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3
Read of size 4 at addr 0000000000000138 by task file1/1955
CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
Modified: 2024-10-25
CVE-2022-48984
In the Linux kernel, the following vulnerability has been resolved:
can: slcan: fix freed work crash
The LTP test pty03 is causing a crash in slcan:
BUG: kernel NULL pointer dereference, address: 0000000000000008
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
Workqueue: 0x0 (events)
RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185)
Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e
RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968
RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0
RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734
R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000
R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0
FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0
Call Trace:
Modified: 2024-11-07
CVE-2022-48985
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix race on per-CQ variable napi work_done After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->work_done. If the other thread (for example, from busy_poll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic. To fix this issue, save the per-CQ work_done variable in a local variable before napi_complete_done(), so it won't be corrupted by a possible concurrent thread after napi_complete_done(). Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done variable race is fixed, so the driver is able to reliably support features like busy_poll.
Modified: 2024-11-01
CVE-2022-48986
In the Linux kernel, the following vulnerability has been resolved:
mm/gup: fix gup_pud_range() for dax
For dax pud, pud_huge() returns true on x86. So the function works as long
as hugetlb is configured. However, dax doesn't depend on hugetlb.
Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed
devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as
well.
This fixes the below kernel panic:
general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP
< snip >
Call Trace:
- https://git.kernel.org/stable/c/04edfa3dc06ecfc6133a33bc7271298782dee875
- https://git.kernel.org/stable/c/3ac29732a2ffa64c7de13a072b0f2848b9c11037
- https://git.kernel.org/stable/c/e06d13c36ded750c72521b600293befebb4e56c5
- https://git.kernel.org/stable/c/f1cf856123ceb766c49967ec79b841030fa1741f
- https://git.kernel.org/stable/c/fcd0ccd836ffad73d98a66f6fea7b16f735ea920
Modified: 2024-11-01
CVE-2022-48988
In the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type.
- https://git.kernel.org/stable/c/0ed074317b835caa6c03bcfa8f133365324673dc
- https://git.kernel.org/stable/c/35963b31821920908e397146502066f6b032c917
- https://git.kernel.org/stable/c/4a7ba45b1a435e7097ca0f79a847d0949d0eb088
- https://git.kernel.org/stable/c/aad8bbd17a1d586005feb9226c2e9cfce1432e13
- https://git.kernel.org/stable/c/b77600e26fd48727a95ffd50ba1e937efb548125
- https://git.kernel.org/stable/c/e1ae97624ecf400ea56c238bff23e5cd139df0b8
- https://git.kernel.org/stable/c/f1f7f36cf682fa59db15e2089039a2eeb58ff2ad
Modified: 2024-10-25
CVE-2022-48989
In the Linux kernel, the following vulnerability has been resolved: fscache: Fix oops due to race with cookie_lru and use_cookie If a cookie expires from the LRU and the LRU_DISCARD flag is set, but the state machine has not run yet, it's possible another thread can call fscache_use_cookie and begin to use it. When the cookie_worker finally runs, it will see the LRU_DISCARD flag set, transition the cookie->state to LRU_DISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed the below oops will occur because the object associated with the cookie is now NULL. Fix the oops by clearing the LRU_DISCARD bit if another thread uses the cookie before the cookie_worker runs. BUG: kernel NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Call Trace: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 kthread+0xd6/0x100
Modified: 2024-10-25
CVE-2022-48990
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix use-after-free during gpu recovery
[Why]
[ 754.862560] refcount_t: underflow; use-after-free.
[ 754.862898] Call Trace:
[ 754.862903]
Modified: 2024-11-07
CVE-2022-48991
In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.
- https://git.kernel.org/stable/c/1a3f8c6cd29d9078cc81b29d39d0e9ae1d6a03c3
- https://git.kernel.org/stable/c/275c626c131cfe141beeb6c575e31fa53d32da19
- https://git.kernel.org/stable/c/5450535901d89a5dcca5fbbc59a24fe89caeb465
- https://git.kernel.org/stable/c/5ffc2a75534d9d74d49760f983f8eb675fa63d69
- https://git.kernel.org/stable/c/7f445ca2e0e59c7971d0b7b853465e50844ab596
- https://git.kernel.org/stable/c/c23105673228c349739e958fa33955ed8faddcaf
- https://git.kernel.org/stable/c/f268f6cf875f3220afc77bdd0bf1bb136eb54db9
- https://git.kernel.org/stable/c/ff2a1a6f869650aec99e9d070b5ab625bfbc5bc3
Modified: 2024-10-25
CVE-2022-48992
In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-pcm: Add NULL check in BE reparenting Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test.
- https://git.kernel.org/stable/c/0760acc2e6598ad4f7bd3662db2d907ef0838139
- https://git.kernel.org/stable/c/34a9796bf0684bfd54e96a142560d560c21c983b
- https://git.kernel.org/stable/c/9f74b9aa8d58c18927bb9b65dd5ba70a5fd61615
- https://git.kernel.org/stable/c/d4dd21a79dbb862d2ebcf9ed90e646416009ff0d
- https://git.kernel.org/stable/c/db8f91d424fe0ea6db337aca8bc05908bbce1498
- https://git.kernel.org/stable/c/e7166d6821c15f3516bcac8ae3f155924da1908c
- https://git.kernel.org/stable/c/f2ba66d8738584d124aff4e760ed1337f5f6dfb6
- https://git.kernel.org/stable/c/f6f45e538328df9ce66aa61bafee1a5717c4b700
Modified: 2024-11-07
CVE-2022-48994
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.
- https://git.kernel.org/stable/c/05530ef7cf7c7d700f6753f058999b1b5099a026
- https://git.kernel.org/stable/c/13ee8fb5410b740c8dd2867d3557c7662f7dda2d
- https://git.kernel.org/stable/c/15c42ab8d43acb73e2eba361ad05822c0af0ecfa
- https://git.kernel.org/stable/c/2f46e95bf344abc4e74f8158901d32a869e0adb6
- https://git.kernel.org/stable/c/63badfed200219ca656968725f1a43df293ac936
- https://git.kernel.org/stable/c/b38486e82ecb9f3046e0184205f6b61408fc40c9
- https://git.kernel.org/stable/c/e385360705a0b346bdb57ce938249175d0613b8a
- https://git.kernel.org/stable/c/fccd454129f6a0739651f7f58307cdb631fd6e89
Modified: 2024-10-25
CVE-2022-48995
In the Linux kernel, the following vulnerability has been resolved: Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send() There is a kmemleak when test the raydium_i2c_ts with bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff88812d3675c8 (size 8): comm "python3", pid 349, jiffies 4294741070 (age 95.692s) hex dump (first 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed.
Modified: 2024-11-07
CVE-2022-48996
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes() Commit da87878010e5 ("mm/damon/sysfs: support online inputs update") made 'damon_sysfs_set_schemes()' to be called for running DAMON context, which could have schemes. In the case, DAMON sysfs interface is supposed to update, remove, or add schemes to reflect the sysfs files. However, the code is assuming the DAMON context wouldn't have schemes at all, and therefore creates and adds new schemes. As a result, the code doesn't work as intended for online schemes tuning and could have more than expected memory footprint. The schemes are all in the DAMON context, so it doesn't leak the memory, though. Remove the wrong asssumption (the DAMON context wouldn't have schemes) in 'damon_sysfs_set_schemes()' to fix the bug.
Modified: 2024-11-07
CVE-2022-48997
In the Linux kernel, the following vulnerability has been resolved: char: tpm: Protect tpm_pm_suspend with locks Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system. Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex. [Jason: reworked commit message, added metadata]
- https://git.kernel.org/stable/c/23393c6461422df5bf8084a086ada9a7e17dc2ba
- https://git.kernel.org/stable/c/25b78bf98b07ff5aceb9b1e24f72ec0236c5c053
- https://git.kernel.org/stable/c/4e0d6c687c925e27fd4bc78a2721d10acf5614d6
- https://git.kernel.org/stable/c/571b6bbbf54d835ea6120f65575cb55cd767e603
- https://git.kernel.org/stable/c/d699373ac5f3545243d3c73a1ccab77fdef8cec6
Modified: 2024-11-07
CVE-2022-48998
In the Linux kernel, the following vulnerability has been resolved:
powerpc/bpf/32: Fix Oops on tail call tests
test_bpf tail call tests end up as:
test_bpf: #0 Tail call leaf jited:1 85 PASS
test_bpf: #1 Tail call 2 jited:1 111 PASS
test_bpf: #2 Tail call 3 jited:1 145 PASS
test_bpf: #3 Tail call 4 jited:1 170 PASS
test_bpf: #4 Tail call load/store leaf jited:1 190 PASS
test_bpf: #5 Tail call load/store jited:1
BUG: Unable to handle kernel data access on write at 0xf1b4e000
Faulting instruction address: 0xbe86b710
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Hash PowerMac
Modules linked in: test_bpf(+)
CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195
Hardware name: PowerMac3,1 750CL 0x87210 PowerMac
NIP: be86b710 LR: be857e88 CTR: be86b704
REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+)
MSR: 00009032
Modified: 2024-10-31
CVE-2022-48999
In the Linux kernel, the following vulnerability has been resolved: ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match: fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961 fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753 inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874 Separate nexthop objects are mutually exclusive with the legacy multipath spec. Fix fib_nh_match to return if the config for the to be deleted route contains a multipath spec while the fib_info is using a nexthop object.
- https://git.kernel.org/stable/c/0b5394229ebae09afc07aabccb5ffd705ffd250e
- https://git.kernel.org/stable/c/25174d91e4a32a24204060d283bd5fa6d0ddf133
- https://git.kernel.org/stable/c/61b91eb33a69c3be11b259c5ea484505cd79f883
- https://git.kernel.org/stable/c/bb20a2ae241be846bc3c11ea4b3a3c69e41d51f2
- https://git.kernel.org/stable/c/cc3cd130ecfb8b0ae52e235e487bae3f16a24a32
Modified: 2024-10-31
CVE-2022-49000
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in has_external_pci() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() before 'return true' to avoid reference count leak.
Modified: 2024-10-30
CVE-2022-49001
In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack overflow, riscv firstly switches to the so called shadow stack, then use this shadow stack to call the get_overflow_stack() to get the overflow stack. However, there's a race here if two or more harts use the same shadow stack at the same time. To solve this race, we introduce spin_shadow_stack atomic var, which will be swap between its own address and 0 in atomic way, when the var is set, it means the shadow_stack is being used; when the var is cleared, it means the shadow_stack isn't being used. [Palmer: Add AQ to the swap, and also some comments.]
Modified: 2024-10-25
CVE-2022-49002
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak.
- https://git.kernel.org/stable/c/2a8f7b90681472948de172dbbf5a54cd342870aa
- https://git.kernel.org/stable/c/4bedbbd782ebbe7287231fea862c158d4f08a9e3
- https://git.kernel.org/stable/c/71c4a621985fc051ab86d3a86c749069a993fcb2
- https://git.kernel.org/stable/c/876d7bfb89273997056220029ff12b1c2cc4691d
- https://git.kernel.org/stable/c/a5c65cd56aed027f8a97fda8b691caaeb66d115e
- https://git.kernel.org/stable/c/bdb613ef179ad4bb9d56a2533e9b30e434f1dfb7
- https://git.kernel.org/stable/c/cbdd83bd2fd67142b03ce9dbdd1eab322ff7321f
- https://git.kernel.org/stable/c/d47bc9d7bcdbb9adc9703513d964b514fee5b0bf
Modified: 2024-10-25
CVE-2022-49003
In the Linux kernel, the following vulnerability has been resolved: nvme: fix SRCU protection of nvme_ns_head list Walking the nvme_ns_head siblings list is protected by the head's srcu in nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees. Hold the head's srcu lock in nvme_mpath_revalidate_paths() and synchronize with the srcu, not the global RCU, in nvme_ns_remove(). Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != get_capacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic). [37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1 [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018 [37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core] [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core] [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Call Trace: [37315.828515] nvme_update_ns_info+0x1ac/0x250 [nvme_core] [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core] [37315.961871] ? __blk_mq_free_request+0x6b/0x90 [37316.015021] nvme_scan_work+0x151/0x240 [nvme_core] [37316.073371] process_one_work+0x1a7/0x360 [37316.121318] ? create_worker+0x1a0/0x1a0 [37316.168227] worker_thread+0x30/0x390 [37316.212024] ? create_worker+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? set_kthread_struct+0x50/0x50 [37316.347590] ret_from_fork+0x35/0x40 [37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex ---truncated---
Modified: 2024-10-25
CVE-2022-49004
In the Linux kernel, the following vulnerability has been resolved: riscv: Sync efi page table's kernel mappings before switching The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic. Fix that by updating the efi kernel mappings before switching to the efi page table.
Modified: 2024-10-25
CVE-2022-49005
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Fix bounds check for _sx controls For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in snd_soc_put_volsw_sx() needs to just check against the maximum value.
- https://git.kernel.org/stable/c/325d94d16e3131b54bdf07356e4cd855e0d853fc
- https://git.kernel.org/stable/c/46bab25cc0230df60d1c02b651cc5640a14b08df
- https://git.kernel.org/stable/c/4a95a49f26308782b4056401989ecd7768fda8fa
- https://git.kernel.org/stable/c/698813ba8c580efb356ace8dbf55f61dac6063a8
- https://git.kernel.org/stable/c/73dce3c1d48c4662bdf3ccbde1492c2cb4bfd8ce
- https://git.kernel.org/stable/c/98b15c706644bebc19d2e77ccc360cc51444f6d0
- https://git.kernel.org/stable/c/b50c9641897274c3faef5f95ac852f54b94be2e8
- https://git.kernel.org/stable/c/e46adadf19248d59af3aa6bc52e09115bf479bf7
Modified: 2024-11-04
CVE-2022-49006
In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="��������������������������������������� ---truncated---
- https://git.kernel.org/stable/c/1603feac154ff38514e8354e3079a455eb4801e2
- https://git.kernel.org/stable/c/417d5ea6e735e5d88ffb6c436cf2938f3f476dd1
- https://git.kernel.org/stable/c/4313e5a613049dfc1819a6dfb5f94cf2caff9452
- https://git.kernel.org/stable/c/be111ebd8868d4b7c041cb3c6102e1ae27d6dc1d
- https://git.kernel.org/stable/c/c52d0c8c4f38f7580cff61c4dfe1034c580cedfd
Modified: 2024-10-25
CVE-2022-49007
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()
Syzbot reported a null-ptr-deref bug:
NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP
frequency < 30 seconds
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 3603 Comm: segctord Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google
10/11/2022
RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0
fs/nilfs2/alloc.c:608
Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00
00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7
RSP: 0018:ffffc90003dff830 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d
RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010
RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f
R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158
R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004
FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0
Call Trace:
- https://git.kernel.org/stable/c/165c7a3b27a3857ebf57f626b9f38b48b6792e68
- https://git.kernel.org/stable/c/2f2c59506ae39496588ceb8b88bdbdbaed895d63
- https://git.kernel.org/stable/c/33021419fd81efd3d729a7f19341ba4b98fe66ce
- https://git.kernel.org/stable/c/381b84f60e549ea98cec4666c6c728b1b3318756
- https://git.kernel.org/stable/c/9a130b72e6bd1fb07fc3cde839dc6fb53da76f07
- https://git.kernel.org/stable/c/bc3fd3293887b4cf84a9109700faeb82de533c89
- https://git.kernel.org/stable/c/e858917ab785afe83c14f5ac141301216ccda847
- https://git.kernel.org/stable/c/f0a0ccda18d6fd826d7c7e7ad48a6ed61c20f8b4
Modified: 2024-10-25
CVE-2022-49008
In the Linux kernel, the following vulnerability has been resolved: can: can327: can327_feed_frame_to_netdev(): fix potential skb leak when netdev is down In can327_feed_frame_to_netdev(), it did not free the skb when netdev is down, and all callers of can327_feed_frame_to_netdev() did not free allocated skb too. That would trigger skb leak. Fix it by adding kfree_skb() in can327_feed_frame_to_netdev() when netdev is down. Not tested, just compiled.
Modified: 2024-10-24
CVE-2022-49009
In the Linux kernel, the following vulnerability has been resolved: hwmon: (asus-ec-sensors) Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference.
Modified: 2024-10-24
CVE-2022-49010
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Check for null before removing sysfs attrs
If coretemp_add_core() gets an error then pdata->core_data[indx]
is already NULL and has been kfreed. Don't pass that to
sysfs_remove_group() as that will crash in sysfs_remove_group().
[Shortened for readability]
[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'
- https://git.kernel.org/stable/c/070d5ea4a0592a37ad96ce7f7b6b024f90bb009f
- https://git.kernel.org/stable/c/280110db1a7d62ad635b103bafc3ae96e8bef75c
- https://git.kernel.org/stable/c/7692700ac818866d138a8de555130a6e70e6ac16
- https://git.kernel.org/stable/c/89eecabe6a47403237f45aafd7d24f93cb973653
- https://git.kernel.org/stable/c/a89ff5f5cc64b9fe7a992cf56988fd36f56ca82a
- https://git.kernel.org/stable/c/ae6c8b6e5d5628df1c475c0a8fca1465e205c95b
- https://git.kernel.org/stable/c/f06e0cd01eab954bd5f2190c9faa79bb5357e05b
- https://git.kernel.org/stable/c/fb503d077ff7b43913503eaf72995d1239028b99
Modified: 2024-10-24
CVE-2022-49011
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it after using to avoid refcount leak.
- https://git.kernel.org/stable/c/0dd1da5a15eeecb2fe4cf131b3216fb455af783c
- https://git.kernel.org/stable/c/2f74cffc7c85f770b1b1833dccb03b8cde3be102
- https://git.kernel.org/stable/c/6e035d5a2a6b907cfce9a80c5f442c2e459cd34e
- https://git.kernel.org/stable/c/7dec14537c5906b8bf40fd6fd6d9c3850f8df11d
- https://git.kernel.org/stable/c/bb75a0d1223d43f97089841aecb28a9b4de687a9
- https://git.kernel.org/stable/c/c40db1e5f316792b557d2be37e447c20d9ac4635
- https://git.kernel.org/stable/c/ea5844f946b1ec5c0b7c115cd7684f34fd48021b
- https://git.kernel.org/stable/c/f598da27acbeee414679cacd14294db3e273e3d2
Modified: 2024-10-24
CVE-2022-49012
In the Linux kernel, the following vulnerability has been resolved: afs: Fix server->active leak in afs_put_server The atomic_read was accidentally replaced with atomic_inc_return, which prevents the server from getting cleaned up and causes rmmod to hang with a warning: Can't purge s=00000001
Modified: 2024-10-24
CVE-2022-49013
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix memory leak in sctp_stream_outq_migrate()
When sctp_stream_outq_migrate() is called to release stream out resources,
the memory pointed to by prio_head in stream out is not released.
The memory leak information is as follows:
unreferenced object 0xffff88801fe79f80 (size 64):
comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s)
hex dump (first 32 bytes):
80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................
90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................
backtrace:
[
- https://git.kernel.org/stable/c/0dfb9a566327182387c90100ea54d8426cee8c67
- https://git.kernel.org/stable/c/176ee6c673ccd118e9392fd2dbb165423bdb99ca
- https://git.kernel.org/stable/c/9ed7bfc79542119ac0a9e1ce8a2a5285e43433e9
- https://git.kernel.org/stable/c/a7555681e50bdebed2c40ff7404ee73c2e932993
- https://git.kernel.org/stable/c/fa20f88271259d42ebe66f0a8c4c20199e888c99
Modified: 2024-10-24
CVE-2022-49014
In the Linux kernel, the following vulnerability has been resolved:
net: tun: Fix use-after-free in tun_detach()
syzbot reported use-after-free in tun_detach() [1]. This causes call
trace like below:
==================================================================
BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673
CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/04b995e963229501401810dab89dc73e7f12d054
- https://git.kernel.org/stable/c/16c244bc65d1175775325ec0489a5a5c830e02c7
- https://git.kernel.org/stable/c/1f23f1890d91812c35d32eab1b49621b6d32dc7b
- https://git.kernel.org/stable/c/4cde8da2d814a3b7b176db81922d4ddaad7c0f0e
- https://git.kernel.org/stable/c/5daadc86f27ea4d691e2131c04310d0418c6cd12
- https://git.kernel.org/stable/c/5f442e1d403e0496bacb74a58e2be7f500695e6f
Modified: 2024-10-24
CVE-2022-49015
In the Linux kernel, the following vulnerability has been resolved: net: hsr: Fix potential use-after-free The skb is delivered to netif_rx() which may free it, after calling this, dereferencing skb may trigger use-after-free.
- https://git.kernel.org/stable/c/4b351609af4fdbc23f79ab2b12748f4403ea9af4
- https://git.kernel.org/stable/c/53a62c5efe91665f7a41fad0f888a96f94dc59eb
- https://git.kernel.org/stable/c/7ca81a161e406834a1fdc405fc83a572bd14b8d9
- https://git.kernel.org/stable/c/7e177d32442b7ed08a9fa61b61724abc548cb248
- https://git.kernel.org/stable/c/8393ce5040803666bfa26a3a7bf41e44fab0ace9
- https://git.kernel.org/stable/c/b35d899854d5d5d58eb7d7e7c0f61afc60d3a9e9
- https://git.kernel.org/stable/c/dca370e575d9b6c983f5015e8dc035e23e219ee6
- https://git.kernel.org/stable/c/f3add2b8cf620966de3ebfa07679ca12d33ec26f
Modified: 2024-10-24
CVE-2022-49016
In the Linux kernel, the following vulnerability has been resolved: net: mdiobus: fix unbalanced node reference count I got the following report while doing device(mscc-miim) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0 If the 'fwnode' is not an acpi node, the refcount is get in fwnode_mdiobus_phy_device_register(), but it has never been put when the device is freed in the normal path. So call fwnode_handle_put() in phy_device_release() to avoid leak. If it's an acpi node, it has never been get, but it's put in the error path, so call fwnode_handle_get() before phy_device_register() to keep get/put operation balanced.
Modified: 2024-10-24
CVE-2022-49017
In the Linux kernel, the following vulnerability has been resolved:
tipc: re-fetch skb cb after tipc_msg_validate
As the call trace shows, the original skb was freed in tipc_msg_validate(),
and dereferencing the old skb cb would cause an use-after-free crash.
BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
Call Trace:
Modified: 2024-10-24
CVE-2022-49018
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix sleep in atomic at close time
Matt reported a splat at msk close time:
BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill
preempt_count: 201, expected: 0
RCU nest depth: 0, expected: 0
4 locks held by packetdrill/155:
#0: ffff888001536990 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650)
#1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973)
#2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363)
#3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820)
Preemption disabled at:
0x0
CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
Modified: 2024-10-24
CVE-2022-49019
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/45752af0247589e6d3dede577415bfe117b4392c
- https://git.kernel.org/stable/c/80e82f7b440b65cf131dce10f487dc73a7046e6b
- https://git.kernel.org/stable/c/910c0264b64ef2dad8887714a7c56c93e39a0ed3
- https://git.kernel.org/stable/c/9256db4e45e8b497b0e993cc3ed4ad08eb2389b6
- https://git.kernel.org/stable/c/9c584d6d9cfb935dce8fc81a4c26debac0a3049b
Modified: 2024-10-24
CVE-2022-49020
In the Linux kernel, the following vulnerability has been resolved: net/9p: Fix a potential socket leak in p9_socket_open Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak. This patch adds sock_release() to fix the leak issue.
- https://git.kernel.org/stable/c/0396227f4daf4792a6a8aaa3b7771dc25c4cd443
- https://git.kernel.org/stable/c/2d24d91b9f44620824fc37b766f7cae00ca32748
- https://git.kernel.org/stable/c/8782b32ef867de7981bbe9e86ecb90e92e8780bd
- https://git.kernel.org/stable/c/8b14bd0b500aec1458b51cb621c8e5fab3304260
- https://git.kernel.org/stable/c/aa08323fe18cb7cf95317ffa2d54ca1de8e74ebd
- https://git.kernel.org/stable/c/dcc14cfd7debe11b825cb077e75d91d2575b4cb8
- https://git.kernel.org/stable/c/ded893965b895b2dccd3d1436d8d3daffa23ea64
- https://git.kernel.org/stable/c/e01c1542379fb395e7da53706df598f38905dfbf
Modified: 2024-10-24
CVE-2022-49021
In the Linux kernel, the following vulnerability has been resolved:
net: phy: fix null-ptr-deref while probe() failed
I got a null-ptr-deref report as following when doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
- https://git.kernel.org/stable/c/0744c7be4de564db03e24527b2e096b7e0e20972
- https://git.kernel.org/stable/c/369eb2c9f1f72adbe91e0ea8efb130f0a2ba11a6
- https://git.kernel.org/stable/c/3e21f85d87c836462bb52ef2078ea561260935c1
- https://git.kernel.org/stable/c/51d7f6b20fae8bae64ad1136f1e30d1fd5ba78f7
- https://git.kernel.org/stable/c/7730904f50c7187dd16c76949efb56b5fb55cd57
- https://git.kernel.org/stable/c/8aaafe0f71314f46a066382a047ba8bb3840d273
- https://git.kernel.org/stable/c/eaa5722549ac2604ffa56c2e946acc83226f130c
- https://git.kernel.org/stable/c/fe6bc99c27c21348f548966118867ed26a9a372c
Modified: 2024-10-24
CVE-2022-49022
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration
Fix possible out-of-bound access in ieee80211_get_rate_duration routine
as reported by the following UBSAN report:
UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47
index 15 is out of range for type 'u16 [12]'
CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic
Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017
Workqueue: mt76 mt76u_tx_status_data [mt76_usb]
Call Trace:
Modified: 2024-10-24
CVE-2022-49023
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix buffer overflow in elem comparison For vendor elements, the code here assumes that 5 octets are present without checking. Since the element itself is already checked to fit, we only need to check the length.
- https://git.kernel.org/stable/c/391cb872553627bdcf236c03ee7d5adb275e37e1
- https://git.kernel.org/stable/c/88a6fe3707888bd1893e9741157a7035c4159ab6
- https://git.kernel.org/stable/c/9e6b79a3cd17620d467311b30d56f2648f6880aa
- https://git.kernel.org/stable/c/9f16b5c82a025cd4c864737409234ddc44fb166a
- https://git.kernel.org/stable/c/f5c2ec288a865dbe3706b09bed12302e9f6d696b
Modified: 2024-10-24
CVE-2022-49024
In the Linux kernel, the following vulnerability has been resolved: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods In m_can_pci_remove() and error handling path of m_can_pci_probe(), m_can_class_free_dev() should be called to free resource allocated by m_can_class_allocate_dev(), otherwise there will be memleak.
Modified: 2024-10-24
CVE-2022-49025
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free when reverting termination table When having multiple dests with termination tables and second one or afterwards fails the driver reverts usage of term tables but doesn't reset the assignment in attr->dests[num_vport_dests].termtbl which case a use-after-free when releasing the rule. Fix by resetting the assignment of termtbl to null.
- https://git.kernel.org/stable/c/0a2d73a77060c3cbdc6e801cd5d979d674cd404b
- https://git.kernel.org/stable/c/0d2f9d95d9fbe993f3c4bafb87d59897b0325aff
- https://git.kernel.org/stable/c/372eb550faa0757349040fd43f59483cbfdb2c0b
- https://git.kernel.org/stable/c/52c795af04441d76f565c4634f893e5b553df2ae
- https://git.kernel.org/stable/c/e6d2d26a49c3a9cd46b232975e45236304810904
Modified: 2024-10-24
CVE-2022-49026
In the Linux kernel, the following vulnerability has been resolved: e100: Fix possible use after free in e100_xmit_prepare In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will resend the skb. But the skb is already freed, which will cause UAF bug when the upper layer resends the skb. Remove the harmful free.
Modified: 2024-10-24
CVE-2022-49027
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix error handling in iavf_init_module() The iavf_init_module() won't destroy workqueue when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak")
Modified: 2024-10-24
CVE-2022-49028
In the Linux kernel, the following vulnerability has been resolved: ixgbevf: Fix resource leak in ixgbevf_init_module() ixgbevf_init_module() won't destroy the workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Add destroy_workqueue() in fail path to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak")
Modified: 2024-10-24
CVE-2022-49029
In the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().
- https://git.kernel.org/stable/c/24b9633f7db7f4809be7053df1d2e117e7c2de10
- https://git.kernel.org/stable/c/45f6e81863747c0d7bc6a95ec51129900e71467a
- https://git.kernel.org/stable/c/798198273bf86673b970b51acdb35e57f42b3fcb
- https://git.kernel.org/stable/c/7b2b67fe1339389e0bf3c37c7a677a004ac0e4e3
- https://git.kernel.org/stable/c/90907cd4d11351ff76c9a447bcb5db0e264c47cd
- https://git.kernel.org/stable/c/e2a87785aab0dac190ac89be6a9ba955e2c634f2
- https://git.kernel.org/stable/c/e65cfd1f9cd27d9c27ee5cb88128a9f79f25d863
- https://git.kernel.org/stable/c/f2a13196ad41c6c2ab058279dffe6c97292e753a
Modified: 2024-10-24
CVE-2022-49030
In the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap.
Modified: 2024-10-24
CVE-2022-49031
In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4403: Fix oob read in afe4403_read_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279 Call Trace: afe4403_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 This issue can be reproduced by singe command: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw The array size of afe4403_channel_leds is less than channels, so access with chan->address cause OOB read in afe4403_read_raw. Fix it by moving access before use it.
- https://git.kernel.org/stable/c/06c6ce21cec77dfa860d57e7a006000a57812efb
- https://git.kernel.org/stable/c/2d6a437064ffbe685c67ddb16dfc0946074c6c3f
- https://git.kernel.org/stable/c/58143c1ed5882c138a3cd2251a336fc8755f23d9
- https://git.kernel.org/stable/c/726fa3e4ab97dcff1c745bdc4fb137366cb8d3df
- https://git.kernel.org/stable/c/98afcb5f3be645d330c74c5194ba0d80e26f95e0
- https://git.kernel.org/stable/c/b1756af172fb80a3edc143772d49e166ec691b6c
- https://git.kernel.org/stable/c/c9268df36818ee4eaaaeadc80009b442a5ca69c9
- https://git.kernel.org/stable/c/e7e76a77aabef8989cbc0a8417af1aa040620867
Modified: 2024-10-24
CVE-2022-49032
In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan->address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them.
- https://git.kernel.org/stable/c/113c08030a89aaf406f8a1d4549d758a67c2afba
- https://git.kernel.org/stable/c/3f566b626029ca8598d48e5074e56bb37399ca1b
- https://git.kernel.org/stable/c/5eb114f55b37dbc0487aa9c1913b81bb7837f1c4
- https://git.kernel.org/stable/c/68de7da092f38395dde523f2e5db26eba6c23e28
- https://git.kernel.org/stable/c/d45d9f45e7b1365fd0d9bf14680d6d5082a590d1
- https://git.kernel.org/stable/c/f5575041ec15310bdc50c42b8b22118cc900226e
- https://git.kernel.org/stable/c/f7419fc42afc035f6b29ce713e17dcd2000c833f
- https://git.kernel.org/stable/c/fc92d9e3de0b2d30a3ccc08048a5fad533e4672b
Modified: 2024-10-30
CVE-2022-49033
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()
Syzkaller reported BUG as follows:
BUG: sleeping function called from invalid context at
include/linux/sched/mm.h:274
Call Trace:
- https://git.kernel.org/stable/c/01d7c41eac9129fba80d8aed0060caab4a7dbe09
- https://git.kernel.org/stable/c/044da1a371a0da579e805e89c96865f62d8f6f69
- https://git.kernel.org/stable/c/3c98e91be6aea4c7acf09da6eb0c107ea9186bb5
- https://git.kernel.org/stable/c/588ae4fdd8b11788a797776b10d6c44ae12bc133
- https://git.kernel.org/stable/c/89840b12c8fad7200eb6478525c13261512c01be
- https://git.kernel.org/stable/c/8eb912af525042a7365295eb62f6d5270c2a6462
- https://git.kernel.org/stable/c/f4b930a1602b05e77fee31f9616599b25e910a86
- https://git.kernel.org/stable/c/f7e942b5bb35d8e3af54053d19a6bf04143a3955
Modified: 2025-10-01
CVE-2022-49035
In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case.
- https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c
- https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4
- https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39
- https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a
- https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968964b26c
- https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11
- https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd
- https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c
Modified: 2025-11-06
CVE-2022-49762
In the Linux kernel, the following vulnerability has been resolved: ntfs: check overflow when iterating ATTR_RECORDs Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). Because the ATTR_RECORDs are next to each other, kernel can get the next ATTR_RECORD from end address of current ATTR_RECORD, through current ATTR_RECORD length field. The problem is that during iteration, when kernel calculates the end address of current ATTR_RECORD, kernel may trigger an integer overflow bug in executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. This may wrap, leading to a forever iteration on 32bit systems. This patch solves it by adding some checks on calculating end address of current ATTR_RECORD during iteration.
- https://git.kernel.org/stable/c/45683723f6b53e39e8a4cec0894e61fd6ec71989
- https://git.kernel.org/stable/c/5559eb5809353a83a40a1e4e7f066431c7b83020
- https://git.kernel.org/stable/c/63095f4f3af59322bea984a6ae44337439348fe0
- https://git.kernel.org/stable/c/785b2af9654b8beac55644e36da0085c5d776361
- https://git.kernel.org/stable/c/86f36de14dce5802856bb7a5921d74439db00b64
- https://git.kernel.org/stable/c/957732a09c3828267c2819d31c425aa793dd475b
- https://git.kernel.org/stable/c/b612f924f296408d7d02fb4cd01218afd4ed7184
- https://git.kernel.org/stable/c/b63ddb3ba61e2d3539f87e095c881e552bc45dab
Modified: 2025-11-06
CVE-2022-49763
In the Linux kernel, the following vulnerability has been resolved:
ntfs: fix use-after-free in ntfs_attr_find()
Patch series "ntfs: fix bugs about Attribute", v2.
This patchset fixes three bugs relative to Attribute in record:
Patch 1 adds a sanity check to ensure that, attrs_offset field in first
mft record loading from disk is within bounds.
Patch 2 moves the ATTR_RECORD's bounds checking earlier, to avoid
dereferencing ATTR_RECORD before checking this ATTR_RECORD is within
bounds.
Patch 3 adds an overflow checking to avoid possible forever loop in
ntfs_attr_find().
Without patch 1 and patch 2, the kernel triggersa KASAN use-after-free
detection as reported by Syzkaller.
Although one of patch 1 or patch 2 can fix this, we still need both of
them. Because patch 1 fixes the root cause, and patch 2 not only fixes
the direct cause, but also fixes the potential out-of-bounds bug.
This patch (of 3):
Syzkaller reported use-after-free read as follows:
==================================================================
BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597
Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607
[...]
Call Trace:
- https://git.kernel.org/stable/c/266bd5306286316758e6246ea0345133427b0f62
- https://git.kernel.org/stable/c/4863f815463034f588a035cfd99cdca97a4f1069
- https://git.kernel.org/stable/c/5330c423b86263ac7883fef0260b9e2229cb531e
- https://git.kernel.org/stable/c/79f3ac7dcd12c05b7539239a4c6fa229a50d786c
- https://git.kernel.org/stable/c/b825bfbbaafbe8da2037e3a778ad660c59f9e054
- https://git.kernel.org/stable/c/d0006d739738a658a9c29b438444259d9f71dfa0
- https://git.kernel.org/stable/c/d85a1bec8e8d552ab13163ca1874dcd82f3d1550
- https://git.kernel.org/stable/c/fb2004bafd1932e08d21ca604ee5844f2b7f212d
Modified: 2025-11-06
CVE-2022-49764
In the Linux kernel, the following vulnerability has been resolved:
bpf: Prevent bpf program recursion for raw tracepoint probes
We got report from sysbot [1] about warnings that were caused by
bpf program attached to contention_begin raw tracepoint triggering
the same tracepoint by using bpf_trace_printk helper that takes
trace_printk_lock lock.
Call Trace:
Modified: 2025-11-06
CVE-2022-49765
In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation from Tetsuo Handa's suggested patch[1] (slightly reworded): syzbot is reporting inconsistent lock state in p9_req_put()[2], for p9_tag_remove() from p9_req_put() from IRQ context is using spin_lock_irqsave() on "struct p9_client"->lock but trans_fd (not from IRQ context) is using spin_lock(). Since the locks actually protect different things in client.c and in trans_fd.c, just replace trans_fd.c's lock by a new one specific to the transport (client.c's protect the idr for fid/tag allocations, while trans_fd.c's protects its own req list and request status field that acts as the transport's state machine)
Modified: 2025-11-06
CVE-2022-49766
In the Linux kernel, the following vulnerability has been resolved: netlink: Bounds-check struct nlmsgerr creation In preparation for FORTIFY_SOURCE doing bounds-check on memcpy(), switch from __nlmsg_put to nlmsg_put(), and explain the bounds check for dealing with the memcpy() across a composite flexible array struct. Avoids this future run-time warning: memcpy: detected field-spanning write (size 32) of single field "&errmsg->msg" at net/netlink/af_netlink.c:2447 (size 16)
Modified: 2025-11-06
CVE-2022-49767
In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: always use O_NONBLOCK read/write syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is failing to interrupt already started kernel_read() from p9_fd_read() from p9_read_work() and/or kernel_write() from p9_fd_write() from p9_write_work() requests. Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open() does not set O_NONBLOCK flag, but pipe blocks unless signal is pending, p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when the file descriptor refers to a pipe. In other words, pipe file descriptor needs to be handled as if socket file descriptor. We somehow need to interrupt kernel_read()/kernel_write() on pipes. A minimal change, which this patch is doing, is to set O_NONBLOCK flag from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing of regular files. But this approach changes O_NONBLOCK flag on userspace- supplied file descriptors (which might break userspace programs), and O_NONBLOCK flag could be changed by userspace. It would be possible to set O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still remains small race window for clearing O_NONBLOCK flag. If we don't want to manipulate O_NONBLOCK flag, we might be able to surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING) and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are processed by kernel threads which process global system_wq workqueue, signals could not be delivered from remote threads when p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be needed if we count on signals for making kernel_read()/kernel_write() non-blocking. [Dominique: add comment at Christian's suggestion]
- https://git.kernel.org/stable/c/0b5e6bd72b8171364616841603a70e4ba9837063
- https://git.kernel.org/stable/c/0e07032b4b4724b8ad1003698cb81083c1818999
- https://git.kernel.org/stable/c/5af16182c5639349415118e9e9aecd8355f7a08b
- https://git.kernel.org/stable/c/7abf40f06a76c0dff42eada10597917e9776fbd4
- https://git.kernel.org/stable/c/9f8554615df668e4bf83294633ee9d232b28ce45
- https://git.kernel.org/stable/c/a8e2fc8f7b41fa9d9ca5f624f4e4d34fce5b40a9
- https://git.kernel.org/stable/c/b1ad04da7fe4515e2ce2d5f2dcab3b5b6d45614b
- https://git.kernel.org/stable/c/ef575281b21e9a34dfae544a187c6aac2ae424a9
Modified: 2025-11-06
CVE-2022-49768
In the Linux kernel, the following vulnerability has been resolved: 9p: trans_fd/p9_conn_cancel: drop client lock earlier syzbot reported a double-lock here and we no longer need this lock after requests have been moved off to local list: just drop the lock earlier.
- https://git.kernel.org/stable/c/52f1c45dde9136f964d63a77d19826c8a74e2c7f
- https://git.kernel.org/stable/c/612c977f5d481f551d03d83d0aef588845c1300c
- https://git.kernel.org/stable/c/82825dbf393f7c7979d462f9609a15bde8092b3f
- https://git.kernel.org/stable/c/96760723aae1b45f733f702abb4333137143909f
- https://git.kernel.org/stable/c/a4f1a01b2e81378fce9ca528d4d8a049e4b58fcd
- https://git.kernel.org/stable/c/e3031280fe4eaf61a09e60823331f81f321be8e1
- https://git.kernel.org/stable/c/f14858bc77c567e089965962877ee726ffad0556
- https://git.kernel.org/stable/c/fec1406f5e7ab20b71f6d231792b0040e3300aaf
Modified: 2025-11-06
CVE-2022-49769
In the Linux kernel, the following vulnerability has been resolved: gfs2: Check sb_bsize_shift after reading superblock Fuzzers like to scribble over sb_bsize_shift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value. Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb mount /dev/vdb /mnt/test && umount /mnt/test done Before this patch we get a withdraw after [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [ 76.413681] bh = 19 (type: exp=5, found=4) [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492 and with UBSAN configured we also get complaints like [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int' After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg.
- https://git.kernel.org/stable/c/15c83fa0fd659dd9fbdc940a560b61236e876a80
- https://git.kernel.org/stable/c/16670534c7cff1acd918a6a5ec751b14e7436b76
- https://git.kernel.org/stable/c/1ad197097343568066a8ffaa27ee7d0ae6d9f476
- https://git.kernel.org/stable/c/28275a7c84d21c55ab3282d897f284d8d527173c
- https://git.kernel.org/stable/c/5fa30be7ba81191b0a0c7239a89befc0c94286d5
- https://git.kernel.org/stable/c/670f8ce56dd0632dc29a0322e188cc73ce3c6b92
- https://git.kernel.org/stable/c/8b6534c9ae9dba5489703a19d8ba6c8f2cfa33c2
- https://git.kernel.org/stable/c/d6b1e8ea6f3418c3b461ad5a35cdc93c996b2c87
Modified: 2025-11-06
CVE-2022-49770
In the Linux kernel, the following vulnerability has been resolved: ceph: avoid putting the realm twice when decoding snaps fails When decoding the snaps fails it maybe leaving the 'first_realm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUG_ON, etc issues.
- https://git.kernel.org/stable/c/044bc6d3c2c0e9090b0841e7b723875756534b45
- https://git.kernel.org/stable/c/274e4c79a3a2a24fba7cfe0e41113f1138785c37
- https://git.kernel.org/stable/c/2f6e2de3a5289004650118b61f138fe7c28e1905
- https://git.kernel.org/stable/c/51884d153f7ec85e18d607b2467820a90e0f4359
- https://git.kernel.org/stable/c/cb7495fe957526555782ce0723f79ce92a6db22e
- https://git.kernel.org/stable/c/fd879c83e87735ab8f00ef7755752cf0cbae24b2
Modified: 2025-11-07
CVE-2022-49771
In the Linux kernel, the following vulnerability has been resolved: dm ioctl: fix misbehavior if list_versions races with module loading __list_versions will first estimate the required space using the "dm_target_iterate(list_version_get_needed, &needed)" call and then will fill the space using the "dm_target_iterate(list_version_get_info, &iter_info)" call. Each of these calls locks the targets using the "down_read(&_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and the target modules can be loaded at this point, so the second "dm_target_iterate" call may need more space than what was the first "dm_target_iterate" returned. The code tries to handle this overflow (see the beginning of list_version_get_info), however this handling is incorrect. The code sets "param->data_size = param->data_start + needed" and "iter_info.end = (char *)vers+len" - "needed" is the size returned by the first dm_target_iterate call; "len" is the size of the buffer allocated by userspace. "len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->data_size is set to "needed", so it may write data past the param->data_size value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated. Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this guarantees that the second "dm_target_iterate" call will write only up to the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry. Note that there is also a bug in list_version_get_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".
- https://git.kernel.org/stable/c/0c8d4112df329bf3dfbf27693f918c3b08676538
- https://git.kernel.org/stable/c/3a1c35d72dc0b34d1e746ed705790c0f630aa427
- https://git.kernel.org/stable/c/4fe1ec995483737f3d2a14c3fe1d8fe634972979
- https://git.kernel.org/stable/c/5398b8e275bf81a2517b327d216c0f37ac9ac5ae
- https://git.kernel.org/stable/c/6a818db0d5aecf80d4ba9e10ac153f60adc629ca
- https://git.kernel.org/stable/c/6ffce7a92ef5c68f7e5d6f4d722c2f96280c064b
- https://git.kernel.org/stable/c/b545c0e1e4094d4de2bdfe9a3823f9154b0c0005
- https://git.kernel.org/stable/c/f59f5a269ca5e43c567aca7f1f52500a0186e9b7
Modified: 2025-12-23
CVE-2022-49772
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open() snd_usbmidi_output_open() has a check of the NULL port with snd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened, but in reality, the NULL port may be seen when the device gives an invalid endpoint setup at the descriptor, hence the driver skips the allocation. That is, the check itself is valid and snd_BUG_ON() should be dropped from there. Otherwise it's confusing as if it were a real bug, as recently syzbot stumbled on it.
- https://git.kernel.org/stable/c/00f5f1bbf815a39e9eecb468d12ca55d3360eb10
- https://git.kernel.org/stable/c/02b94885b2fdf1808b1874e009bfb90753f8f4db
- https://git.kernel.org/stable/c/a80369c8ca50bc885d14386087a834659ec54a54
- https://git.kernel.org/stable/c/ad72c3c3f6eb81d2cb189ec71e888316adada5df
- https://git.kernel.org/stable/c/c43991065f36f7628cd124e037b8750c4617a7a7
- https://git.kernel.org/stable/c/e7dc436aea80308a9268e6d2d85f910ff107de9b
Modified: 2025-11-07
CVE-2022-49773
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix optc2_configure warning on dcn314
[Why]
dcn314 uses optc2_configure_crc() that wraps
optc1_configure_crc() + set additional registers
not applicable to dcn314.
It's not critical but when used leads to warning like:
WARNING: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c
Call Trace:
Modified: 2025-11-07
CVE-2022-49774
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/xen: Fix eventfd error handling in kvm_xen_eventfd_assign() Should not call eventfd_ctx_put() in case of error. [Introduce new goto target instead. - Paolo]
Modified: 2025-11-07
CVE-2022-49775
In the Linux kernel, the following vulnerability has been resolved:
tcp: cdg: allow tcp_cdg_release() to be called multiple times
Apparently, mptcp is able to call tcp_disconnect() on an already
disconnected flow. This is generally fine, unless current congestion
control is CDG, because it might trigger a double-free [1]
Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect()
more resilient.
[1]
BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline]
BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567
CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: events mptcp_worker
Call Trace:
- https://git.kernel.org/stable/c/0b19171439016a8e4c97eafe543670ac86e2b8fe
- https://git.kernel.org/stable/c/1b639be27cbf428a5ca01dcf8b5d654194c956f8
- https://git.kernel.org/stable/c/35309be06b6feded2ab2cafbc2bca8534c2fa41e
- https://git.kernel.org/stable/c/4026033907cc6186d86b48daa4a252c860db2536
- https://git.kernel.org/stable/c/72e560cb8c6f80fc2b4afc5d3634a32465e13a51
- https://git.kernel.org/stable/c/78be2ee0112409ae4e9ee9e326151e0559b3d239
- https://git.kernel.org/stable/c/9e481d87349d2282f400ee1d010a169c99f766b8
- https://git.kernel.org/stable/c/b49026d9c86f35a4c5bfb8d7345c9c4379828c6b
Modified: 2025-11-07
CVE-2022-49776
In the Linux kernel, the following vulnerability has been resolved:
macvlan: enforce a consistent minimal mtu
macvlan should enforce a minimal mtu of 68, even at link creation.
This patch avoids the current behavior (which could lead to crashes
in ipv6 stack if the link is brought up)
$ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail !
$ ip link sh dev macvlan1
5: macvlan1@eno1:
- https://git.kernel.org/stable/c/2b055c719d8f94c15ec9b7659978133030c6a353
- https://git.kernel.org/stable/c/650137a7c0b2892df2e5b0bc112d7b09a78c93c8
- https://git.kernel.org/stable/c/a62aa84fe19eb24d083d600a074c009a0a66d4f3
- https://git.kernel.org/stable/c/b64085b00044bdf3cd1c9825e9ef5b2e0feae91a
- https://git.kernel.org/stable/c/d2fee7d121d189c6dc905b727d60e7043a6655bb
- https://git.kernel.org/stable/c/e41cbf98df22d08402e65174d147cbb187fe1a33
- https://git.kernel.org/stable/c/e929ec98c0c3b10d9c07f3776df0c1a02d7a763e
Modified: 2025-11-07
CVE-2022-49777
In the Linux kernel, the following vulnerability has been resolved: Input: i8042 - fix leaking of platform device on module removal Avoid resetting the module-wide i8042_platform_device pointer in i8042_probe() or i8042_remove(), so that the device can be properly destroyed by i8042_exit() on module unload.
- https://git.kernel.org/stable/c/3f25add5ecf88de0f8ff2b27b6c0731a1f1b38ed
- https://git.kernel.org/stable/c/4f348b60c79671eee33c1389efe89109c93047da
- https://git.kernel.org/stable/c/81cd7e8489278d28794e7b272950c3e00c344e44
- https://git.kernel.org/stable/c/81df118e79b2136b5c016394f67a051dc508b7b6
- https://git.kernel.org/stable/c/a32cd7feb0127bf629a82686b6e2c128139a86e5
- https://git.kernel.org/stable/c/d5f7f6e63fed9c2ed09725d90059a28907e197e3
Modified: 2025-11-07
CVE-2022-49778
In the Linux kernel, the following vulnerability has been resolved: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud The page table check trigger BUG_ON() unexpectedly when collapse hugepage: ------------[ cut here ]------------ kernel BUG at mm/page_table_check.c:82! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 6 PID: 68 Comm: khugepaged Not tainted 6.1.0-rc3+ #750 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_table_check_clear.isra.0+0x258/0x3f0 lr : page_table_check_clear.isra.0+0x240/0x3f0 [...] Call trace: page_table_check_clear.isra.0+0x258/0x3f0 __page_table_check_pmd_clear+0xbc/0x108 pmdp_collapse_flush+0xb0/0x160 collapse_huge_page+0xa08/0x1080 hpage_collapse_scan_pmd+0xf30/0x1590 khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8 khugepaged+0x338/0x518 kthread+0x278/0x2f8 ret_from_fork+0x10/0x20 [...] Since pmd_user_accessible_page() doesn't check if a pmd is leaf, it decrease file_map_count for a non-leaf pmd comes from collapse_huge_page(). and so trigger BUG_ON() unexpectedly. Fix this problem by using pmd_leaf() insteal of pmd_present() in pmd_user_accessible_page(). Moreover, use pud_leaf() for pud_user_accessible_page() too.
Modified: 2025-11-07
CVE-2022-49779
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case
In __unregister_kprobe_top(), if the currently unregistered probe has
post_handler but other child probes of the aggrprobe do not have
post_handler, the post_handler of the aggrprobe is cleared. If this is
a ftrace-based probe, there is a problem. In later calls to
disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is
NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in
__disarm_kprobe_ftrace() and may even cause use-after-free:
Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2)
WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0
Modules linked in: testKprobe_007(-)
CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18
[...]
Call Trace:
- https://git.kernel.org/stable/c/55788ebbe8b365b4375bd56b4ba7db79d393a370
- https://git.kernel.org/stable/c/5dd7caf0bdc5d0bae7cf9776b4d739fb09bd5ebb
- https://git.kernel.org/stable/c/7b0007b28dd970176f2e297c06ae63eea2447127
- https://git.kernel.org/stable/c/7d606ae1abcc3eab5408e42444d789dc7def51b8
- https://git.kernel.org/stable/c/c49cc2c059b503e962c2f13a806c105f9b757df4
Modified: 2025-11-07
CVE-2022-49780
In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus() If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need goto error label in this case.
- https://git.kernel.org/stable/c/28f7ff5e7559d226e63c7c5de74eb075a83d8c53
- https://git.kernel.org/stable/c/41a6b8b527a5957fab41c3c05e25ad125268e2e9
- https://git.kernel.org/stable/c/75205f1b47a88c3fac4f30bd7567e89b2887c7fd
- https://git.kernel.org/stable/c/a636772988bafab89278e7bb3420d8e8eacfe912
- https://git.kernel.org/stable/c/bc68e428d4963af0201e92159629ab96948f0893
- https://git.kernel.org/stable/c/dce0589a3faec9e2e543e97bca7e62592ec85585
Modified: 2025-11-07
CVE-2022-49781
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling
amd_pmu_enable_all() does:
if (!test_bit(idx, cpuc->active_mask))
continue;
amd_pmu_enable_event(cpuc->events[idx]);
A perf NMI of another event can come between these two steps. Perf NMI
handler internally disables and enables _all_ events, including the one
which nmi-intercepted amd_pmu_enable_all() was in process of enabling.
If that unintentionally enabled event has very low sampling period and
causes immediate successive NMI, causing the event to be throttled,
cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop().
This will result in amd_pmu_enable_event() getting called with event=NULL
when amd_pmu_enable_all() resumes after handling the NMIs. This causes a
kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000198
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
[...]
Call Trace:
Modified: 2025-11-07
CVE-2022-49783
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Drop fpregs lock before inheriting FPU permissions
Mike Galbraith reported the following against an old fork of preempt-rt
but the same issue also applies to the current preempt-rt tree.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
fpu_clone
CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased)
Call Trace:
Modified: 2025-11-07
CVE-2022-49784
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/uncore: Fix memory leak for events array When a CPU comes online, the per-CPU NB and LLC uncore contexts are freed but not the events array within the context structure. This causes a memory leak as identified by the kmemleak detector. [...] unreferenced object 0xffff8c5944b8e320 (size 32): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) 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: [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 unreferenced object 0xffff8c5944b8dd40 (size 64): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) 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: [<00000000306efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 [...] Fix the problem by freeing the events array before freeing the uncore context.
Modified: 2025-11-07
CVE-2022-49785
In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Add overflow check in sgx_validate_offset_length() sgx_validate_offset_length() function verifies "offset" and "length" arguments provided by userspace, but was missing an overflow check on their addition. Add it.
Modified: 2025-11-07
CVE-2022-49786
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: properly pin the parent in blkcg_css_online blkcg_css_online is supposed to pin the blkcg of the parent, but 397c9f46ee4d refactored things and along the way, changed it to pin the css instead. This results in extra pins, and we end up leaking blkcgs and cgroups.
Modified: 2025-11-07
CVE-2022-49787
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case.
- https://git.kernel.org/stable/c/222cfa0118aa68687ace74aab8fdf77ce8fbd7e6
- https://git.kernel.org/stable/c/27f712cd47d65e14cd52cc32a23d42aeef583d5d
- https://git.kernel.org/stable/c/35bca18092685b488003509fef7055aa2d4f2ebc
- https://git.kernel.org/stable/c/4423866d31a06a810db22062ed13389416a66b22
- https://git.kernel.org/stable/c/5dbd6378dbf96787d6dbcca44156c511ae085ea3
- https://git.kernel.org/stable/c/7570e5b5419ffd34b6dc45a88c51e113a9a187e3
- https://git.kernel.org/stable/c/a99a547658e5d451f01ed307426286716b6f01bf
Modified: 2025-11-07
CVE-2022-49788
In the Linux kernel, the following vulnerability has been resolved: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem.
- https://git.kernel.org/stable/c/5a275528025ae4bc7e2232866856dfebf84b2fad
- https://git.kernel.org/stable/c/62634b43d3c4e1bf62fd540196f7081bf0885c0a
- https://git.kernel.org/stable/c/76c50d77b928a33e5290aaa9fdc10e88254ff8c7
- https://git.kernel.org/stable/c/7ccf7229b96fadc3a185d1391f814a604c7ef609
- https://git.kernel.org/stable/c/8e2f33c598370bcf828bab4d667d1d38bcd3c57d
- https://git.kernel.org/stable/c/e5b0d06d9b10f5f43101bd6598b076c347f9295f
- https://git.kernel.org/stable/c/e7061dd1fef2dfb6458cd521aef27aa66f510d31
- https://git.kernel.org/stable/c/f04586c2315cfd03d72ad0395705435e7ed07b1a
Modified: 2025-11-07
CVE-2022-49789
In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice). If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice. The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated---
- https://git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff
- https://git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96
- https://git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd
- https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f
- https://git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab
Modified: 2025-11-05
CVE-2022-49790
In the Linux kernel, the following vulnerability has been resolved: Input: iforce - invert valid length check when fetching device IDs syzbot is reporting uninitialized value at iforce_init_device() [1], for commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer when fetching device IDs") is checking that valid length is shorter than bytes to read. Since iforce_get_id_packet() stores valid length when returning 0, the caller needs to check that valid length is longer than or equals to bytes to read.
- https://git.kernel.org/stable/c/24cc679abbf31477d0cc6106ec83c2fbae6b3cdf
- https://git.kernel.org/stable/c/5d53797ce7ce8fb1d95a5bebc5efa9418c4217a3
- https://git.kernel.org/stable/c/6365569d62a75ddf53fb0c2936c16587a365984c
- https://git.kernel.org/stable/c/b8ebf250997c5fb253582f42bfe98673801ebebd
- https://git.kernel.org/stable/c/fdd57c20d4408cac3c3c535c120d244e083406c9
Modified: 2025-11-05
CVE-2022-49791
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix multishot accept request leaks Having REQ_F_POLLED set doesn't guarantee that the request is executed as a multishot from the polling path. Fortunately for us, if the code thinks it's multishot issue when it's not, it can only ask to skip completion so leaking the request. Use issue_flags to mark multipoll issues.
Modified: 2025-11-05
CVE-2022-49792
In the Linux kernel, the following vulnerability has been resolved: iio: adc: mp2629: fix potential array out of bound access Add sentinel at end of maps to avoid potential array out of bound access in iio core.
Modified: 2025-11-06
CVE-2022-49793
In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init() dev_set_name() allocates memory for name, it need be freed when device_add() fails, call put_device() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. Fault injection test can trigger this: unreferenced object 0xffff8e8340a7b4c0 (size 32): comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s) hex dump (first 32 bytes): 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............ backtrace: [<0000000074999de8>] __kmem_cache_alloc_node+0x1e9/0x360 [<00000000497fd30b>] __kmalloc_node_track_caller+0x44/0x1a0 [<000000003636c520>] kstrdup+0x2d/0x60 [<0000000032f84da2>] kobject_set_name_vargs+0x1e/0x90 [<0000000092efe493>] dev_set_name+0x4e/0x70
- https://git.kernel.org/stable/c/0dd52e141afde089304de470148d311b05c14564
- https://git.kernel.org/stable/c/2c4e65285bdea23fd36d2ff376006ac64db6f42e
- https://git.kernel.org/stable/c/5a39382aa5411d64b25a71516c2c7480aab13bb7
- https://git.kernel.org/stable/c/656f670613662b6cc77aad14112db2803ad18fa8
- https://git.kernel.org/stable/c/8dddf2699da296c84205582aaead6b43dd7e8c4b
- https://git.kernel.org/stable/c/b47bb521961f027b4dcf8683337a7a1ba9e5ea1f
- https://git.kernel.org/stable/c/efa17e90e1711bdb084e3954fa44afb6647331c0
- https://git.kernel.org/stable/c/f68c96821b61d2c71a35dbb8bf90c347fad624d9
Modified: 2025-11-06
CVE-2022-49794
In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger() If iio_trigger_register() returns error, it should call iio_trigger_free() to give up the reference that hold in iio_trigger_alloc(), so that it can call iio_trig_release() to free memory when the refcount hit to 0.
- https://git.kernel.org/stable/c/1bf8c0aff8fb5c4edf3ba6728e6bedbd610d7f4b
- https://git.kernel.org/stable/c/2b29a7f2d52fb5281b30cf61c947d88bab18a29b
- https://git.kernel.org/stable/c/65f20301607d07ee279b0804d11a05a62a6c1a1c
- https://git.kernel.org/stable/c/7b75515728b628a9a7540f201efdeb8ca7299385
- https://git.kernel.org/stable/c/85d2a8b287a89853c0dcfc5a97b5e9d36376fe37
- https://git.kernel.org/stable/c/a0d98ae5a62a7bbad8fcf9fa22e0a1274197bbc4
- https://git.kernel.org/stable/c/c27a3b6ba23350708cf5ab9962337447b51eb76d
- https://git.kernel.org/stable/c/c3ce73f60599a483dca7becd4112508833a40ef9
Modified: 2025-11-06
CVE-2022-49795
In the Linux kernel, the following vulnerability has been resolved:
rethook: fix a potential memleak in rethook_alloc()
In rethook_alloc(), the variable rh is not freed or passed out
if handler is NULL, which could lead to a memleak, fix it.
[Masami: Add "rethook:" tag to the title.]
Acke-by: Masami Hiramatsu (Google)
Modified: 2025-11-06
CVE-2022-49796
In the Linux kernel, the following vulnerability has been resolved:
tracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit()
When test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it
will goto delete, which will call kprobe_event_delete() and release the
corresponding resource. However, the trace_array in gen_kretprobe_test
will point to the invalid resource. Set gen_kretprobe_test to NULL
after called kprobe_event_delete() to prevent null-ptr-deref.
BUG: kernel NULL pointer dereference, address: 0000000000000070
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 246 Comm: modprobe Tainted: G W
6.1.0-rc1-00174-g9522dc5c87da-dirty #248
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0
Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c
01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 <44> 8b 65
70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f
RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000
RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064
R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000
FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-06
CVE-2022-49797
In the Linux kernel, the following vulnerability has been resolved:
tracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit()
When trace_get_event_file() failed, gen_kretprobe_test will be assigned
as the error code. If module kprobe_event_gen_test is removed now, the
null pointer dereference will happen in kprobe_event_gen_test_exit().
Check if gen_kprobe_test or gen_kretprobe_test is error code or NULL
before dereference them.
BUG: kernel NULL pointer dereference, address: 0000000000000012
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 3 PID: 2210 Comm: modprobe Not tainted
6.1.0-rc1-00171-g2159299a3b74-dirty #217
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test]
Code: Unable to access opcode bytes at 0xffffffff9ffffff2.
RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246
RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000
RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c
RBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800
R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-07
CVE-2022-49798
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race where eprobes can be called before the event The flag that tells the event to call its triggers after reading the event is set for eprobes after the eprobe is enabled. This leads to a race where the eprobe may be triggered at the beginning of the event where the record information is NULL. The eprobe then dereferences the NULL record causing a NULL kernel pointer bug. Test for a NULL record to keep this from happening.
Modified: 2025-11-07
CVE-2022-49799
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix wild-memory-access in register_synth_event()
In register_synth_event(), if set_synth_event_print_fmt() failed, then
both trace_remove_event_call() and unregister_trace_event() will be
called, which means the trace_event_call will call
__unregister_trace_event() twice. As the result, the second unregister
will causes the wild-memory-access.
register_synth_event
set_synth_event_print_fmt failed
trace_remove_event_call
event_remove
if call->event.funcs then
__unregister_trace_event (first call)
unregister_trace_event
__unregister_trace_event (second call)
Fix the bug by avoiding to call the second __unregister_trace_event() by
checking if the first one is called.
general protection fault, probably for non-canonical address
0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI
KASAN: maybe wild-memory-access in range
[0xdead000000000120-0xdead000000000127]
CPU: 0 PID: 3807 Comm: modprobe Not tainted
6.1.0-rc1-00186-g76f33a7eedb4 #299
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:unregister_trace_event+0x6e/0x280
Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48
b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02
00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b
RSP: 0018:ffff88810413f370 EFLAGS: 00010a06
RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000
RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20
RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481
R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122
R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028
FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-07
CVE-2022-49800
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event() test_gen_synth_cmd() only free buf in fail path, hence buf will leak when there is no failure. Add kfree(buf) to prevent the memleak. The same reason and solution in test_empty_synth_event(). unreferenced object 0xffff8881127de000 (size 2048): comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s) hex dump (first 32 bytes): 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_ backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<0000000039eb1cf5>] 0xffffffffa00083cd [<000000000e8c3bc8>] 0xffffffffa00086ba [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff8881127df000 (size 2048): comm "modprobe", pid 247, jiffies 4294972324 (age 78.728s) hex dump (first 32 bytes): 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<00000000d4db9a3d>] 0xffffffffa0008071 [<00000000c31354a5>] 0xffffffffa00086ce [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Modified: 2025-11-07
CVE-2022-49801
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory leak in tracing_read_pipe() kmemleak reports this issue: unreferenced object 0xffff888105a18900 (size 128): comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150 [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0 [<0000000065629d9d>] trace_event_printf+0xb6/0xf0 [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0 [<00000000d22db172>] print_trace_line+0x73c/0x1480 [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0 [<0000000015b58459>] vfs_read+0x17b/0x7c0 [<000000004aeee8ed>] ksys_read+0xed/0x1c0 [<0000000063d3d898>] do_syscall_64+0x3b/0x90 [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd iter->fmt alloced in tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not freed, to fix, add free in tracing_release_pipe()
Modified: 2025-11-07
CVE-2022-49802
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix null pointer dereference in ftrace_add_mod()
The @ftrace_mod is allocated by kzalloc(), so both the members {prev,next}
of @ftrace_mode->list are NULL, it's not a valid state to call list_del().
If kstrdup() for @ftrace_mod->{func|module} fails, it goes to @out_free
tag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del()
will write prev->next and next->prev, where null pointer dereference
happens.
BUG: kernel NULL pointer dereference, address: 0000000000000008
Oops: 0002 [#1] PREEMPT SMP NOPTI
Call Trace:
- https://git.kernel.org/stable/c/19ba6c8af9382c4c05dc6a0a79af3013b9a35cd0
- https://git.kernel.org/stable/c/1bea037a1abb23a6729bef36a2265a4565f5ea77
- https://git.kernel.org/stable/c/665b4c6648bf2b91f69b33817f4321cf4c3cafe9
- https://git.kernel.org/stable/c/6a14828caddad0d989495a72af678adf60992704
- https://git.kernel.org/stable/c/6e50eb4b1807017f6c2d5089064256ce2de8aef1
- https://git.kernel.org/stable/c/b5bfc61f541d3f092b13dedcfe000d86eb8e133c
- https://git.kernel.org/stable/c/f715f31559b82e3f75ce047fa476de63d8107584
Modified: 2025-11-07
CVE-2022-49803
In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().
Modified: 2025-11-07
CVE-2022-49804
In the Linux kernel, the following vulnerability has been resolved: s390: avoid using global register for current_stack_pointer Commit 30de14b1884b ("s390: current_stack_pointer shouldn't be a function") made current_stack_pointer a global register variable like on many other architectures. Unfortunately on s390 it uncovers old gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87 ("S/390: Fix PR89775. Stackpointer save/restore instructions removed")] and backported to gcc-8.4 and later. Due to this bug gcc versions prior to 8.4 generate broken code which leads to stack corruptions. Current minimal gcc version required to build the kernel is declared as 5.1. It is not possible to fix all old gcc versions, so work around this problem by avoiding using global register variable for current_stack_pointer.
Modified: 2025-11-07
CVE-2022-49805
In the Linux kernel, the following vulnerability has been resolved: net: lan966x: Fix potential null-ptr-deref in lan966x_stats_init() lan966x_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: lan966x_stats_init() create_singlethread_workqueue() # failed, lan966x->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL.
Modified: 2025-11-07
CVE-2022-49806
In the Linux kernel, the following vulnerability has been resolved: net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start() sparx_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. So as sparx5_start().
Modified: 2025-11-07
CVE-2022-49807
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a memory leak in nvmet_auth_set_key When changing dhchap secrets we need to release the old secrets as well. kmemleak complaint: -- unreferenced object 0xffff8c7f44ed8180 (size 64): comm "check", pid 7304, jiffies 4295686133 (age 72034.246s) hex dump (first 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8 backtrace: [<00000000b6fc5071>] kstrdup+0x2e/0x60 [<00000000f0f4633f>] 0xffffffffc0e07ee6 [<0000000053006c05>] 0xffffffffc0dff783 [<00000000419ae922>] configfs_write_iter+0xb1/0x120 [<000000008183c424>] vfs_write+0x2be/0x3c0 [<000000009005a2a5>] ksys_write+0x5f/0xe0 [<00000000cd495c89>] do_syscall_64+0x38/0x90 [<00000000f2a84ac5>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Modified: 2025-11-07
CVE-2022-49808
In the Linux kernel, the following vulnerability has been resolved: net: dsa: don't leak tagger-owned storage on switch driver unbind In the initial commit dc452a471dba ("net: dsa: introduce tagger-owned storage for private and shared data"), we had a call to tag_ops->disconnect(dst) issued from dsa_tree_free(), which is called at tree teardown time. There were problems with connecting to a switch tree as a whole, so this got reworked to connecting to individual switches within the tree. In this process, tag_ops->disconnect(ds) was made to be called only from switch.c (cross-chip notifiers emitted as a result of dynamic tag proto changes), but the normal driver teardown code path wasn't replaced with anything. Solve this problem by adding a function that does the opposite of dsa_switch_setup_tag_protocol(), which is called from the equivalent spot in dsa_switch_teardown(). The positioning here also ensures that we won't have any use-after-free in tagging protocol (*rcv) ops, since the teardown sequence is as follows: dsa_tree_teardown -> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler -> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many() -> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage
Modified: 2025-11-07
CVE-2022-49809
In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix skb leak in x25_lapb_receive_frame() x25_lapb_receive_frame() using skb_copy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak.
- https://git.kernel.org/stable/c/0ef17d966445358a55c5f4ccf2c73cca3e39192b
- https://git.kernel.org/stable/c/2929cceb2fcf0ded7182562e4888afafece82cce
- https://git.kernel.org/stable/c/2d675be16a461310d738d93f9f1a00da62055c5a
- https://git.kernel.org/stable/c/9f00da9c866d506998bf0a3f699ec900730472da
- https://git.kernel.org/stable/c/c8baf1fc248b2e88642f094fea9509a9bf98c5bb
- https://git.kernel.org/stable/c/dfcfbe4f2e4b2c81cff4e79b48502d97fda73118
- https://git.kernel.org/stable/c/e109b41870db995cae25dfaf0cc3922f9028b1a1
- https://git.kernel.org/stable/c/fda0ba7c84b46d10947c687320804b9de149a921
Modified: 2025-11-07
CVE-2022-49810
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing xas_retry() calls in xarray iteration netfslib has a number of places in which it performs iteration of an xarray whilst being under the RCU read lock. It *should* call xas_retry() as the first thing inside of the loop and do "continue" if it returns true in case the xarray walker passed out a special value indicating that the walk needs to be redone from the root[*]. Fix this by adding the missing retry checks. [*] I wonder if this should be done inside xas_find(), xas_next_node() and suchlike, but I'm told that's not an simple change to effect. This can cause an oops like that below. Note the faulting address - this is an internal value (|0x2) returned from xarray. BUG: kernel NULL pointer dereference, address: 0000000000000402 ... RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs] ... Call Trace: netfs_rreq_assess+0xa6/0x240 [netfs] netfs_readpage+0x173/0x3b0 [netfs] ? init_wait_var_entry+0x50/0x50 filemap_read_page+0x33/0xf0 filemap_get_pages+0x2f2/0x3f0 filemap_read+0xaa/0x320 ? do_filp_open+0xb2/0x150 ? rmqueue+0x3be/0xe10 ceph_read_iter+0x1fe/0x680 [ceph] ? new_sync_read+0x115/0x1a0 new_sync_read+0x115/0x1a0 vfs_read+0xf3/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Changes: ======== ver #2) - Changed an unsigned int to a size_t to reduce the likelihood of an overflow as per Willy's suggestion. - Added an additional patch to fix the maths.
Modified: 2025-11-07
CVE-2022-49811
In the Linux kernel, the following vulnerability has been resolved: drbd: use after free in drbd_create_device() The drbd_destroy_connection() frees the "connection" so use the _safe() iterator to prevent a use after free.
- https://git.kernel.org/stable/c/7d93417d596402ddd46bd76c721f205d09d0d025
- https://git.kernel.org/stable/c/813a8dd9c45fd46f5cbbfbedf0791afa7740ccf5
- https://git.kernel.org/stable/c/9ed51414aef6e59e832e2960f10766dce2d5b1a1
- https://git.kernel.org/stable/c/a7a1598189228b5007369a9622ccdf587be0730f
- https://git.kernel.org/stable/c/bf47ca1b35fc1f55091ffaff5fbe41ea0c6f59a1
- https://git.kernel.org/stable/c/c2a00b149836d60c222930bbea6b2139caf34d4f
- https://git.kernel.org/stable/c/fc1897f16ebcfd22364f2afcc27f53a740f3bc7a
Modified: 2025-11-07
CVE-2022-49812
In the Linux kernel, the following vulnerability has been resolved: bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm "ip", pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 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: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Modified: 2025-11-07
CVE-2022-49813
In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix error handling in ena_init() The ena_init() won't destroy workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak.
Modified: 2025-11-07
CVE-2022-49814
In the Linux kernel, the following vulnerability has been resolved: kcm: close race conditions on sk_receive_queue sk->sk_receive_queue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rx_lock to protect more than just skb queue. However, kcm_recvmsg() still only grabs the skb queue lock, so race conditions still exist. We can teach kcm_recvmsg() to grab mux->rx_lock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets. So we have to enforce skb queue lock in requeue_rx_msgs() and handle skb peek case carefully in kcm_wait_data(). Fortunately, skb_recv_datagram() already handles it nicely and is widely used by other sockets, we can just switch to skb_recv_datagram() after getting rid of the unnecessary sock lock in kcm_recvmsg() and kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets, so it is safe to get rid of this check too. I ran the original syzbot reproducer for 30 min without seeing any issue.
- https://git.kernel.org/stable/c/22f6b5d47396b4287662668ee3f5c1f766cb4259
- https://git.kernel.org/stable/c/4154b6afa2bd639214ff259d912faad984f7413a
- https://git.kernel.org/stable/c/5121197ecc5db58c07da95eb1ff82b98b121a221
- https://git.kernel.org/stable/c/bf92e54597d842da127c59833b365d6faeeaf020
- https://git.kernel.org/stable/c/ce57d6474ae999a3b2d442314087473a646a65c7
- https://git.kernel.org/stable/c/d9ad4de92e184b19bcae4da10dac0275abf83931
- https://git.kernel.org/stable/c/f7b0e95071bb4be4b811af3f0bfc3e200eedeaa3
Modified: 2025-11-07
CVE-2022-49815
In the Linux kernel, the following vulnerability has been resolved: erofs: fix missing xas_retry() in fscache mode The xarray iteration only holds the RCU read lock and thus may encounter XA_RETRY_ENTRY if there's process modifying the xarray concurrently. This will cause oops when referring to the invalid entry. Fix this by adding the missing xas_retry(), which will make the iteration wind back to the root node if XA_RETRY_ENTRY is encountered.
Modified: 2025-11-07
CVE-2022-49817
In the Linux kernel, the following vulnerability has been resolved: net: mhi: Fix memory leak in mhi_net_dellink() MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch calls free_netdev() to fix it since netdev_priv is used after unregister.
Modified: 2025-11-10
CVE-2022-49819
In the Linux kernel, the following vulnerability has been resolved: octeon_ep: fix potential memory leak in octep_device_setup() When occur unsupported_dev and mbox init errors, it did not free oct->conf and iounmap() oct->mmio[i].hw_addr. That would trigger memory leak problem. Add kfree() for oct->conf and iounmap() for oct->mmio[i].hw_addr under unsupported_dev and mbox init errors to fix the problem.
Modified: 2025-11-10
CVE-2022-49820
In the Linux kernel, the following vulnerability has been resolved: mctp i2c: don't count unused / invalid keys for flow release We're currently hitting the WARN_ON in mctp_i2c_flow_release: if (midev->release_count > midev->i2c_lock_count) { WARN_ONCE(1, "release count overflow"); This may be hit if we expire a flow before sending the first packet it contains - as we will not be pairing the increment of release_count (performed on flow release) with the i2c lock operation (only performed on actual TX). To fix this, only release a flow if we've encountered it previously (ie, dev_flow_state does not indicate NEW), as we will mark the flow as ACTIVE at the same time as accounting for the i2c lock operation. We also need to add an INVALID flow state, to indicate when we've done the release.
Modified: 2025-11-10
CVE-2022-49821
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_dsp_element_register() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, use put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the kfree() is removed. list_del() is called in mISDN_dsp_dev_release(), so it need be initialized.
- https://git.kernel.org/stable/c/083a2c9ef82e184bdf0b9f9a1e5fc38d32afbb47
- https://git.kernel.org/stable/c/0f2c681900a01e3f23789bca26d88268c3d5b51d
- https://git.kernel.org/stable/c/727ed7d28348c026c7ef4d852f3d0e5054d376e8
- https://git.kernel.org/stable/c/7a05e3929668c8cfef495c69752a9e91fac4878f
- https://git.kernel.org/stable/c/98a2ac1ca8fd6eca6867726fe238d06e75eb1acd
- https://git.kernel.org/stable/c/b119bedbefb7dd9ed8bf8cb9f1056504250d610e
- https://git.kernel.org/stable/c/bbd53d05c4c892080ef3b617eff4f57903acecb9
- https://git.kernel.org/stable/c/d4b8394725079670be309f9a35ad88a8cbbaaefd
Modified: 2025-11-10
CVE-2022-49822
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix connections leak when tlink setup failed If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit. Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST) Let's check the result of tlink setup, and do some cleanup.
Modified: 2025-11-10
CVE-2022-49823
In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tdev_add() In ata_tdev_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #36 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x3a0 lr : device_del+0x44/0x3a0 Call trace: device_del+0x48/0x3a0 attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tdev_delete+0x24/0x50 [libata] ata_tlink_delete+0x40/0xa0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tdev_add(). In the error path, device_del() is called to delete the device which was added earlier in this function, and ata_tdev_free() is called to free ata_dev.
Modified: 2025-11-10
CVE-2022-49824
In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tlink_add() In ata_tlink_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #12 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tlink_delete+0x88/0xb0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tlink_add().
Modified: 2025-11-10
CVE-2022-49825
In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tport_add() In ata_tport_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tport_delete+0x34/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tport_add().
Modified: 2025-11-10
CVE-2022-49826
In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix double ata_host_put() in ata_tport_add() In the error path in ata_tport_add(), when calling put_device(), ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null. When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Fix this by removing redundant ata_host_put() in the error path.
- https://git.kernel.org/stable/c/30e12e2be27ac6c4be2af4163c70db381364706f
- https://git.kernel.org/stable/c/377ff82c33c0cb74562a353361b64b33c09562cf
- https://git.kernel.org/stable/c/865a6da40ba092c18292ae5f6194756131293745
- https://git.kernel.org/stable/c/8c76310740807ade5ecdab5888f70ecb6d35732e
- https://git.kernel.org/stable/c/ac471468f7c16cda2525909946ca13ddbcd14000
- https://git.kernel.org/stable/c/bec9ded5404cb14e5f5470103d0973a2ff83d6a5
Modified: 2025-11-10
CVE-2022-49827
In the Linux kernel, the following vulnerability has been resolved:
drm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()
drm_vblank_init() call drmm_add_action_or_reset() with
drm_vblank_init_release() as action. If __drmm_add_action() failed, will
directly call drm_vblank_init_release() with the vblank whose worker is
NULL. As the resule, a null-ptr-deref will happen in
kthread_destroy_worker(). Add the NULL check before calling
drm_vblank_destroy_worker().
BUG: null-ptr-deref
KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
CPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty
RIP: 0010:kthread_destroy_worker+0x25/0xb0
Call Trace:
Modified: 2025-11-10
CVE-2022-49828
In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: don't delete error page from pagecache This change is very similar to the change that was made for shmem [1], and it solves the same problem but for HugeTLBFS instead. Currently, when poison is found in a HugeTLB page, the page is removed from the page cache. That means that attempting to map or read that hugepage in the future will result in a new hugepage being allocated instead of notifying the user that the page was poisoned. As [1] states, this is effectively memory corruption. The fix is to leave the page in the page cache. If the user attempts to use a poisoned HugeTLB page with a syscall, the syscall will fail with EIO, the same error code that shmem uses. For attempts to map the page, the thread will get a BUS_MCEERR_AR SIGBUS. [1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Modified: 2025-11-10
CVE-2022-49829
In the Linux kernel, the following vulnerability has been resolved: drm/scheduler: fix fence ref counting We leaked dependency fences when processes were beeing killed. Additional to that grab a reference to the last scheduled fence.
Modified: 2025-11-10
CVE-2022-49830
In the Linux kernel, the following vulnerability has been resolved: drm/drv: Fix potential memory leak in drm_dev_init() drm_dev_init() will add drm_dev_init_release() as a callback. When drmm_add_action() failed, the release function won't be added. As the result, the ref cnt added by device_get() in drm_dev_init() won't be put by drm_dev_init_release(), which leads to the memleak. Use drmm_add_action_or_reset() instead of drmm_add_action() to prevent memleak. unreferenced object 0xffff88810bc0c800 (size 2048): comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s) hex dump (first 32 bytes): e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<............. backtrace: [<000000007251f72d>] __kmalloc+0x4b/0x1c0 [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0 [<000000004452a479>] platform_device_register_full+0x24/0x1c0 [<0000000089f4ea61>] 0xffffffffa0736051 [<00000000235b2441>] do_one_initcall+0x7a/0x380 [<0000000001a4a177>] do_init_module+0x5c/0x230 [<000000002bf8a8e2>] load_module+0x227d/0x2420 [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140 [<00000000c99fc324>] do_syscall_64+0x3f/0x90 [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Modified: 2025-11-10
CVE-2022-49831
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: initialize device's zone info for seeding When performing seeding on a zoned filesystem it is necessary to initialize each zoned device's btrfs_zoned_device_info structure, otherwise mounting the filesystem will cause a NULL pointer dereference. This was uncovered by fstests' testcase btrfs/163.
Modified: 2025-11-10
CVE-2022-49832
In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map Here is the BUG report by KASAN about null pointer dereference: BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50 Read of size 1 at addr 0000000000000000 by task python3/2640 Call Trace: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() would return NULL pointer when kmalloc() fail to allocate. So directly return ENOMEM, if kasprintf() return NULL pointer.
- https://git.kernel.org/stable/c/040f726fecd88121f3b95e70369785ad452dddf9
- https://git.kernel.org/stable/c/5834a3a98cd266ad35a229923c0adbd0addc8d68
- https://git.kernel.org/stable/c/777430aa4ddccaa5accec6db90ffc1d47f00d471
- https://git.kernel.org/stable/c/91d5c5060ee24fe8da88cd585bb43b843d2f0dce
- https://git.kernel.org/stable/c/97e5b508e96176f1a73888ed89df396d7041bfcb
- https://git.kernel.org/stable/c/a988dcd3dd9e691c5ccc3324b209688f3b5453e9
- https://git.kernel.org/stable/c/aaf552c5d53abe4659176e099575fe870d2e4768
- https://git.kernel.org/stable/c/b4d9f55cd38435358bc16d580612bc0d798d7b4c
Modified: 2025-11-10
CVE-2022-49833
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: clone zoned device info when cloning a device When cloning a btrfs_device, we're not cloning the associated btrfs_zoned_device_info structure of the device in case of a zoned filesystem. Later on this leads to a NULL pointer dereference when accessing the device's zone_info for instance when setting a zone as active. This was uncovered by fstests' testcase btrfs/161.
Modified: 2025-11-10
CVE-2022-49834
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free bug of ns_writer on remount If a nilfs2 filesystem is downgraded to read-only due to metadata corruption on disk and is remounted read/write, or if emergency read-only remount is performed, detaching a log writer and synchronizing the filesystem can be done at the same time. In these cases, use-after-free of the log writer (hereinafter nilfs->ns_writer) can happen as shown in the scenario below: Task1 Task2 -------------------------------- ------------------------------ nilfs_construct_segment nilfs_segctor_sync init_wait init_waitqueue_entry add_wait_queue schedule nilfs_remount (R/W remount case) nilfs_attach_log_writer nilfs_detach_log_writer nilfs_segctor_destroy kfree finish_wait _raw_spin_lock_irqsave __raw_spin_lock_irqsave do_raw_spin_lock debug_spin_lock_before <-- use-after-free While Task1 is sleeping, nilfs->ns_writer is freed by Task2. After Task1 waked up, Task1 accesses nilfs->ns_writer which is already freed. This scenario diagram is based on the Shigeru Yoshida's post [1]. This patch fixes the issue by not detaching nilfs->ns_writer on remount so that this UAF race doesn't happen. Along with this change, this patch also inserts a few necessary read-only checks with superblock instance where only the ns_writer pointer was used to check if the filesystem is read-only.
- https://git.kernel.org/stable/c/39a3ed68270b079c6b874d4e4727a512b9b4882c
- https://git.kernel.org/stable/c/4feedde5486c07ea79787839153a71ca71329c7d
- https://git.kernel.org/stable/c/8cccf05fe857a18ee26e20d11a8455a73ffd4efd
- https://git.kernel.org/stable/c/9b162e81045266a2d5b44df9dffdf05c54de9cca
- https://git.kernel.org/stable/c/afbd1188382a75f6cfe22c0b68533f7f9664f182
- https://git.kernel.org/stable/c/b152300d5a1ba4258dacf9916bff20e6a8c7603b
- https://git.kernel.org/stable/c/b2fbf10040216ef5ee270773755fc2f5da65b749
- https://git.kernel.org/stable/c/b4736ab5542112fe0a40f140a0a0b072954f34da
Modified: 2025-11-10
CVE-2022-49835
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix potential memleak in 'add_widget_node' As 'kobject_add' may allocated memory for 'kobject->name' when return error. And in this function, if call 'kobject_add' failed didn't free kobject. So call 'kobject_put' to recycling resources.
- https://git.kernel.org/stable/c/02dea987ec1cac712c78e75d224ceb9bb73519ed
- https://git.kernel.org/stable/c/3a79f9568de08657fcdbc41d6fc4c0ca145a7a2b
- https://git.kernel.org/stable/c/455d99bd6baf19688048b6d42d9fa74eae27f93b
- https://git.kernel.org/stable/c/7140d7aaf93da6a665b454f91bb4dc6b1de218bd
- https://git.kernel.org/stable/c/90b7d055e2b5f39429f9a9e3815b48a48530ef28
- https://git.kernel.org/stable/c/9a5523f72bd2b0d66eef3d58810c6eb7b5ffc143
- https://git.kernel.org/stable/c/b688a3ec235222d9a84e43a48a6f31acb95baf2d
- https://git.kernel.org/stable/c/bb0ac8d5e541224f599bc8e8f31a313faa4bf7b7
Modified: 2025-11-10
CVE-2022-49836
In the Linux kernel, the following vulnerability has been resolved: siox: fix possible memory leak in siox_device_add() If device_register() returns error in siox_device_add(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(), and sdevice is freed in siox_device_release(), set it to null in error path.
- https://git.kernel.org/stable/c/0a5da069603ecc3d7aa09167450235462adaa295
- https://git.kernel.org/stable/c/5d03c2911c529ea4d6ebfec53425f1091e8d402b
- https://git.kernel.org/stable/c/6e63153db50059fb78b8a8447b132664887d24e3
- https://git.kernel.org/stable/c/a4b5423f88a17a36550ae8c16c46779b1ee42f4b
- https://git.kernel.org/stable/c/d9c31e728843259209fb530c59995e4fe262699f
- https://git.kernel.org/stable/c/f9fe7ba4ea5b24ffdf8e125f660aca3ba4a147fb
Modified: 2025-10-01
CVE-2022-49837
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memory leaks in __check_func_call kmemleak reports this issue: unreferenced object 0xffff88817139d000 (size 2048): comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 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: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The root case here is: In function prepare_func_exit(), the callee is not released in the abnormal scenario after "state->curframe--;". To fix, move "state->curframe--;" to the very bottom of the function, right when we free callee and reset frame[] pointer to NULL, as Andrii suggested. In addition, function __check_func_call() has a similar problem. In the abnormal scenario before "state->curframe++;", the callee also should be released by free_func_state().
Modified: 2025-11-10
CVE-2022-49838
In the Linux kernel, the following vulnerability has been resolved: sctp: clear out_curr if all frag chunks of current msg are pruned A crash was reported by Zhen Chen: list_del corruption, ffffa035ddf01c18->next is NULL WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Call Trace: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream out_curr outq while this outq was empty. Normally stream->out_curr must be set to NULL once all frag chunks of current msg are dequeued, as we can see in sctp_sched_dequeue_done(). However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue, sctp_sched_dequeue_done() is not called to do this. This patch is to fix it by simply setting out_curr to NULL when the last frag chunk of current msg is dequeued from out_curr stream in sctp_prsctp_prune_unsent().
Modified: 2025-10-01
CVE-2022-49839
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_transport_sas: Fix error handling in sas_phy_add() If transport_add_device() fails in sas_phy_add(), the kernel will crash trying to delete the device in transport_remove_device() called from sas_remove_host(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add().
Modified: 2025-10-01
CVE-2022-49840
In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() We got a syzkaller problem because of aarch64 alignment fault if KFENCE enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size + @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a cache line.
- https://git.kernel.org/stable/c/047824a730699c6c66df43306b80f700c9dfc2fd
- https://git.kernel.org/stable/c/1b597f2d6a55e9f549989913860ad5170da04964
- https://git.kernel.org/stable/c/730fb1ef974a13915bc7651364d8b3318891cd70
- https://git.kernel.org/stable/c/7a704dbfd3735304e261f2787c52fbc7c3884736
- https://git.kernel.org/stable/c/d3fd203f36d46aa29600a72d57a1b61af80e4a25
- https://git.kernel.org/stable/c/e60f37a1d379c821c17b08f366412dce9ef3d99f
- https://git.kernel.org/stable/c/eaa8edd86514afac9deb9bf9a5053e74f37edf40
Modified: 2025-11-10
CVE-2022-49841
In the Linux kernel, the following vulnerability has been resolved: serial: imx: Add missing .thaw_noirq hook The following warning is seen with non-console UART instance when system hibernates. [ 37.371969] ------------[ cut here ]------------ [ 37.376599] uart3_root_clk already disabled [ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 ... [ 37.506986] Call trace: [ 37.509432] clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platform_pm_thaw+0x30/0x6c [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4 [ 37.528972] device_resume+0x7c/0x160 [ 37.532633] dpm_resume+0xe8/0x230 [ 37.536036] hibernation_snapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] state_store+0xc4/0xd0 [ 37.547203] kobj_attr_store+0x1c/0x30 [ 37.550953] sysfs_kf_write+0x48/0x60 [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac [ 37.559063] new_sync_write+0xe8/0x184 [ 37.562812] vfs_write+0x230/0x290 [ 37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0 [ 37.578156] do_el0_svc+0x11c/0x150 [ 37.581648] el0_svc+0x30/0x140 [ 37.584792] el0t_64_sync_handler+0xe8/0xf0 [ 37.588976] el0t_64_sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ]--- On hibernating, pm core calls into related hooks in sequence like: .freeze .freeze_noirq .thaw_noirq .thaw With .thaw_noirq hook being absent, the clock will be disabled in a unbalanced call which results the warning above. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Adding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have the call sequence corrected as below and thus fix the warning. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_resume_noirq() clk_enable() imx_uart_thaw clk_disable_unprepare()
- https://git.kernel.org/stable/c/0a3160f4ffc70ee4bfa1521f698dace06e6091fd
- https://git.kernel.org/stable/c/4561d8008a467cb05ac632a215391d6b787f40aa
- https://git.kernel.org/stable/c/476b09e07bd519ec7ba5941a6a6f9a02256dbb21
- https://git.kernel.org/stable/c/ae22294e213a402a70fa1731538367d1b758ffe7
- https://git.kernel.org/stable/c/e3f9d87d6f0732827c443bd1474df21c2fad704b
- https://git.kernel.org/stable/c/e401312ca6e180ee1bd65f6a766e99dd40aa95e7
Modified: 2025-10-01
CVE-2022-49842
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Fix use-after-free in snd_soc_exit()
KASAN reports a use-after-free:
BUG: KASAN: use-after-free in device_del+0xb5b/0xc60
Read of size 8 at addr ffff888008655050 by task rmmod/387
CPU: 2 PID: 387 Comm: rmmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
- https://git.kernel.org/stable/c/2ec3f558db343b045a7c7419cdbaec266b8ac1a7
- https://git.kernel.org/stable/c/34eee4189bcebbd5f6a2ff25ef0cb893ad33d51e
- https://git.kernel.org/stable/c/41fad4f712e081acdfde8b59847f9f66eaf407a0
- https://git.kernel.org/stable/c/6ec27c53886c8963729885bcf2dd996eba2767a7
- https://git.kernel.org/stable/c/8d21554ec7680e9585fb852d933203c3db60dad1
- https://git.kernel.org/stable/c/90bbdf30a51e42378cb23a312005a022794b8e1e
- https://git.kernel.org/stable/c/a3365e62239dc064019a244bde5686ac18527c22
- https://git.kernel.org/stable/c/c5674bd073c0fd9f620ca550c5ff08d0d429bdd9
Modified: 2025-10-01
CVE-2022-49844
In the Linux kernel, the following vulnerability has been resolved: can: dev: fix skb drop check In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only mode") the priv->ctrlmode element is read even on virtual CAN interfaces that do not create the struct can_priv at startup. This out-of-bounds read may lead to CAN frame drops for virtual CAN interfaces like vcan and vxcan. This patch mainly reverts the original commit and adds a new helper for CAN interface drivers that provide the required information in struct can_priv. [mkl: patch pch_can, too]
Modified: 2025-10-01
CVE-2022-49845
In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_send_one(): fix missing CAN header initialization The read access to struct canxl_frame::len inside of a j1939 created skbuff revealed a missing initialization of reserved and later filled elements in struct can_frame. This patch initializes the 8 byte CAN header with zero.
- https://git.kernel.org/stable/c/2719f82ad5d8199cf5f346ea8bb3998ad5323b72
- https://git.kernel.org/stable/c/3eb3d283e8579a22b81dd2ac3987b77465b2a22f
- https://git.kernel.org/stable/c/69e86c6268d59ceddd0abe9ae8f1f5296f316c3c
- https://git.kernel.org/stable/c/d0513b095e1ef1469718564dec3fb3348556d0a8
- https://git.kernel.org/stable/c/f8e0edeaa0f2b860bdbbf0aafb4492533043d650
Modified: 2025-10-01
CVE-2022-49846
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix a slab-out-of-bounds write bug in udf_find_entry()
Syzbot reported a slab-out-of-bounds Write bug:
loop0: detected capacity change from 0 to 2048
==================================================================
BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0
fs/udf/namei.c:253
Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610
CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/11/2022
Call Trace:
- https://git.kernel.org/stable/c/03f9582a6a2ebd25a440896475c968428c4b63e7
- https://git.kernel.org/stable/c/583fdd98d94acba1e7225e5cc29063aef0741030
- https://git.kernel.org/stable/c/7a6051d734f1ed0031e2216f9a538621235c11a4
- https://git.kernel.org/stable/c/ac79001b8e603226fab17240a79cb9ef679d3cd9
- https://git.kernel.org/stable/c/c736ed8541605e3a25075bb1cbf8f38cb3083238
- https://git.kernel.org/stable/c/c8af247de385ce49afabc3bf1cf4fd455c94bfe8
- https://git.kernel.org/stable/c/d8971f410739a864c537e0ac29344a7b6c450232
- https://git.kernel.org/stable/c/f1517721c408631f09d54c743aa70cb07fd3eebd
Modified: 2025-11-10
CVE-2022-49847
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: Fix segmentation fault at module unload Move am65_cpsw_nuss_phylink_cleanup() call to after am65_cpsw_nuss_cleanup_ndev() so phylink is still valid to prevent the below Segmentation fault on module remove when first slave link is up. [ 31.652944] Unable to handle kernel paging request at virtual address 00040008000005f4 [ 31.684627] Mem abort info: [ 31.687446] ESR = 0x0000000096000004 [ 31.704614] EC = 0x25: DABT (current EL), IL = 32 bits [ 31.720663] SET = 0, FnV = 0 [ 31.723729] EA = 0, S1PTW = 0 [ 31.740617] FSC = 0x04: level 0 translation fault [ 31.756624] Data abort info: [ 31.759508] ISV = 0, ISS = 0x00000004 [ 31.776705] CM = 0, WnR = 0 [ 31.779695] [00040008000005f4] address between user and kernel address ranges [ 31.808644] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 31.814928] Modules linked in: wlcore_sdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce phy_gmii_sel ti_am65_cpsw_nuss(-) sch_fq_codel ipv6 [ 31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160 [ 31.837547] Hardware name: Texas Instruments AM625 (DT) [ 31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.849709] pc : phy_stop+0x18/0xf8 [ 31.853202] lr : phylink_stop+0x38/0xf8 [ 31.857031] sp : ffff80000a0839f0 [ 31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000 [ 31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98 [ 31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90 [ 31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000 [ 31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106 [ 31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000 [ 31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0 [ 31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0 [ 31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920 [ 31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200 [ 31.931603] Call trace: [ 31.934042] phy_stop+0x18/0xf8 [ 31.937177] phylink_stop+0x38/0xf8 [ 31.940657] am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss] [ 31.947452] __dev_close_many+0xa4/0x140 [ 31.951371] dev_close_many+0x84/0x128 [ 31.955115] unregister_netdevice_many+0x130/0x6d0 [ 31.959897] unregister_netdevice_queue+0x94/0xd8 [ 31.964591] unregister_netdev+0x24/0x38 [ 31.968504] am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss] [ 31.975637] am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss]
Modified: 2025-10-01
CVE-2022-49848
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp-combo: fix NULL-deref on runtime resume Commit fc64623637da ("phy: qcom-qmp-combo,usb: add support for separate PCS_USB region") started treating the PCS_USB registers as potentially separate from the PCS registers but used the wrong base when no PCS_USB offset has been provided. Fix the PCS_USB base used at runtime resume to prevent dereferencing a NULL pointer on platforms that do not provide a PCS_USB offset (e.g. SC7180).
Modified: 2025-11-10
CVE-2022-49849
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix match incorrectly in dev_args_match_device syzkaller found a failed assertion: assertion failed: (args->devid != (u64)-1) || args->missing, in fs/btrfs/volumes.c:6921 This can be triggered when we set devid to (u64)-1 by ioctl. In this case, the match of devid will be skipped and the match of device may succeed incorrectly. Patch 562d7b1512f7 introduced this function which is used to match device. This function contains two matching scenarios, we can distinguish them by checking the value of args->missing rather than check whether args->devid and args->uuid is default value.
Modified: 2025-10-01
CVE-2022-49850
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix deadlock in nilfs_count_free_blocks() A semaphore deadlock can occur if nilfs_get_block() detects metadata corruption while locating data blocks and a superblock writeback occurs at the same time: task 1 task 2 ------ ------ * A file operation * nilfs_truncate() nilfs_get_block() down_read(rwsem A) <-- nilfs_bmap_lookup_contig() ... generic_shutdown_super() nilfs_put_super() * Prepare to write superblock * down_write(rwsem B) <-- nilfs_cleanup_super() * Detect b-tree corruption * nilfs_set_log_cursor() nilfs_bmap_convert_error() nilfs_count_free_blocks() __nilfs_error() down_read(rwsem A) <-- nilfs_set_error() down_write(rwsem B) <-- *** DEADLOCK *** Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem) and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata corruption, __nilfs_error() is called from nilfs_bmap_convert_error() inside the lock section. Since __nilfs_error() calls nilfs_set_error() unless the filesystem is read-only and nilfs_set_error() attempts to writelock rwsem B (= nilfs->ns_sem) to write back superblock exclusively, hierarchical lock acquisition occurs in the order rwsem A -> rwsem B. Now, if another task starts updating the superblock, it may writelock rwsem B during the lock sequence above, and can deadlock trying to readlock rwsem A in nilfs_count_free_blocks(). However, there is actually no need to take rwsem A in nilfs_count_free_blocks() because it, within the lock section, only reads a single integer data on a shared struct with nilfs_sufile_get_ncleansegs(). This has been the case after commit aa474a220180 ("nilfs2: add local variable to cache the number of clean segments"), that is, even before this bug was introduced. So, this resolves the deadlock problem by just not taking the semaphore in nilfs_count_free_blocks().
- https://git.kernel.org/stable/c/1d4ff73062096c21b47954d2996b4df259777bda
- https://git.kernel.org/stable/c/36ff974b0310771417c0be64b64aa221bd70d63d
- https://git.kernel.org/stable/c/3c89ca6d3dfa6c09c515807a7a97a521f5d5147e
- https://git.kernel.org/stable/c/8ac932a4921a96ca52f61935dbba64ea87bbd5dc
- https://git.kernel.org/stable/c/8b4506cff6630bb474bb46a2a75c31e533a756ba
- https://git.kernel.org/stable/c/abc082aac0d9b6b926038fc3adb7008306581be2
- https://git.kernel.org/stable/c/cb029b54953420f7a2d65100f1c5107f14411bdc
- https://git.kernel.org/stable/c/f0cc93080d4c09510b74ecba87fd778cca390bb1
Modified: 2025-11-10
CVE-2022-49851
In the Linux kernel, the following vulnerability has been resolved:
riscv: fix reserved memory setup
Currently, RISC-V sets up reserved memory using the "early" copy of the
device tree. As a result, when trying to get a reserved memory region
using of_reserved_mem_lookup(), the pointer to reserved memory regions
is using the early, pre-virtual-memory address which causes a kernel
panic when trying to use the buffer's name:
Unable to handle kernel paging request at virtual address 00000000401c31ac
Oops [#1]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1
Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
epc : string+0x4a/0xea
ra : vsnprintf+0x1e4/0x336
epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0
gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000
t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20
s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000
a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff
a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff
s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008
s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00
s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002
s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617
t5 : ffffffff812f3618 t6 : ffffffff81203d08
status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d
[
Modified: 2026-01-23
CVE-2022-49852
In the Linux kernel, the following vulnerability has been resolved: riscv: process: fix kernel info leakage thread_struct's s[12] may contain random kernel memory content, which may be finally leaked to userspace. This is a security hole. Fix it by clearing the s[12] array in thread_struct when fork. As for kthread case, it's better to clear the s[12] array as well.
- https://git.kernel.org/stable/c/358a68f98304b40b201ba5afe94c20355aa3dc68
- https://git.kernel.org/stable/c/6510c78490c490a6636e48b61eeaa6fb65981f4b
- https://git.kernel.org/stable/c/c4601d30f7d989b4f354df899ab85b5f7a750d30
- https://git.kernel.org/stable/c/c5c0b3167537793a7cf936fb240366eefd2fc7fb
- https://git.kernel.org/stable/c/cc36c7fa5d9384602529ba3eea8c5daee7be4dbc
- https://git.kernel.org/stable/c/e56d18a976dda653194218df6d40d8122c775712
Modified: 2025-10-01
CVE-2022-49853
In the Linux kernel, the following vulnerability has been resolved:
net: macvlan: fix memory leaks of macvlan_common_newlink
kmemleak reports memory leaks in macvlan_common_newlink, as follows:
ip link add link eth0 name .. type macvlan mode source macaddr add
- https://git.kernel.org/stable/c/21d3a8b6a1e39e7529ce9de07316ee13a63f305b
- https://git.kernel.org/stable/c/23569b5652ee8e8e55a12f7835f59af6f3cefc30
- https://git.kernel.org/stable/c/685e73e3f7a9fb75cbf049a9d0b7c45cc6b57b2e
- https://git.kernel.org/stable/c/956e0216a19994443c90ba2ea6b0b284c9c4f9cb
- https://git.kernel.org/stable/c/9ea003c4671b2fc455320ecf6d4a43b0a3c1878a
- https://git.kernel.org/stable/c/9f288e338be206713d79b29144c27fca4503c39b
- https://git.kernel.org/stable/c/a81b44d1df1f07f00c0dcc0a0b3d2fa24a46289e
- https://git.kernel.org/stable/c/a8d67367ab33604326cc37ab44fd1801bf5691ba
Modified: 2025-10-01
CVE-2022-49854
In the Linux kernel, the following vulnerability has been resolved: mctp: Fix an error handling path in mctp_init() If mctp_neigh_init() return error, the routes resources should be released in the error handling path. Otherwise some resources leak.
Modified: 2025-10-01
CVE-2022-49855
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg ipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to obtain the wwan power state configuration from BIOS but is not freeing the acpi_object. The acpi_evaluate_dsm() returned acpi_object to be freed. Free the acpi_object after use.
Modified: 2025-10-01
CVE-2022-49857
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init() When prestera_sdma_switch_init() failed, the memory pointed to by sw->rxtx isn't released. Fix it. Only be compiled, not be tested.
Modified: 2025-11-10
CVE-2022-49858
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed.
Modified: 2025-11-10
CVE-2022-49859
In the Linux kernel, the following vulnerability has been resolved:
net: lapbether: fix issue of invalid opcode in lapbeth_open()
If lapb_register() failed when lapb device goes to up for the first time,
the NAPI is not disabled. As a result, the invalid opcode issue is
reported when the lapb device goes to up for the second time.
The stack info is as follows:
[ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442!
[ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0
[ 1958.332310][T11356] Call Trace:
[ 1958.332817][T11356]
Modified: 2025-10-01
CVE-2022-49860
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-glue: fix memory leak when register device fail If device_register() fails, it should call put_device() to give up reference, the name allocated in dev_set_name() can be freed in callback function kobject_cleanup().
Modified: 2025-10-01
CVE-2022-49861
In the Linux kernel, the following vulnerability has been resolved: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in the remove function. Add the missing call.
- https://git.kernel.org/stable/c/04f2cc56d80a1ac058045a7835c5bfd910f17863
- https://git.kernel.org/stable/c/081195d17a0c4c636da2b869bd5809d42e8cbb13
- https://git.kernel.org/stable/c/0b7ee3d50f32d277bf024b4ddb4de54da43a3025
- https://git.kernel.org/stable/c/1d84887327659c58a6637060ac8c50c3a952a163
- https://git.kernel.org/stable/c/20479886b40c0ed4864a5fc8490a1f6b70cccf1b
- https://git.kernel.org/stable/c/4b6641c3a2ba95ddcfecec263b4a5e572a4b0641
- https://git.kernel.org/stable/c/992e966caf57e00855edbd79f19d911809732a69
- https://git.kernel.org/stable/c/a1cb72e20a64a3c83f9b4ee993fbf97e4c1d7714
Modified: 2025-10-01
CVE-2022-49862
In the Linux kernel, the following vulnerability has been resolved: tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value in tipc_nl_compat_name_table_dump") where it should have type casted sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative value. syzbot reported a call trace because of it: BUG: KMSAN: uninit-value in ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline]
- https://git.kernel.org/stable/c/082707d3df191bf5bb8801d43e4ce3dea39ca173
- https://git.kernel.org/stable/c/1c075b192fe41030457cd4a5f7dea730412bca40
- https://git.kernel.org/stable/c/301caa06091af4d5cf056ac8249cbda4e6029c6a
- https://git.kernel.org/stable/c/36769b9477491a7af6635863bd950309c1e1b96c
- https://git.kernel.org/stable/c/55a253a6753a603e80b95932ca971ba514aa6ce7
- https://git.kernel.org/stable/c/6cee2c60bd168279852ac7dbe54c2b70d1028644
- https://git.kernel.org/stable/c/a0ead1d648df9c456baec832b494513ef405949a
- https://git.kernel.org/stable/c/f31dd158580940938f77514b87337a777520185a
Modified: 2025-10-01
CVE-2022-49863
In the Linux kernel, the following vulnerability has been resolved:
can: af_can: fix NULL pointer dereference in can_rx_register()
It causes NULL pointer dereference when testing as following:
(a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.
(b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan
link device, and bind vxcan device to bond device (can also use
ifenslave command to bind vxcan device to bond device).
(c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.
(d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.
The bond device invokes the can-raw protocol registration interface to
receive CAN packets. However, ml_priv is not allocated to the dev,
dev_rcv_lists is assigned to NULL in can_rx_register(). In this case,
it will occur the NULL pointer dereference issue.
The following is the stack information:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
RIP: 0010:can_rx_register+0x12d/0x1e0
Call Trace:
- https://git.kernel.org/stable/c/261178a1c2623077d62e374a75c195e6c99a6f05
- https://git.kernel.org/stable/c/8aa59e355949442c408408c2d836e561794c40a1
- https://git.kernel.org/stable/c/a8055677b054bc2bb78beb1080fdc2dc5158c2fe
- https://git.kernel.org/stable/c/afab4655750fcb3fca359bc7d7214e3d634cdf9c
- https://git.kernel.org/stable/c/d68fa77ee3d03bad6fe84e89759ddf7005f9e9c6
Modified: 2025-10-01
CVE-2022-49864
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram() ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced.
Modified: 2026-01-23
CVE-2022-49865
In the Linux kernel, the following vulnerability has been resolved: ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network When copying a `struct ifaddrlblmsg` to the network, __ifal_reserved remained uninitialized, resulting in a 1-byte infoleak: BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841 __netdev_start_xmit ./include/linux/netdevice.h:4841 netdev_start_xmit ./include/linux/netdevice.h:4857 xmit_one net/core/dev.c:3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606 __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256 dev_queue_xmit ./include/linux/netdevice.h:3009 __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1263 netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272 netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360 nlmsg_unicast ./include/net/netlink.h:1061 rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 ... Uninit was created at: slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742 slab_alloc_node mm/slub.c:3398 __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437 __do_kmalloc_node mm/slab_common.c:954 __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975 kmalloc_reserve net/core/skbuff.c:437 __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509 alloc_skb ./include/linux/skbuff.h:1267 nlmsg_new ./include/net/netlink.h:964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345 netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921 ... This patch ensures that the reserved field is always initialized.
- https://git.kernel.org/stable/c/0f85b7ae7c4b5d7b4bbf7ac653a733c181a8a2bf
- https://git.kernel.org/stable/c/2acb2779b147decd300c117683d5a32ce61c75d6
- https://git.kernel.org/stable/c/49e92ba5ecd7d72ba369dde2ccff738edd028a47
- https://git.kernel.org/stable/c/568a47ff756f913e8b374c2af9d22cd2c772c744
- https://git.kernel.org/stable/c/58cd7fdc8c1e6c7873acc08f190069fed88d1c12
- https://git.kernel.org/stable/c/6d26d0587abccb9835382a0b53faa7b9b1cd83e3
- https://git.kernel.org/stable/c/a033b86c7f7621fde31f0364af8986f43b44914f
- https://git.kernel.org/stable/c/c23fb2c82267638f9d206cb96bb93e1f93ad7828
Modified: 2025-10-01
CVE-2022-49866
In the Linux kernel, the following vulnerability has been resolved: net: wwan: mhi: fix memory leak in mhi_mbim_dellink MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch sets needs_free_netdev to true when registers network device, which makes netdev subsystem call free_netdev() automatically after unregister_netdevice().
Modified: 2025-10-01
CVE-2022-49867
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_wwan_dellink IOSM driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch sets needs_free_netdev to true when registers network device, which makes netdev subsystem call free_netdev() automatically after unregister_netdevice().
Modified: 2025-11-10
CVE-2022-49868
In the Linux kernel, the following vulnerability has been resolved: phy: ralink: mt7621-pci: add sentinel to quirks table With mt7621 soc_dev_attr fixed to register the soc as a device, kernel will experience an oops in soc_device_match_attr This quirk test was introduced in the staging driver in commit 9445ccb3714c ("staging: mt7621-pci-phy: add quirks for 'E2' revision using 'soc_device_attribute'"). The staging driver was removed, and later re-added in commit d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY") for kernel 5.11
Modified: 2025-10-01
CVE-2022-49869
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible crash in bnxt_hwrm_set_coal() During the error recovery sequence, the rtnl_lock is not held for the entire duration and some datastructures may be freed during the sequence. Check for the BNXT_STATE_OPEN flag instead of netif_running() to ensure that the device is fully operational before proceeding to reconfigure the coalescing settings. This will fix a possible crash like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G IOE --------- - - 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019 RIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en] Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6 RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5 RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28 RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0 FS: 00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ethnl_set_coalesce+0x3ce/0x4c0 genl_family_rcv_msg_doit.isra.15+0x10f/0x150 genl_family_rcv_msg+0xb3/0x160 ? coalesce_fill_reply+0x480/0x480 genl_rcv_msg+0x47/0x90 ? genl_family_rcv_msg+0x160/0x160 netlink_rcv_skb+0x4c/0x120 genl_rcv+0x24/0x40 netlink_unicast+0x196/0x230 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 __sys_sendto+0xee/0x160 ? syscall_trace_enter+0x1d3/0x2c0 ? __audit_syscall_exit+0x249/0x2a0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f38524163bb
- https://git.kernel.org/stable/c/38147073c96dce8c7e142ce0e5f305a420a729ba
- https://git.kernel.org/stable/c/6d81ea3765dfa6c8a20822613c81edad1c4a16a0
- https://git.kernel.org/stable/c/7781e32984cde65549bedc3201537e253297c98d
- https://git.kernel.org/stable/c/a5a05fbef4a0dfe45fe03b2f1d02ba23aebf5384
- https://git.kernel.org/stable/c/ac257c43fa615d22180916074feed803b8bb8cb0
Modified: 2025-11-10
CVE-2022-49870
In the Linux kernel, the following vulnerability has been resolved:
capabilities: fix undefined behavior in bit shift for CAP_TO_MASK
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/151dc8087b5609e53b069c068e3f3ee100efa586
- https://git.kernel.org/stable/c/27bdb134c043ff32c459d98f16550d0ffa0b3c34
- https://git.kernel.org/stable/c/46653972e3ea64f79e7f8ae3aa41a4d3fdb70a13
- https://git.kernel.org/stable/c/5661f111a1616ac105ec8cec81bff99b60f847ac
- https://git.kernel.org/stable/c/5b79fa628e2ab789e629a83cd211ef9b4c1a593e
- https://git.kernel.org/stable/c/65b0bc7a0690861812ade523d19f82688ab819dc
- https://git.kernel.org/stable/c/dbaab08c8677d598244d21afb7818e44e1c5d826
- https://git.kernel.org/stable/c/fcbd2b336834bd24e1d9454ad5737856470c10d7
Modified: 2025-10-01
CVE-2022-49871
In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix memory leaks of napi_get_frags kmemleak reports after running test_progs: unreferenced object 0xffff8881b1672dc0 (size 232): comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] __napi_build_skb+0x15/0x50 [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540 [<000000003ecfa30e>] napi_get_frags+0x59/0x140 [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun] [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320 [<000000008f338ea2>] do_iter_write+0x135/0x630 [<000000008a3377a4>] vfs_writev+0x12e/0x440 [<00000000a6b5639a>] do_writev+0x104/0x280 [<00000000ccf065d8>] do_syscall_64+0x3b/0x90 [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: tun_get_user() napi_gro_frags() napi_frags_finish() case GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- While napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() is not called, napi->rx_list is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tun_napi_del() ... tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list is not empty, which caused memory leaks To fix, add napi_complete() after napi_gro_frags().
- https://git.kernel.org/stable/c/1118b2049d77ca0b505775fc1a8d1909cf19a7ec
- https://git.kernel.org/stable/c/223ef6a94e52331a6a7ef31e59921e0e82d2d40a
- https://git.kernel.org/stable/c/3401f964028ac941425b9b2c8ff8a022539ef44a
- https://git.kernel.org/stable/c/8b12a020b20a78f62bedc50f26db3bf4fadf8cb9
- https://git.kernel.org/stable/c/a4f73f6adc53fd7a3f9771cbc89a03ef39b0b755
- https://git.kernel.org/stable/c/d7569302a7a52a9305d2fb054df908ff985553bb
Modified: 2025-11-10
CVE-2022-49872
In the Linux kernel, the following vulnerability has been resolved: net: gso: fix panic on frag_list with mixed head alloc types Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list"), it is allowed to change gso_size of a GRO packet. However, that commit assumes that "checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too". It turns out this assumption does not hold. We've seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced. There are three different locations where this can be fixed: (1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem. (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list. (3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down. This patch implements (3). To limit the performance impact in skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set that have gso_size changed. Normal paths thus will not hit it. We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side.
- https://git.kernel.org/stable/c/0a9f56e525ea871d3950b90076912f5c7494f00f
- https://git.kernel.org/stable/c/50868de7dc4e7f0fcadd6029f32bf4387c102ee6
- https://git.kernel.org/stable/c/5876b7f249a1ecbbcc8e35072c3828d6526d1c3a
- https://git.kernel.org/stable/c/598d9e30927b15731e83797fbd700ecf399f42dd
- https://git.kernel.org/stable/c/65ad047fd83502447269fda8fd26c99077a9af47
- https://git.kernel.org/stable/c/9e4b7a99a03aefd37ba7bb1f022c8efab5019165
- https://git.kernel.org/stable/c/ad25a115f50800c6847e0d841c5c7992a9f7c1b3
- https://git.kernel.org/stable/c/bd5362e58721e4d0d1a37796593bd6e51536ce7a
Modified: 2025-10-01
CVE-2022-49873
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix wrong reg type conversion in release_reference() Some helper functions will allocate memory. To avoid memory leaks, the verifier requires the eBPF program to release these memories by calling the corresponding helper functions. When a resource is released, all pointer registers corresponding to the resource should be invalidated. The verifier use release_references() to do this job, by apply __mark_reg_unknown() to each relevant register. It will give these registers the type of SCALAR_VALUE. A register that will contain a pointer value at runtime, but of type SCALAR_VALUE, which may allow the unprivileged user to get a kernel pointer by storing this register into a map. Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this problem.
Modified: 2025-10-01
CVE-2022-49874
In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: fix possible memory leak in mousevsc_probe() If hid_add_device() returns error, it should call hid_destroy_device() to free hid_dev which is allocated in hid_allocate_device().
- https://git.kernel.org/stable/c/249b743801c00542e9324f87b380032e957a43e8
- https://git.kernel.org/stable/c/5ad95d71344b7ffec360d62591633b3c465dc049
- https://git.kernel.org/stable/c/5f3aba6566b866f5b0a4916f0b2e8a6ae66a6451
- https://git.kernel.org/stable/c/8597b59e3d22b27849bd3e4f92a3d466774bfb04
- https://git.kernel.org/stable/c/a6d2fb1874c52ace1f5cf1966ee558829c5c19b6
- https://git.kernel.org/stable/c/b5bcb94b0954a026bbd671741fdb00e7141f9c91
- https://git.kernel.org/stable/c/e29289d0d8193fca6d2c1f0a1de75cfc80edec00
- https://git.kernel.org/stable/c/ed75d1a1c31a0cae8ecc8bcea710b25c0be68da0
Modified: 2025-10-01
CVE-2022-49875
In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE When using bpftool to pin {PROG, MAP, LINK} without FILE, segmentation fault will occur. The reson is that the lack of FILE will cause strlen to trigger NULL pointer dereference. The corresponding stacktrace is shown below: do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereference Fix it by adding validation to the common process.
Modified: 2025-10-01
CVE-2022-49876
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit()
When device is running and the interface status is changed, the gpf issue
is triggered. The problem triggering process is as follows:
Thread A: Thread B
ieee80211_runtime_change_iftype() process_one_work()
... ...
ieee80211_do_stop() ...
... ...
sdata->bss = NULL ...
... ieee80211_subif_start_xmit()
ieee80211_multicast_to_unicast
//!sdata->bss->multicast_to_unicast
cause gpf issue
When the interface status is changed, the sending queue continues to send
packets. After the bss is set to NULL, the bss is accessed. As a result,
this causes a general-protection-fault issue.
The following is the stack information:
general protection fault, probably for non-canonical address
0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000178-0x000000000000017f]
Workqueue: mld mld_ifc_work
RIP: 0010:ieee80211_subif_start_xmit+0x25b/0x1310
Call Trace:
Modified: 2025-11-10
CVE-2022-49877
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues
When running `test_sockmap` selftests, the following warning appears:
WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0
Call Trace:
- https://git.kernel.org/stable/c/14e8bc3bf7bd6af64d7538a0684c8238d96cdfd7
- https://git.kernel.org/stable/c/8ec95b94716a1e4d126edc3fb2bc426a717e2dba
- https://git.kernel.org/stable/c/95adbd2ac8de82e43fd6b347e7e1b47f74dc1abb
- https://git.kernel.org/stable/c/cc21dc48a78cc9e5af9a4d039cd456446a6e73ff
- https://git.kernel.org/stable/c/d975bec1eaeb52341acc9273db79ddb078220399
Modified: 2025-10-01
CVE-2022-49878
In the Linux kernel, the following vulnerability has been resolved: bpf, verifier: Fix memory leak in array reallocation for stack state If an error (NULL) is returned by krealloc(), callers of realloc_array() were setting their allocation pointers to NULL, but on error krealloc() does not touch the original allocation. This would result in a memory resource leak. Instead, free the old allocation on the error handling path. The memory leak information is as follows as also reported by Zhengchao: unreferenced object 0xffff888019801800 (size 256): comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s) 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: [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] realloc_array+0x82/0xe2 [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186 [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d [<000000002973c690>] bpf_prog_load+0x13db/0x2240 [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0 [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0 [<0000000056fedaf5>] do_syscall_64+0x35/0x80 [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Modified: 2025-11-10
CVE-2022-49879
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix BUG_ON() when directory entry has invalid rec_len
The rec_len field in the directory entry has to be a multiple of 4. A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().
------------[ cut here ]------------
kernel BUG at fs/ext4/ext4.h:2413!
...
RIP: 0010:make_indexed_dir+0x53f/0x5f0
...
Call Trace:
- https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad
- https://git.kernel.org/stable/c/17a0bc9bd697f75cfdf9b378d5eb2d7409c91340
- https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909
- https://git.kernel.org/stable/c/999cff2b6ce3b45c08abf793bf55534777421327
- https://git.kernel.org/stable/c/ce1ee2c8827fb6493e91acbd50f664cf2a972c3d
Modified: 2025-10-01
CVE-2022-49880
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883
- https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb
- https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b
- https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e
- https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97
- https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20
- https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6
- https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63
Modified: 2025-10-01
CVE-2022-49881
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix memory leak in query_regdb_file() In the function query_regdb_file() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdb_fw_cb(). However, request_firmware_nowait() can fail without calling regdb_fw_cb() and thus leak memory.
- https://git.kernel.org/stable/c/0ede1a988299e95d54bd89551fd635980572e920
- https://git.kernel.org/stable/c/219446396786330937bcd382a7bc4ccd767383bc
- https://git.kernel.org/stable/c/38c9fa2cc6bf4b6e1a74057aef8b5cffd23d3264
- https://git.kernel.org/stable/c/57b962e627ec0ae53d4d16d7bd1033e27e67677a
- https://git.kernel.org/stable/c/e1e12180321f416d83444f2cdc9259e0f5093d35
- https://git.kernel.org/stable/c/e9b5a4566d5bc71cc901be50d1fa24da00613120
Modified: 2025-11-10
CVE-2022-49882
In the Linux kernel, the following vulnerability has been resolved: KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive. Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmu_notifier invalidation due to the cache not being on the list of gfns to invalidate. Note, "active" needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmu_notifier events. If a relevant mmu_notifier event occurs while the cache is "active" but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmu_notifier event with active users and/or kvm_gpc_refresh(). A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND can be exploited to trigger the bug. 1. Deactivate shinfo cache: kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = false gpc->khva = NULL gpc->active = false Result: active = false, valid = false 2. Cause cache refresh: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check return -EWOULDBLOCK because !gpc->valid kvm_xen_set_evtchn_fast return -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = true gpc->khva = not NULL Result: active = false, valid = true 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast read_lock gpc->lock kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO mutex_lock kvm->lock kvm_xen_shared_info_init kvm_gpc_activate gpc->khva = NULL kvm_gpc_check [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pending_bits = shinfo->evtchn_pending CRASH: test_and_set_bit(..., pending_bits)
Modified: 2025-11-10
CVE-2022-49883
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format On 64 bit host, if the guest doesn't have X86_FEATURE_LM, KVM will access 16 gprs to 32-bit smram image, causing out-ouf-bound ram access. On 32 bit host, the rsm_load_state_64/enter_smm_save_state_64 is compiled out, thus access overflow can't happen.
Modified: 2025-11-10
CVE-2022-49884
In the Linux kernel, the following vulnerability has been resolved: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper Move the gfn_to_pfn_cache lock initialization to another helper and call the new helper during VM/vCPU creation. There are race conditions possible due to kvm_gfn_to_pfn_cache_init()'s ability to re-initialize the cache's locks. For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock. (thread 1) | (thread 2) | kvm_xen_set_evtchn_fast | read_lock_irqsave(&gpc->lock, ...) | | kvm_gfn_to_pfn_cache_init | rwlock_init(&gpc->lock) read_unlock_irqrestore(&gpc->lock, ...) | Rename "cache_init" and "cache_destroy" to activate+deactivate to avoid implying that the cache really is destroyed/freed. Note, there more races in the newly named kvm_gpc_activate() that will be addressed separately. [sean: call out that this is a bug fix]
Modified: 2025-10-01
CVE-2022-49885
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.
The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
The following call trace is observed because of this bug:
[ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[ 9.317131] Call Trace:
[ 9.317134]
Modified: 2025-11-10
CVE-2022-49886
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Panic on bad configs that #VE on "private" memory access All normal kernel memory is "TDX private memory". This includes everything from kernel stacks to kernel text. Handling exceptions on arbitrary accesses to kernel memory is essentially impossible because they can happen in horribly nasty places like kernel entry/exit. But, TDX hardware can theoretically _deliver_ a virtualization exception (#VE) on any access to private memory. But, it's not as bad as it sounds. TDX can be configured to never deliver these exceptions on private memory with a "TD attribute" called ATTR_SEPT_VE_DISABLE. The guest has no way to *set* this attribute, but it can check it. Ensure ATTR_SEPT_VE_DISABLE is set in early boot. panic() if it is unset. There is no sane way for Linux to run with this attribute clear so a panic() is appropriate. There's small window during boot before the check where kernel has an early #VE handler. But the handler is only for port I/O and will also panic() as soon as it sees any other #VE, such as a one generated by a private memory access. [ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo(). Add Kirill's tested-by because I made changes since he wrote this. ]
Modified: 2025-10-01
CVE-2022-49887
In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix possible refcount leak in vdec_probe() v4l2_device_unregister need to be called to put the refcount got by v4l2_device_register when vdec_probe fails or vdec_remove is called.
- https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef
- https://git.kernel.org/stable/c/70119756311a0be3b95bec2e1ba714673e90feba
- https://git.kernel.org/stable/c/7718999356234d9cc6a11b4641bb773928f1390f
- https://git.kernel.org/stable/c/be6e22f54623d8a856a4f167b25be73c2ff1ff80
- https://git.kernel.org/stable/c/f96ad391d054bd5c36994f98afd6a12cbb5600bf
Modified: 2025-05-07
CVE-2022-49888
In the Linux kernel, the following vulnerability has been resolved: arm64: entry: avoid kprobe recursion The cortex_a76_erratum_1463225_debug_handler() function is called when handling debug exceptions (and synchronous exceptions from BRK instructions), and so is called when a probed function executes. If the compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it can be probed. If cortex_a76_erratum_1463225_debug_handler() is probed, any debug exception or software breakpoint exception will result in recursive exceptions leading to a stack overflow. This can be triggered with the ftrace multiple_probes selftest, and as per the example splat below. This is a regression caused by commit: 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround") ... which removed the NOKPROBE_SYMBOL() annotation associated with the function. My intent was that cortex_a76_erratum_1463225_debug_handler() would be inlined into its caller, el1_dbg(), which is marked noinstr and cannot be probed. Mark cortex_a76_erratum_1463225_debug_handler() as __always_inline to ensure this. Example splat prior to this patch (with recursive entries elided): | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64_enter_el1_dbg+0x4/0x20 | lr : el1_dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xe4/0x104 | show_stack+0x18/0x4c | dump_stack_lvl+0x64/0x7c | dump_stack+0x18/0x38 | panic+0x14c/0x338 | test_taint+0x0/0x2c | panic_bad_stack+0x104/0x118 | handle_bad_stack+0x34/0x48 | __bad_stack+0x78/0x7c | arm64_enter_el1_dbg+0x4/0x20 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | do_el0_svc+0x0/0x28 | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]--- With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined into el1_dbg(), and el1_dbg() cannot be probed: | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | sh: write error: No such file or directory | # grep -w cortex_a76_errat ---truncated---
Modified: 2025-10-01
CVE-2022-49890
In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks]
- https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603
- https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1
- https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85
- https://git.kernel.org/stable/c/7480aeff0093d8c54377553ec6b31110bea37b4d
- https://git.kernel.org/stable/c/8cf0a1bc12870d148ae830a4ba88cfdf0e879cee
- https://git.kernel.org/stable/c/90577bcc01c4188416a47269f8433f70502abe98
- https://git.kernel.org/stable/c/cdf01c807e974048c43c7fd3ca574f6086a57906
Modified: 2025-10-01
CVE-2022-49891
In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd() test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd(). unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Modified: 2025-05-07
CVE-2022-49892
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]
Modified: 2025-11-10
CVE-2022-49893
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix cxl_region leak, cleanup targets at region delete When a region is deleted any targets that have been previously assigned to that region hold references to it. Trigger those references to drop by detaching all targets at unregister_region() time. Otherwise that region object will leak as userspace has lost the ability to detach targets once region sysfs is torn down.
Modified: 2025-10-01
CVE-2022-49894
In the Linux kernel, the following vulnerability has been resolved:
cxl/region: Fix region HPA ordering validation
Some regions may not have any address space allocated. Skip them when
validating HPA order otherwise a crash like the following may result:
devm_cxl_add_region: cxl_acpi cxl_acpi.0: decoder3.4: created region9
BUG: kernel NULL pointer dereference, address: 0000000000000000
[..]
RIP: 0010:store_targetN+0x655/0x1740 [cxl_core]
[..]
Call Trace:
Modified: 2025-10-01
CVE-2022-49895
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix decoder allocation crash When an intermediate port's decoders have been exhausted by existing regions, and creating a new region with the port in question in it's hierarchical path is attempted, cxl_port_attach_region() fails to find a port decoder (as would be expected), and drops into the failure / cleanup path. However, during cleanup of the region reference, a sanity check attempts to dereference the decoder, which in the above case didn't exist. This causes a NULL pointer dereference BUG. To fix this, refactor the decoder allocation and de-allocation into helper routines, and in this 'free' routine, check that the decoder, @cxld, is valid before attempting any operations on it.
Modified: 2025-10-01
CVE-2022-49896
In the Linux kernel, the following vulnerability has been resolved: cxl/pmem: Fix cxl_pmem_region and cxl_memdev leak When a cxl_nvdimm object goes through a ->remove() event (device physically removed, nvdimm-bridge disabled, or nvdimm device disabled), then any associated regions must also be disabled. As highlighted by the cxl-create-region.sh test [1], a single device may host multiple regions, but the driver was only tracking one region at a time. This leads to a situation where only the last enabled region per nvdimm device is cleaned up properly. Other regions are leaked, and this also causes cxl_memdev reference leaks. Fix the tracking by allowing cxl_nvdimm objects to track multiple region associations.
Modified: 2025-11-10
CVE-2022-49898
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix tree mod log mishandling of reallocated nodes We have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40 Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); This occurs because we replay the nodes in order that they happened, and when we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot, starting at 0. 'n' here is the number of items in this block, which in this case was 1, but we had 2 REMOVE_WHILE_FREEING operations. The actual root cause of this was that we were replaying operations for a block that shouldn't have been replayed. Consider the following sequence of events 1. We have an already modified root, and we do a btrfs_get_tree_mod_seq(). 2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots. 3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node. 4. We modify a new root, and re-allocate the above node to the root node of this other root. The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8 >From here the bug is triggered by the following steps 1. Call btrfs_get_old_root() on the new_root. 2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0. 3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE. 4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e ---truncated---
Modified: 2025-10-01
CVE-2022-49899
In the Linux kernel, the following vulnerability has been resolved: fscrypt: stop using keyrings subsystem for fscrypt_master_key The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support.
Modified: 2025-11-10
CVE-2022-49900
In the Linux kernel, the following vulnerability has been resolved:
i2c: piix4: Fix adapter not be removed in piix4_remove()
In piix4_probe(), the piix4 adapter will be registered in:
piix4_probe()
piix4_add_adapters_sb800() / piix4_add_adapter()
i2c_add_adapter()
Based on the probed device type, piix4_add_adapters_sb800() or single
piix4_add_adapter() will be called.
For the former case, piix4_adapter_count is set as the number of adapters,
while for antoher case it is not set and kept default *zero*.
When piix4 is removed, piix4_remove() removes the adapters added in
piix4_probe(), basing on the piix4_adapter_count value.
Because the count is zero for the single adapter case, the adapter won't
be removed and makes the sources allocated for adapter leaked, such as
the i2c client and device.
These sources can still be accessed by i2c or bus and cause problems.
An easily reproduced case is that if a new adapter is registered, i2c
will get the leaked adapter and try to call smbus_algorithm, which was
already freed:
Triggered by: rmmod i2c_piix4 && modprobe max31730
BUG: unable to handle page fault for address: ffffffffc053d860
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 3752 Comm: modprobe Tainted: G
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core
RSP: 0018:ffff888107477710 EFLAGS: 00000246
...
Modified: 2025-10-01
CVE-2022-49901
In the Linux kernel, the following vulnerability has been resolved: blk-mq: Fix kmemleak in blk_mq_init_allocated_queue There is a kmemleak caused by modprobe null_blk.ko unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 That is because q->ma_ops is set to NULL before blk_release_queue is called. blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q); [1]: blk_mq_alloc_and_init_hctx failed at i != 0. [2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and will be cleaned up in blk_mq_release. [3]: q->nr_hw_queues is 0. [4]: Set q->mq_ops to NULL. [5]: queue_is_mq returns false due to [4]. And blk_mq_release will not be called. The hctxs in q->unused_hctx_list are leaked. To fix it, call blk_release_queue in exception path.
Modified: 2025-10-01
CVE-2022-49902
In the Linux kernel, the following vulnerability has been resolved: block: Fix possible memory leak for rq_wb on add_disk failure kmemleak reported memory leaks in device_add_disk(): kmemleak: 3 new suspected memory leaks unreferenced object 0xffff88800f420800 (size 512): comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s) hex dump (first 32 bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d3662699>] kmalloc_trace+0x26/0x60 [<00000000edc7aadc>] wbt_init+0x50/0x6f0 [<0000000069601d16>] wbt_enable_default+0x157/0x1c0 [<0000000028fc393f>] blk_register_queue+0x2a4/0x420 [<000000007345a042>] device_add_disk+0x6fd/0xe40 [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd] ... It is because the memory allocated in wbt_enable_default() is not released in device_add_disk() error path. Normally, these memory are freed in: del_gendisk() rq_qos_exit() rqos->ops->exit(rqos); wbt_exit() So rq_qos_exit() is called to free the rq_wb memory for wbt_init(). However in the error path of device_add_disk(), only blk_unregister_queue() is called and make rq_wb memory leaked. Add rq_qos_exit() to the error path to fix it.
Modified: 2025-11-11
CVE-2022-49903
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix WARNING in ip6_route_net_exit_late()
During the initialization of ip6_route_net_init_late(), if file
ipv6_route or rt6_stats fails to be created, the initialization is
successful by default. Therefore, the ipv6_route or rt6_stats file
doesn't be found during the remove in ip6_route_net_exit_late(). It
will cause WRNING.
The following is the stack information:
name 'rt6_stats'
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/080589287127838046077904f34d5054ea0f895c
- https://git.kernel.org/stable/c/0ed71af4d017d2bd2cbb8f7254f613a4914def26
- https://git.kernel.org/stable/c/381453770f731f0f43616a1cd4c759b7807a1517
- https://git.kernel.org/stable/c/5dbb47ee89762da433cd8458788d7640c85f1a07
- https://git.kernel.org/stable/c/768b3c745fe5789f2430bdab02f35a9ad1148d97
- https://git.kernel.org/stable/c/83fbf246ced54dadd7b9adc2a16efeff30ba944d
Modified: 2025-10-01
CVE-2022-49904
In the Linux kernel, the following vulnerability has been resolved:
net, neigh: Fix null-ptr-deref in neigh_table_clear()
When IPv6 module gets initialized but hits an error in the middle,
kenel panic with:
KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
CPU: 1 PID: 361 Comm: insmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
RSP: 0018:ffff888012677908 EFLAGS: 00000202
...
Call Trace:
- https://git.kernel.org/stable/c/0d38b4ca6679e72860ff8730e79bb99d0e9fa3b0
- https://git.kernel.org/stable/c/1c89642e7f2b7ecc9635610653f5c2f0276c0051
- https://git.kernel.org/stable/c/2b45d6d0c41cb9593868e476681efb1aae5078a1
- https://git.kernel.org/stable/c/a99a8ec4c62180c889482a2ff6465033e0743458
- https://git.kernel.org/stable/c/b49f6b2f21f543d4dc88fb7b1ec2adccb822f27c
- https://git.kernel.org/stable/c/b736592de2aa53aee2d48d6b129bc0c892007bbe
- https://git.kernel.org/stable/c/f8017317cb0b279b8ab98b0f3901a2e0ac880dad
Modified: 2025-11-11
CVE-2022-49905
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible leaked pernet namespace in smc_init()
In smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called
without any error handling.
If it fails, registering of &smc_net_ops won't be reverted.
And if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted.
This leaves wild ops in subsystem linkedlist and when another module
tries to call register_pernet_operations() it triggers page fault:
BUG: unable to handle page fault for address: fffffbfff81b964c
RIP: 0010:register_pernet_operations+0x1b9/0x5f0
Call Trace:
Modified: 2025-10-01
CVE-2022-49906
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Free rwi on reset success Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed.
Modified: 2025-11-11
CVE-2022-49907
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/20ed01a7b9af6e6a3c33761eebbb710ea6dd49b7
- https://git.kernel.org/stable/c/40e4eb324c59e11fcb927aa46742d28aba6ecb8a
- https://git.kernel.org/stable/c/4954b5359eb141499492fadfab891e28905509e2
- https://git.kernel.org/stable/c/634f066d02bdb22a26da7deb0c7617ab1a65fc9d
- https://git.kernel.org/stable/c/6ce6f8f8f6316da6f92afe7490bc2f0b654d68e0
- https://git.kernel.org/stable/c/7006176a3c863e3e353ce1b8a349ef5bb1b9320e
- https://git.kernel.org/stable/c/985a88bf0b27193522bba7856b1763f428cef19d
- https://git.kernel.org/stable/c/a3fafc974be37319679f36dc4e7cca7db1e02973
Modified: 2025-10-01
CVE-2022-49908
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix memory leak in vhci_write
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810d81ac00 (size 240):
[...]
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:
[
Modified: 2025-11-11
CVE-2022-49910
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
- https://git.kernel.org/stable/c/03af22e23b96fb7ef75fb7885407ef457e8b403d
- https://git.kernel.org/stable/c/3aff8aaca4e36dc8b17eaa011684881a80238966
- https://git.kernel.org/stable/c/4cd094fd5d872862ca278e15b9b51b07e915ef3f
- https://git.kernel.org/stable/c/6c7407bfbeafc80a04e6eaedcf34d378532a04f2
- https://git.kernel.org/stable/c/8278a87bb1eeea94350d675ef961ee5a03341fde
- https://git.kernel.org/stable/c/9a04161244603f502c6e453913e51edd59cb70c1
- https://git.kernel.org/stable/c/cb1c012099ef5904cd468bdb8d6fcdfdd9bcb569
- https://git.kernel.org/stable/c/dc30e05bb18852303084430c03ca76e69257d9ea
Modified: 2025-11-11
CVE-2022-49911
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: enforce documented limit to prevent allocating huge memory
Daniel Xu reported that the hash:net,iface type of the ipset subsystem does
not limit adding the same network with different interfaces to a set, which
can lead to huge memory usage or allocation failure.
The quick reproducer is
$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0
$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done
The backtrace when vmalloc fails:
[Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages
<...>
[Tue Oct 25 00:13:08 2022] Call Trace:
[Tue Oct 25 00:13:08 2022]
Modified: 2025-11-12
CVE-2022-49912
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ulist leaks in error paths of qgroup self tests In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests, if we fail to add the tree ref, remove the extent item or remove the extent ref, we are returning from the test function without freeing the "old_roots" ulist that was allocated by the previous calls to btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
- https://git.kernel.org/stable/c/0a0dead4ad1a2e2a9bdf133ef45111d7c8daef84
- https://git.kernel.org/stable/c/203204798831c35d855ecc6417d98267d2d2184b
- https://git.kernel.org/stable/c/3f58283d83a588ff5da62fc150de19e798ed2ec2
- https://git.kernel.org/stable/c/5d1a47ebf84540e40b5b43fc21aef0d6c0f627d9
- https://git.kernel.org/stable/c/d37de92b38932d40e4a251e876cc388f9aee5f42
- https://git.kernel.org/stable/c/d81370396025cf63a7a1b5f8bb25a3479203b2ca
- https://git.kernel.org/stable/c/da7003434bcab0ae9aba3f2c003e734cae093326
- https://git.kernel.org/stable/c/f46ea5fa3320dca4fe0c0926b49a5f14cb85de62
Modified: 2025-11-12
CVE-2022-49913
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at find_parent_nodes() During backref walking, at find_parent_nodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolve_indirect_refs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to the refs ulist passed as argument to find_parent_nodes(). Since they were not yet added to the refs ulist and prelim_release() does not free the lists, on error the caller can only free the lists attached to the refs that were added to the refs ulist, all the remaining refs get their inode lists never freed, therefore leaking their memory. Fix this by having prelim_release() always free any attached inode list to each ref found in the rbtree, and have find_parent_nodes() set the ref's inode list to NULL once it transfers ownership of the inode list to a ref added to the refs ulist passed to find_parent_nodes().
- https://git.kernel.org/stable/c/222a3d533027b9492d5b7f5ecdc01a90f57bb5a9
- https://git.kernel.org/stable/c/61e06128113711df0534c404fb6bb528eb7d2332
- https://git.kernel.org/stable/c/6a6731a0df8c47ecc703bd7bb73459df767051e0
- https://git.kernel.org/stable/c/83ea8c5b54d452a5769e605e3c5c687e8ca06d89
- https://git.kernel.org/stable/c/92876eec382a0f19f33d09d2c939e9ca49038ae5
Modified: 2025-11-12
CVE-2022-49914
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the unodes. Fix this by calling free_leaf_list() instead of ulist_free() when we exit from resolve_indirect_refs(). The static function free_leaf_list() is moved up for this to be possible and it's slightly simplified by removing unnecessary code.
- https://git.kernel.org/stable/c/2c0329406bb28109c07c6e23e5e3e0fa618a95d7
- https://git.kernel.org/stable/c/396515db923ad5cbeb179d6b88927870b4cbebb7
- https://git.kernel.org/stable/c/5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1
- https://git.kernel.org/stable/c/6ba3479f9e96b9ad460c7e77abc26dd16e5dec4f
- https://git.kernel.org/stable/c/a52e24c7fcc3c5ce3588a14e3663c00868d36623
- https://git.kernel.org/stable/c/b1dc9019bb5f89abae85645de1a2dd4830c1f8e9
- https://git.kernel.org/stable/c/cded2c89774b99b67c98147ae103ea878c92a206
Modified: 2025-10-01
CVE-2022-49915
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release().
- https://git.kernel.org/stable/c/029d5b7688a2f3a86f2a3be5a6ba9cc968c80e41
- https://git.kernel.org/stable/c/080aabfb29b2ee9cbb8894a1d039651943d3773e
- https://git.kernel.org/stable/c/0d4e91efcaee081e919b3c50e875ecbb84290e41
- https://git.kernel.org/stable/c/2ff6b669523d3b3d253a044fa9636a67d0694995
- https://git.kernel.org/stable/c/a636fc5a7cabd05699b5692ad838c2c7a3abec7b
- https://git.kernel.org/stable/c/d1d1aede313eb2b9a84afd60ff6cfb7c33631e0e
- https://git.kernel.org/stable/c/e77d213843e67b4373285712699b692f9c743f61
- https://git.kernel.org/stable/c/e7d1d4d9ac0dfa40be4c2c8abd0731659869b297
Modified: 2025-10-01
CVE-2022-49916
In the Linux kernel, the following vulnerability has been resolved:
rose: Fix NULL pointer dereference in rose_send_frame()
The syzkaller reported an issue:
KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: rcu_gp srcu_invoke_callbacks
RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
Call Trace:
- https://git.kernel.org/stable/c/01b9c68c121847d05a4ccef68244dadf82bfa331
- https://git.kernel.org/stable/c/3e2129c67daca21043a26575108f6286c85e71f6
- https://git.kernel.org/stable/c/5b46adfbee1e429f33b10a88d6c00fa88f3d6c77
- https://git.kernel.org/stable/c/a601e5eded33bb88b8a42743db8fef3ad41dd97e
- https://git.kernel.org/stable/c/b13be5e852b03f376058027e462fad4230240891
- https://git.kernel.org/stable/c/bbc03d74e641e824754443b908454ca9e203773e
- https://git.kernel.org/stable/c/e97c089d7a49f67027395ddf70bf327eeac2611e
- https://git.kernel.org/stable/c/f06186e5271b980bac03f5c97276ed0146ddc9b0
Modified: 2025-11-12
CVE-2022-49917
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in ip_vs_app_net_cleanup()
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/06d7596d18725f1a93cf817662d36050e5afb989
- https://git.kernel.org/stable/c/2c8d81bdb2684d53d6cedad7410ba4cf9090e343
- https://git.kernel.org/stable/c/5663ed63adb9619c98ab7479aa4606fa9b7a548c
- https://git.kernel.org/stable/c/8457a00c981fe1a799ce34123908856b0f5973b8
- https://git.kernel.org/stable/c/97f872b00937f2689bff2dab4ad9ed259482840f
- https://git.kernel.org/stable/c/adc76740ccd52e4a1d910767cd1223e134a7078b
Modified: 2025-11-12
CVE-2022-49918
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in __ip_vs_cleanup_batch()
During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
or ip_vs_conn_sync fails to be created, the initialization is successful
by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
be found during the remove.
The following is the stack information:
name 'ip_vs_conn_sync'
WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/3d00c6a0da8ddcf75213e004765e4a42acc71d5d
- https://git.kernel.org/stable/c/5ee2d6b726b0ce339e36569e5849692f4cf4595e
- https://git.kernel.org/stable/c/7effc4ce3d1434ce6ff286866585a6e905fdbfc1
- https://git.kernel.org/stable/c/931f56d59c854263b32075bfac56fdb3b1598d1b
- https://git.kernel.org/stable/c/e724220b826e008764309d2a1f55a9434a4e1530
- https://git.kernel.org/stable/c/f08ee2aa24c076f81d84e26e213d8c6f4efd9f50
Modified: 2025-10-01
CVE-2022-49919
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flow rule object from commit path No need to postpone this to the commit release path, since no packets are walking over this object, this is accessed from control plane only. This helped uncovered UAF triggered by races with the netlink notifier.
- https://git.kernel.org/stable/c/26b5934ff4194e13196bedcba373cd4915071d0e
- https://git.kernel.org/stable/c/4ab6f96444e936f5e4a936d5c0bc948144bcded3
- https://git.kernel.org/stable/c/6044791b7be707fd0e709f26e961a446424e5051
- https://git.kernel.org/stable/c/74fd5839467054cd9c4d050614d3ee8788386171
- https://git.kernel.org/stable/c/b2d7a92aff0fbd93c29d2aa6451fb99f050e2c4e
Modified: 2025-10-01
CVE-2022-49920
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: netlink notifier might race to release objects commit release path is invoked via call_rcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path. Call rcu_barrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty.
Modified: 2025-10-01
CVE-2022-49921
In the Linux kernel, the following vulnerability has been resolved: net: sched: Fix use after free in red_enqueue() We can't use "skb" again after passing it to qdisc_enqueue(). This is basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb len before calling child enqueue").
- https://git.kernel.org/stable/c/170e5317042c302777ed6d59fdb84af9b0219d4e
- https://git.kernel.org/stable/c/52e0429471976785c155bfbf51d80990c6cd46e2
- https://git.kernel.org/stable/c/5960b9081baca85cc7dcb14aec1de85999ea9d36
- https://git.kernel.org/stable/c/795afe0b9bb6c915f0299a8e309936519be01619
- https://git.kernel.org/stable/c/8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9
- https://git.kernel.org/stable/c/a238cdcf2bdc72207c74375fc8be13ee549ca9db
- https://git.kernel.org/stable/c/e877f8fa49fbccc63cb2df2e9179bddc695b825a
- https://git.kernel.org/stable/c/fc4b50adb400ee5ec527a04073174e8e73a139fa
Modified: 2025-10-01
CVE-2022-49922
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds.
- https://git.kernel.org/stable/c/52438e734c1566f5e2bcd9a065d2d65e306c0555
- https://git.kernel.org/stable/c/5dfdac5e3f8db5f4445228c44f64091045644a3b
- https://git.kernel.org/stable/c/825656ae61e73ddc05f585e6258d284c87064b10
- https://git.kernel.org/stable/c/92a1df9c6da20c02cf9872f8b025a66ddb307aeb
- https://git.kernel.org/stable/c/93d904a734a74c54d945a9884b4962977f1176cd
- https://git.kernel.org/stable/c/c8e7d4a1166f063703955f1b2e765a6db5bf1771
- https://git.kernel.org/stable/c/dd0ee55ead91fbb16889dbe7ff0b0f7c9e4e849d
- https://git.kernel.org/stable/c/f30060efcf18883748a0541aa41acef183cd9c0e
Modified: 2025-10-01
CVE-2022-49923
In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds.
Modified: 2025-10-01
CVE-2022-49924
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished.
Modified: 2025-10-01
CVE-2022-49925
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
- https://git.kernel.org/stable/c/07c0d131cc0fe1f3981a42958fc52d573d303d89
- https://git.kernel.org/stable/c/6b3d5dcb12347f3518308c2c9d2cf72453a3e1e5
- https://git.kernel.org/stable/c/ab817f75e5e0fa58d9be0825da6a7b7d8a1fa1d9
- https://git.kernel.org/stable/c/af8fb5a0600e9ae29950e9422a032c3c22649ee5
- https://git.kernel.org/stable/c/d360e875c011a005628525bf290322058927e7dc
Modified: 2025-10-01
CVE-2022-49926
In the Linux kernel, the following vulnerability has been resolved: net: dsa: Fix possible memory leaks in dsa_loop_init() kmemleak reported memory leaks in dsa_loop_init(): kmemleak: 12 new suspected memory leaks unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ... There are two reasons for memleak in dsa_loop_init(). First, fixed_phy_register() create and register phy_device: fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove() But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked. Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs. Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.
- https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e
- https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254
- https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50
- https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3
- https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7
- https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f
- https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c
Modified: 2025-10-01
CVE-2022-49927
In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d
- https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67
- https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593
- https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c
- https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d
- https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127
- https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb
- https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401
Modified: 2025-10-01
CVE-2022-49928
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed
There is a null-ptr-deref when xps sysfs alloc failed:
BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0
Read of size 8 at addr 0000000000000030 by task gssproxy/457
CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9
Call Trace:
Modified: 2025-11-12
CVE-2022-49929
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix mr leak in RESPST_ERR_RNR rxe_recheck_mr() will increase mr's ref_cnt, so we should call rxe_put(mr) to drop mr's ref_cnt in RESPST_ERR_RNR to avoid below warning: WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe] ... Call Trace: rxe_dereg_mr+0x4c/0x60 [rdma_rxe] ib_dereg_mr_user+0xa8/0x200 [ib_core] ib_mr_pool_destroy+0x77/0xb0 [ib_core] nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma] nvme_rdma_free_queue+0x40/0x50 [nvme_rdma] nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma] nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma] process_one_work+0x582/0xa40 ? pwq_dec_nr_in_flight+0x100/0x100 ? rwlock_bug.part.0+0x60/0x60 worker_thread+0x2a9/0x700 ? process_one_work+0xa40/0xa40 kthread+0x168/0x1a0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Modified: 2025-10-01
CVE-2022-49930
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix NULL pointer problem in free_mr_init() Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL pointer. It should be init mutex_init() first before use the lock. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __mutex_lock.constprop.0+0xd0/0x5c0 __mutex_lock_slowpath+0x1c/0x2c mutex_lock+0x44/0x50 free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2] hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2] hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2] ib_dereg_mr_user+0x54/0x124 uverbs_free_mr+0x24/0x30 destroy_hw_idr_uobject+0x38/0x74 uverbs_destroy_uobject+0x48/0x1c4 uobj_destroy+0x74/0xcc ib_uverbs_cmd_verbs+0x368/0xbb0 ib_uverbs_ioctl+0xec/0x1a4 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x190 do_el0_svc+0x30/0x90 el0_svc+0x2c/0xb4 el0t_64_sync_handler+0x1a4/0x1b0 el0t_64_sync+0x19c/0x1a0
Modified: 2025-10-01
CVE-2022-49931
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list.
- https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55
- https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e
- https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0
- https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c
- https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926
Modified: 2025-11-24
CVE-2022-50234
In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: defer registered files gc to io_uring release Instead of putting io_uring's registered files in unix_gc() we want it to be done by io_uring itself. The trick here is to consider io_uring registered files for cycle detection but not actually putting them down. Because io_uring can't register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with io_ring_ctx_free(). [axboe: add kerneldoc comment to skb, fold in skb leak fix]
- https://git.kernel.org/stable/c/0091bfc81741b8d3aeb3b7ab8636f911b2de6e80
- https://git.kernel.org/stable/c/04df9719df1865f6770af9bc7880874af0e594b2
- https://git.kernel.org/stable/c/75e94c7e8859e58aadc15a98cc9704edff47d4f2
- https://git.kernel.org/stable/c/813d8fe5d30388f73a21d3a2bf46b0a1fd72498c
- https://git.kernel.org/stable/c/b4293c01ee0d0ecdd3cb5801e13f62271144667a
- https://git.kernel.org/stable/c/c378c479c5175833bb22ff71974cda47d7b05401
Modified: 2025-11-24
CVE-2022-50235
In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv2 READDIR Restore the previous limit on the @count argument to prevent a buffer overflow attack.
- https://git.kernel.org/stable/c/00b4492686e0497fdb924a9d4c8f6f99377e176c
- https://git.kernel.org/stable/c/0e57d696f60dee6117a8ace0cac7c5761d375277
- https://git.kernel.org/stable/c/c2a878095b5c6f04f90553a3c45872f990dab14e
- https://git.kernel.org/stable/c/dc7f225090c29a5f3b9419b1af32846a201555e7
- https://git.kernel.org/stable/c/f59c74df82f6ac9d2ea4e01aa3ae7c6c4481652d
Modified: 2025-11-24
CVE-2022-50239
In the Linux kernel, the following vulnerability has been resolved: cpufreq: qcom: fix writes in read-only memory region This commit fixes a kernel oops because of a write in some read-only memory: [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271] __memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190 [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c ..snip.. The following line defines a pointer that point to a char buffer stored in read-only memory: char *pvs_name = "speedXX-pvsXX-vXX"; This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the XX values get overridden by the qcom_cpufreq_krait_name_version function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops: snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the stack by using the following syntax: char pvs_name_buffer[] = "speedXX-pvsXX-vXX"; Because the `pvs_name` needs to be able to be assigned to NULL, the template buffer is stored in the pvs_name_buffer and not under the pvs_name variable.
Modified: 2025-11-25
CVE-2022-50241
In the Linux kernel, the following vulnerability has been resolved: NFSD: fix use-after-free on source server when doing inter-server copy Use-after-free occurred when the laundromat tried to free expired cpntf_state entry on the s2s_cp_stateids list after inter-server copy completed. The sc_cp_list that the expired copy state was inserted on was already freed. When COPY completes, the Linux client normally sends LOCKU(lock_state x), FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server. The nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state from the s2s_cp_stateids list before freeing the lock state's stid. However, sometimes the CLOSE was sent before the FREE_STATEID request. When this happens, the nfsd4_close_open_stateid call from nfsd4_close frees all lock states on its st_locks list without cleaning up the copy state on the sc_cp_list list. When the time the FREE_STATEID arrives the server returns BAD_STATEID since the lock state was freed. This causes the use-after-free error to occur when the laundromat tries to free the expired cpntf_state. This patch adds a call to nfs4_free_cpntf_statelist in nfsd4_close_open_stateid to clean up the copy state before calling free_ol_stateid_reaplist to free the lock state's stid on the reaplist.
- https://git.kernel.org/stable/c/019805fea91599b22dfa62ffb29c022f35abeb06
- https://git.kernel.org/stable/c/35aa0fb8c3033a3d78603356e96fc18c5b9cceb2
- https://git.kernel.org/stable/c/6ea71246b7a02af675d733e72d14bd0d591d5f4a
- https://git.kernel.org/stable/c/83b94969751a691347606dbe6b1865efcfa5a643
- https://git.kernel.org/stable/c/bbacfcde5fff25ac22597e8373a065c647da6738
Modified: 2025-11-24
CVE-2022-50243
In the Linux kernel, the following vulnerability has been resolved: sctp: handle the error returned from sctp_auth_asoc_init_active_key When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens.
- https://git.kernel.org/stable/c/022152aaebe116a25c39818a07e175a8cd3c1e11
- https://git.kernel.org/stable/c/0f90099d18e3abdc01babf686f41f63fe04939c1
- https://git.kernel.org/stable/c/19d636b663e0e92951bba5fced929ca7fd25c552
- https://git.kernel.org/stable/c/382ff44716603a54f5fd238ddec6a2468e217612
- https://git.kernel.org/stable/c/3b0fcf5e29c0940e1169ce9c44f73edd98bdf12d
- https://git.kernel.org/stable/c/b8fa99a3a11bdd77fef6b4a97f1021eb30b5ba40
- https://git.kernel.org/stable/c/f65955340e0044f5c41ac799a01698ac7dee8a4e
Modified: 2025-11-25
CVE-2022-50249
In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount.
- https://git.kernel.org/stable/c/05215fb32010d4afb68fbdbb4d237df6e2d4567b
- https://git.kernel.org/stable/c/1c6cac6fa4d08aea161f83d38117d733b3c3a000
- https://git.kernel.org/stable/c/2680690f9ce4e6abbb4f559e97271c15b7eeda97
- https://git.kernel.org/stable/c/62ccab6e3376f8a22167c3b81468ae4f3e7d25f1
- https://git.kernel.org/stable/c/68c9c4e6495b825be3a8946df1a0148399555fe4
- https://git.kernel.org/stable/c/85a40bfb8e7a170abcf9dae2c0898a1983e48daa
- https://git.kernel.org/stable/c/a4d0bd4388e1a39df47e8aaa044ef6a7ee626e48
- https://git.kernel.org/stable/c/a4f7eb83852a65b6f8dea7dcc42b7c76d4d9b0a3
- https://git.kernel.org/stable/c/daaec4b3fe2297b022c6b2d6bf48b6e5265a60b9
Modified: 2025-11-25
CVE-2022-50254
In the Linux kernel, the following vulnerability has been resolved: media: ov8865: Fix an error handling path in ov8865_probe() The commit in Fixes also introduced some new error handling which should goto the existing error handling path. Otherwise some resources leak.
Modified: 2025-11-25
CVE-2022-50255
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix reading strings from synthetic events The follow commands caused a crash: # cd /sys/kernel/tracing # echo 's:open char file[]' > dynamic_events # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sys_enter_openat/trigger' # echo 1 > events/synthetic/open/enable BOOM! The problem is that the synthetic event field "char file[]" will read the value given to it as a string without any memory checks to make sure the address is valid. The above example will pass in the user space address and the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an oops when accessing user space addresses. Use the helper functions from trace_kprobe and trace_eprobe that can read strings safely (and actually succeed when the address is from user space and the memory is mapped in). Now the above can show: packagekitd-1721 [000] ...2. 104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr in:imjournal-978 [006] ...2. 104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp packagekitd-1721 [000] ...2. 104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr
Modified: 2025-11-25
CVE-2022-50256
In the Linux kernel, the following vulnerability has been resolved: drm/meson: remove drm bridges at aggregate driver unbind time drm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init were not manually removed at module unload time, which caused dangling references to freed memory to remain linked in the global bridge_list. When loading the driver modules back in, the same functions would again call drm_bridge_add, and when traversing the global bridge_list, would end up peeking into freed memory. Once again KASAN revealed the problem: [ +0.000095] ============================================================= [ +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120 [ +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483 [ +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000006] dump_backtrace+0x1ec/0x280 [ +0.000012] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000008] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009] __list_add_valid+0x9c/0x120 [ +0.000009] drm_bridge_add+0x6c/0x104 [drm] [ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi] [ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi] [ +0.000014] component_bind+0x174/0x520 [ +0.000012] component_bind_all+0x1a8/0x38c [ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm] [ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm] [ +0.000027] try_to_bring_up_aggregate_device+0x19c/0x390 [ +0.000010] component_master_add_with_match+0x1c8/0x284 [ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm] [ +0.000026] platform_probe+0xd0/0x220 [ +0.000009] really_probe+0x3ac/0xa80 [ +0.000009] __driver_probe_device+0x1f8/0x400 [ +0.000009] driver_probe_device+0x68/0x1b0 [ +0.000009] __driver_attach+0x20c/0x480 [ +0.000008] bus_for_each_dev+0x114/0x1b0 [ +0.000009] driver_attach+0x48/0x64 [ +0.000008] bus_add_driver+0x390/0x564 [ +0.000009] driver_register+0x1a8/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm] [ +0.000027] do_one_initcall+0xc4/0x2b0 [ +0.000011] do_init_module+0x154/0x570 [ +0.000011] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000009] __arm64_sys_init_module+0x78/0xb0 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000016] Allocated by task 879: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] __kasan_kmalloc+0x90/0xd0 [ +0.000007] __kmalloc+0x278/0x4a0 [ +0.000011] mpi_resize+0x13c/0x1d0 [ +0.000011] mpi_powm+0xd24/0x1570 [ +0.000009] rsa_enc+0x1a4/0x30c [ +0.000009] pkcs1pad_verify+0x3f0/0x580 [ +0.000009] public_key_verify_signature+0x7a8/0xba4 [ +0.000010] public_key_verify_signature_2+0x40/0x60 [ +0.000008] verify_signature+0xb4/0x114 [ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574 [ +0.000009] pkcs7_validate_trust+0xb8/0x15c [ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0 [ +0.000012] verify_pkcs7_signature+0x78/0xac [ +0.000007] mod_verify_sig+0x110/0x190 [ +0.000009] module_sig_check+0x114/0x1e0 [ +0.000009] load_module+0xa0/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64 ---truncated---
Modified: 2025-11-25
CVE-2022-50257
In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: Prevent leaking grants Prior to this commit, if a grant mapping operation failed partially, some of the entries in the map_ops array would be invalid, whereas all of the entries in the kmap_ops array would be valid. This in turn would cause the following logic in gntdev_map_grant_pages to become invalid: for (i = 0; i < map->count; i++) { if (map->map_ops[i].status == GNTST_okay) { map->unmap_ops[i].handle = map->map_ops[i].handle; if (!use_ptemod) alloced++; } if (use_ptemod) { if (map->kmap_ops[i].status == GNTST_okay) { if (map->map_ops[i].status == GNTST_okay) alloced++; map->kunmap_ops[i].handle = map->kmap_ops[i].handle; } } } ... atomic_add(alloced, &map->live_grants); Assume that use_ptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the "alloced" variable is only incremented when both kmap_ops[i].status and map_ops[i].status are set to GNTST_okay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above. The aforementioned causes map->live_grants to be incorrectly set. In some cases, all of the map_ops mappings fail, but all of the kmap_ops mappings succeed, meaning that live_grants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmap_ops, because unmap_grant_pages has the following snippet of code at its beginning: if (atomic_read(&map->live_grants) == 0) return; /* Nothing to do */ In other cases where only some of the map_ops mappings fail but all kmap_ops mappings succeed, live_grants is made positive, but when the user requests unmapping the grant-mapped pages, __unmap_grant_pages_done will then make map->live_grants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts "data->count" (i.e., a value that can be greater than map->live_grants) from map->live_grants. The side effects of a negative live_grants value have not been studied. The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen's grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: "g.e. 0x1234 still pending", especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0). The fix for this issue involves counting all successful map_ops and kmap_ops mappings separately, and then adding the sum to live_grants. During unmapping, only the number of successfully unmapped grants is subtracted from live_grants. The code is also modified to check for negative live_grants values after the subtraction and warn the user.
- https://git.kernel.org/stable/c/0991028cd49567d7016d1b224fe0117c35059f86
- https://git.kernel.org/stable/c/0bccddd9b8f03ad57bb738f0d3da8845d4e1e579
- https://git.kernel.org/stable/c/1cb73704cb4778299609634a790a80daba582f7d
- https://git.kernel.org/stable/c/273f6a4f71be12e2ec80a4919837d6e4fa933a04
- https://git.kernel.org/stable/c/3d056d81b93a787613eda44aeb21fc14c3392b34
- https://git.kernel.org/stable/c/49bb053b1ec367b6883030eb2cca696e91435679
- https://git.kernel.org/stable/c/49db6cb81400ba863e1a85e55fcdf1031807c23f
- https://git.kernel.org/stable/c/b043f2cab100bed3e0a999dcf38cc05b1e4a7e41
- https://git.kernel.org/stable/c/cb1ccfe7655380f77a58b340072f5f40bc285902
Modified: 2025-11-25
CVE-2022-50260
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Make .remove and .shutdown HW shutdown consistent Drivers' .remove and .shutdown callbacks are executed on different code paths. The former is called when a device is removed from the bus, while the latter is called at system shutdown time to quiesce the device. This means that some overlap exists between the two, because both have to take care of properly shutting down the hardware. But currently the logic used in these two callbacks isn't consistent in msm drivers, which could lead to kernel panic. For example, on .remove the component is deleted and its .unbind callback leads to the hardware being shutdown but only if the DRM device has been marked as registered. That check doesn't exist in the .shutdown logic and this can lead to the driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't been properly initialized. A situation like this can happen if drivers for expected sub-devices fail to probe, since the .bind callback will never be executed. If that is the case, drm_atomic_helper_shutdown() will attempt to take mutexes that are only initialized if drm_mode_config_init() is called during a device bind. This bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix shutdown hook in case GPU components failed to bind"), but unfortunately it still happens in some cases as the one mentioned above, i.e: systemd-shutdown[1]: Powering off. kvm: exiting hardware virtualization platform wifi-firmware.0: Removing from iommu group 12 platform video-firmware.0: Removing from iommu group 10 ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0 ... Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0 lr : drm_modeset_lock_all_ctx+0x48/0x3d0 sp : ffff80000805bb80 x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030 x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800 x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000 x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0 Call trace: drm_modeset_lock_all_ctx+0x3c4/0x3d0 drm_atomic_helper_shutdown+0x70/0x134 msm_drv_shutdown+0x30/0x40 platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_sys_reboot+0x28/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x44/0xec do_el0_svc+0x2c/0xc0 el0_svc+0x2c/0x84 el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x18c/0x190 ---[ end trace 0000000000000000 ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000 [0000000000000018] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP ... Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ww_mutex_lock+0x28/0x32c lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0 sp : ffff80000805bb50 x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000 x26: 00000 ---truncated---
Modified: 2025-12-03
CVE-2022-50265
In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_wait kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. syzbot reported: BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: reserve_rx_kcm net/kcm/kcmsock.c:283 [inline] kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x01 -> 0x00 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
- https://git.kernel.org/stable/c/0c745b5141a45a076f1cb9772a399f7ebcb0948a
- https://git.kernel.org/stable/c/2733fb2ad5bfbe6538f2f93a21f2504e3dba9d6a
- https://git.kernel.org/stable/c/62086d1c4602e4f2ec07b975165afc2ed0ff1be9
- https://git.kernel.org/stable/c/663682cd3192dd4f3547b7890a4391c72441001d
- https://git.kernel.org/stable/c/9ae47f11493509cde707af8ecc7eee04c8b8e635
- https://git.kernel.org/stable/c/dbc3a0b917c4f75292b1c0819c188e40fd3c8924
- https://git.kernel.org/stable/c/e2a28807b1ceaa309164b92c38d73d12feea33df
- https://git.kernel.org/stable/c/f1f7122bb2ef056afc6f91ce4c35ab6df1207c8d
Modified: 2025-12-03
CVE-2022-50271
In the Linux kernel, the following vulnerability has been resolved:
vhost/vsock: Use kvmalloc/kvfree for larger packets.
When copying a large file over sftp over vsock, data size is usually 32kB,
and kmalloc seems to fail to try to allocate 32 32kB regions.
vhost-5837: page allocation failure: order:4, mode:0x24040c0
Call Trace:
[
- https://git.kernel.org/stable/c/0d720c3f0a03e97867deab7e480ba3d3e19837ba
- https://git.kernel.org/stable/c/0e3f72931fc47bb81686020cc643cde5d9cd0bb8
- https://git.kernel.org/stable/c/36c9f340c60413e28f980c0224c4e9d35851526b
- https://git.kernel.org/stable/c/7aac8c63f604e6a6a46560c0f0188cd0332cf320
- https://git.kernel.org/stable/c/a99fc6d818161d6f1ff3307de8bf5237f6cc34d8
- https://git.kernel.org/stable/c/b4a5905fd2ef841cd61e969ea692c213c2e5c1f7
- https://git.kernel.org/stable/c/e28a4e7f0296824c61a81e7fd54ab48bad3e75ad
- https://git.kernel.org/stable/c/e6d0152c95108651f1880c1ddfab47cb9e3e62d0
Modified: 2025-12-03
CVE-2022-50273
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on destination blkaddr during recovery
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=216456
loop5: detected capacity change from 0 to 131072
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): Bitmap was wrongly set, blk:5634
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198
RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]
Call Trace:
- https://git.kernel.org/stable/c/0ef4ca04a3f9223ff8bc440041c524b2123e09a3
- https://git.kernel.org/stable/c/3a4d24d746866dd45d970bd565ff3886e839366a
- https://git.kernel.org/stable/c/68b1e607559d3dc85f94b0d738d7c4e8029b0cfa
- https://git.kernel.org/stable/c/73fb4bd2c055a393816f078f158cdd3025006f1d
- https://git.kernel.org/stable/c/8f0a47def4722c5fd8d6b9268b5ffed8a249e2db
- https://git.kernel.org/stable/c/ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362
Modified: 2025-12-04
CVE-2022-50281
In the Linux kernel, the following vulnerability has been resolved: MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create() In error case in bridge_platform_create after calling platform_device_add()/platform_device_add_data()/ platform_device_add_resources(), release the failed 'pdev' or it will be leak, call platform_device_put() to fix this problem. Besides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd', use platform_device_unregister() to release sgi_w1 resources when xtalk-bridge registration fails.
- https://git.kernel.org/stable/c/11bec9cba4de06b3c0e9e4041453c2caaa1cbec1
- https://git.kernel.org/stable/c/48025893b3e31b917ad654d28d23fff66681cac4
- https://git.kernel.org/stable/c/93296e7ab774230b7c36541dead10b6da39b650f
- https://git.kernel.org/stable/c/d7ac29e60d0ff71e9e414af595b8c92800f7fa90
- https://git.kernel.org/stable/c/da2aecef866b476438d02c662507a0e4e818da9d
Modified: 2025-12-04
CVE-2022-50283
In the Linux kernel, the following vulnerability has been resolved: mtd: core: add missing of_node_get() in dynamic partitions code This fixes unbalanced of_node_put(): [ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand [ 1.085116] Creating 6 MTD partitions on "gpmi-nand": [ 1.090181] 0x000000000000-0x000008000000 : "nandboot" [ 1.096952] 0x000008000000-0x000009000000 : "nandfit" [ 1.103547] 0x000009000000-0x00000b000000 : "nandkernel" [ 1.110317] 0x00000b000000-0x00000c000000 : "nanddtb" [ 1.115525] ------------[ cut here ]------------ [ 1.120141] refcount_t: addition on 0; use-after-free. [ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xdc/0x148 [ 1.133528] Modules linked in: [ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7 [ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT) [ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158965] pc : refcount_warn_saturate+0xdc/0x148 [ 1.163760] lr : refcount_warn_saturate+0xdc/0x148 [ 1.168556] sp : ffff800009ddb080 [ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002 [ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05 [ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000 [ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff [ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004 [ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003 [ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00 [ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b [ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000 [ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a [ 1.243365] Call trace: [ 1.245806] refcount_warn_saturate+0xdc/0x148 [ 1.250253] kobject_get+0x98/0x9c [ 1.253658] of_node_get+0x20/0x34 [ 1.257072] of_fwnode_get+0x3c/0x54 [ 1.260652] fwnode_get_nth_parent+0xd8/0xf4 [ 1.264926] fwnode_full_name_string+0x3c/0xb4 [ 1.269373] device_node_string+0x498/0x5b4 [ 1.273561] pointer+0x41c/0x5d0 [ 1.276793] vsnprintf+0x4d8/0x694 [ 1.280198] vprintk_store+0x164/0x528 [ 1.283951] vprintk_emit+0x98/0x164 [ 1.287530] vprintk_default+0x44/0x6c [ 1.291284] vprintk+0xf0/0x134 [ 1.294428] _printk+0x54/0x7c [ 1.297486] of_node_release+0xe8/0x128 [ 1.301326] kobject_put+0x98/0xfc [ 1.304732] of_node_put+0x1c/0x28 [ 1.308137] add_mtd_device+0x484/0x6d4 [ 1.311977] add_mtd_partitions+0xf0/0x1d0 [ 1.316078] parse_mtd_partitions+0x45c/0x518 [ 1.320439] mtd_device_parse_register+0xb0/0x274 [ 1.325147] gpmi_nand_probe+0x51c/0x650 [ 1.329074] platform_probe+0xa8/0xd0 [ 1.332740] really_probe+0x130/0x334 [ 1.336406] __driver_probe_device+0xb4/0xe0 [ 1.340681] driver_probe_device+0x3c/0x1f8 [ 1.344869] __driver_attach+0xdc/0x1a4 [ 1.348708] bus_for_each_dev+0x80/0xcc [ 1.352548] driver_attach+0x24/0x30 [ 1.356127] bus_add_driver+0x108/0x1f4 [ 1.359967] driver_register+0x78/0x114 [ 1.363807] __platform_driver_register+0x24/0x30 [ 1.368515] gpmi_nand_driver_init+0x1c/0x28 [ 1.372798] do_one_initcall+0xbc/0x238 [ 1.376638] do_initcall_level+0x94/0xb4 [ 1.380565] do_initcalls+0x54/0x94 [ 1.384058] do_basic_setup+0x1c/0x28 [ 1.387724] kernel_init_freeable+0x110/0x188 [ 1.392084] kernel_init+0x20/0x1a0 [ 1.395578] ret_from_fork+0x10/0x20 [ 1.399157] ---[ end trace 0000000000000000 ]--- [ 1.403782] ------------[ cut here ]------------
Modified: 2025-12-04
CVE-2022-50285
In the Linux kernel, the following vulnerability has been resolved: mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages The h->*_huge_pages counters are protected by the hugetlb_lock, but alloc_huge_page has a corner case where it can decrement the counter outside of the lock. This could lead to a corrupted value of h->resv_huge_pages, which we have observed on our systems. Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a potential race.
- https://git.kernel.org/stable/c/112a005d1ded04a4b41b6d01833cc0bda90625cc
- https://git.kernel.org/stable/c/11993652d0b49e27272db0a37aa828d8a3a4b92b
- https://git.kernel.org/stable/c/12df140f0bdfae5dcfc81800970dd7f6f632e00c
- https://git.kernel.org/stable/c/2b35432d324898ec41beb27031d2a1a864a4d40e
- https://git.kernel.org/stable/c/3e50a07b6a5fcd39df1534d3fdaca4292a65efe6
- https://git.kernel.org/stable/c/568e3812b1778b4c0c229649b59977d88f400ece
- https://git.kernel.org/stable/c/629c986e19fe9481227c7cdfd9a105bbc104d245
- https://git.kernel.org/stable/c/c828fab903725279aa9dc6ae3d44bb7e4778f92c
Modified: 2025-12-04
CVE-2022-50291
In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_psock kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. We do the same for kcm->rx_wait in the following patch. syzbot reported: BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1: unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313 kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffff88812971ce00 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
- https://git.kernel.org/stable/c/12a0eb340c9a22e0f8c00d2c0c1a60695ead926a
- https://git.kernel.org/stable/c/13dba69e18d04c8eec7596369f2a0596b0260275
- https://git.kernel.org/stable/c/15e4dabda11b0fa31d510a915d1a580f47dfc92e
- https://git.kernel.org/stable/c/1b8a5692ab25db4ef1c2cc8e5d21f7a65dc3d079
- https://git.kernel.org/stable/c/342d918cf9a45df9cf11bbe7162b851adefd178f
- https://git.kernel.org/stable/c/bf46af730e58d340f6f740bc69a07c5f6b85c655
- https://git.kernel.org/stable/c/c325f92d8d9b223d5842609ca067e898e9d34566
- https://git.kernel.org/stable/c/e94395e916b48a5b912a0a04570981b5b091acb0
Modified: 2025-12-04
CVE-2022-50292
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix bridge lifetime Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP bridges, previously allocated bridges will leak on probe deferral. Fix this by amending the DP parser interface and tying the lifetime of the bridge device to the DRM device rather than DP platform device. Patchwork: https://patchwork.freedesktop.org/patch/502667/
Modified: 2025-12-04
CVE-2022-50295
In the Linux kernel, the following vulnerability has been resolved:
io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()
Syzkaller produced the below call trace:
BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0
Write of size 8 at addr 0000000000000070 by task repro/16399
CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
Call Trace:
Modified: 2025-12-04
CVE-2022-50296
In the Linux kernel, the following vulnerability has been resolved: UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
- https://git.kernel.org/stable/c/16c546e148fa6d14a019431436a6f7b4087dbccd
- https://git.kernel.org/stable/c/2e3863cc02c156b51b50592d43ffa6a13b680b0d
- https://git.kernel.org/stable/c/5177bdc38eaa1c1ca6302214ab06913540cd00a2
- https://git.kernel.org/stable/c/6a73e6edcbf3cdd82796dcdf0c0f5fe5d91021af
- https://git.kernel.org/stable/c/7efe61dc6aa45aab8a40e304fa2dae21e33b0db4
- https://git.kernel.org/stable/c/844748412be03a236dcf4a208b588162a275e189
- https://git.kernel.org/stable/c/8f96aa67c2ccbd7e41b8dc992b8d13cfe206d571
- https://git.kernel.org/stable/c/cd251d39b13485eb94ee65bb000d024e02c00e45
- https://git.kernel.org/stable/c/dbd964a733db015bbb9dff592c259c736398140f
Modified: 2025-12-04
CVE-2022-50298
In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd: cleanup in probe error path Add proper error path in probe() to cleanup resources previously acquired/allocated to fix warnings visible during probe deferral: notifier callback qcom_slim_ngd_ssr_notify already registered WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90 Modules linked in: CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380 Call trace: notifier_chain_register+0x5c/0x90 srcu_notifier_chain_register+0x44/0x90 qcom_register_ssr_notifier+0x38/0x4c qcom_slim_ngd_ctrl_probe+0xd8/0x400 platform_probe+0x6c/0xe0 really_probe+0xbc/0x2d4 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0x12c __device_attach_driver+0xb8/0x120 bus_for_each_drv+0x78/0xd0 __device_attach+0xa8/0x1c0 device_initial_probe+0x18/0x24 bus_probe_device+0xa0/0xac deferred_probe_work_func+0x88/0xc0 process_one_work+0x1d4/0x320 worker_thread+0x2cc/0x44c kthread+0x110/0x114 ret_from_fork+0x10/0x20
Modified: 2025-12-04
CVE-2022-50299
In the Linux kernel, the following vulnerability has been resolved:
md: Replace snprintf with scnprintf
Current code produces a warning as shown below when total characters
in the constituent block device names plus the slashes exceeds 200.
snprintf() returns the number of characters generated from the given
input, which could cause the expression “200 – len” to wrap around
to a large positive number. Fix this by using scnprintf() instead,
which returns the actual number of characters written into the buffer.
[ 1513.267938] ------------[ cut here ]------------
[ 1513.267943] WARNING: CPU: 15 PID: 37247 at
- https://git.kernel.org/stable/c/1727fd5015d8f93474148f94e34cda5aa6ad4a43
- https://git.kernel.org/stable/c/3b0a2bd51f60418ecd67493586a2bb2174199de3
- https://git.kernel.org/stable/c/41ca95033a0c47cd6dace1f0a36a6eb5ebe799e6
- https://git.kernel.org/stable/c/5d8259c9d1915a50c60c7d6e9e7fb9b7da64a175
- https://git.kernel.org/stable/c/76694e9ce0b2238c0a5f3ba54f9361dd3770ec78
- https://git.kernel.org/stable/c/897b1450abe5a67c842a5d24173ce4449ccdfa94
- https://git.kernel.org/stable/c/97238b88583c27c9d3b4a0cedb45f816523f17c3
- https://git.kernel.org/stable/c/f95825c4e51cf9a653b0ef947ac78401fc9d3a40
Modified: 2025-12-04
CVE-2022-50301
In the Linux kernel, the following vulnerability has been resolved: iommu/omap: Fix buffer overflow in debugfs There are two issues here: 1) The "len" variable needs to be checked before the very first write. Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a buffer overflow. 2) The snprintf() function returns the number of bytes that *would* have been copied if there were enough space. But we want to know the number of bytes which were *actually* copied so use scnprintf() instead.
- https://git.kernel.org/stable/c/0c7043a5b5c3b35f5dc8875757f71e7f491d64d4
- https://git.kernel.org/stable/c/184233a5202786b20220acd2d04ddf909ef18f29
- https://git.kernel.org/stable/c/2fee0dbfaeaaa4bda04279ce772c4572b1429d04
- https://git.kernel.org/stable/c/4010a1afaae1c0fb9c2cac5de703bed29b1f1782
- https://git.kernel.org/stable/c/648472df221f2bbffb433b964bcb87baccc586d8
- https://git.kernel.org/stable/c/706e359cf046c142db290244c3f4938b20fbe805
- https://git.kernel.org/stable/c/9814cc350e0765ce69244bf55ae4c8b29facd27e
- https://git.kernel.org/stable/c/bd0438f534b2e31b12f0b39b355c5dc2bbdaf854
- https://git.kernel.org/stable/c/ec53b99b6b9da8b501f001595a6260c03b42d5b7
Modified: 2025-12-04
CVE-2022-50306
In the Linux kernel, the following vulnerability has been resolved: ext4: fix potential out of bound read in ext4_fc_replay_scan() For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.
Modified: 2025-12-04
CVE-2022-50307
In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix out-of-bounds access on cio_ignore free The channel-subsystem-driver scans for newly available devices whenever device-IDs are removed from the cio_ignore list using a command such as: echo free >/proc/cio_ignore Since an I/O device scan might interfer with running I/Os, commit 172da89ed0ea ("s390/cio: avoid excessive path-verification requests") introduced an optimization to exclude online devices from the scan. The newly added check for online devices incorrectly assumes that an I/O-subchannel's drvdata points to a struct io_subchannel_private. For devices that are bound to a non-default I/O subchannel driver, such as the vfio_ccw driver, this results in an out-of-bounds read access during each scan. Fix this by changing the scan logic to rely on a driver-independent online indication. For this we can use struct subchannel->config.ena, which is the driver's requested subchannel-enabled state. Since I/Os can only be started on enabled subchannels, this matches the intent of the original optimization of not scanning devices where I/O might be running.
Modified: 2025-12-04
CVE-2022-50309
In the Linux kernel, the following vulnerability has been resolved: media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1c78f19c3a0ea312a8178a6bfd8934eb93e9b10a
- https://git.kernel.org/stable/c/22b93530bbe6af9dce8e520bb6e978d1bda39d2b
- https://git.kernel.org/stable/c/2630cc88327a5557aa0d9cc63be95e3c6e0a55b3
- https://git.kernel.org/stable/c/2ea7caa9684687cf3adc1467cf4af3653a776192
- https://git.kernel.org/stable/c/3336210948b22c2db43e9df2ea403d251b4d24ab
- https://git.kernel.org/stable/c/3c38467c3255c428cdbd3cefaccca4662f302dc9
- https://git.kernel.org/stable/c/59b315353252abe7b8fdb8651ca31b8484ce287a
- https://git.kernel.org/stable/c/6e7b3b1e4e9f739800cd8010b75a9bee8d808cee
- https://git.kernel.org/stable/c/7b0efe7534071e0153708886355d80db69525d50
Modified: 2025-12-04
CVE-2022-50310
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: fix UAF issue in ip6mr_sk_done() when addrconf_init_net() failed
If the initialization fails in calling addrconf_init_net(), devconf_all is
the pointer that has been released. Then ip6mr_sk_done() is called to
release the net, accessing devconf->mc_forwarding directly causes invalid
pointer access.
The process is as follows:
setup_net()
ops_init()
addrconf_init_net()
all = kmemdup(...) ---> alloc "all"
...
net->ipv6.devconf_all = all;
__addrconf_sysctl_register() ---> failed
...
kfree(all); ---> ipv6.devconf_all invalid
...
ops_exit_list()
...
ip6mr_sk_done()
devconf = net->ipv6.devconf_all;
//devconf is invalid pointer
if (!devconf || !atomic_read(&devconf->mc_forwarding))
The following is the Call Trace information:
BUG: KASAN: use-after-free in ip6mr_sk_done+0x112/0x3a0
Read of size 4 at addr ffff888075508e88 by task ip/14554
Call Trace:
Modified: 2025-12-04
CVE-2022-50312
In the Linux kernel, the following vulnerability has been resolved: drivers: serial: jsm: fix some leaks in probe This error path needs to unwind instead of just returning directly.
- https://git.kernel.org/stable/c/1d5859ef229e381f4db38dce8ed58e4bf862006b
- https://git.kernel.org/stable/c/3bf05c2650cf6b8d83bf0b0d808cc78c6ee7e84c
- https://git.kernel.org/stable/c/3ea1fd63fdf0e83b491c2a9f25b395aa0e4bf6e8
- https://git.kernel.org/stable/c/6066bd69ffba3a6abc7c0793ccba1da79b7d77e3
- https://git.kernel.org/stable/c/6be8e565a4a60530797a974d0a3d0e30656166a1
- https://git.kernel.org/stable/c/71ffe5111f0ffa2fd43c14fd176c6f05d4e82212
- https://git.kernel.org/stable/c/737594536dc3ce732976c0d84bb1dcc842065521
- https://git.kernel.org/stable/c/744c2d33a88b082d9d504520f0132b3d688547b2
- https://git.kernel.org/stable/c/ff9a5e50fb1910be33e62925bc7ee3bef474879e
Modified: 2025-12-04
CVE-2022-50313
In the Linux kernel, the following vulnerability has been resolved: erofs: fix order >= MAX_ORDER warning due to crafted negative i_size As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly. Let's fall back to the generic path to deal with such unusual i_size. [1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com
- https://git.kernel.org/stable/c/0ab621fcdff1a58ff4de51a8590fa92a0ecd34be
- https://git.kernel.org/stable/c/17a0cdbd7b0cf0fc0d7ca4187a67f8f1c18c291f
- https://git.kernel.org/stable/c/1dd73601a1cba37a0ed5f89a8662c90191df5873
- https://git.kernel.org/stable/c/6235fb899b25fd287d5e42635ff82196395708cc
- https://git.kernel.org/stable/c/acc2f40b980c61a9178b72cdedd150b829064997
- https://git.kernel.org/stable/c/b6c8330f5b0f22149957a2e4977fd0f01a9db7cd
Modified: 2025-12-04
CVE-2022-50314
In the Linux kernel, the following vulnerability has been resolved: nbd: Fix hung when signal interrupts nbd_start_device_ioctl() syzbot reported hung task [1]. The following program is a simplified version of the reproducer: int main(void) { int sv[2], fd; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 1; if ((fd = open("/dev/nbd0", 0)) < 0) return 1; if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0) return 1; if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0) return 1; if (ioctl(fd, NBD_DO_IT) < 0) return 1; return 0; } When signal interrupt nbd_start_device_ioctl() waiting the condition atomic_read(&config->recv_threads) == 0, the task can hung because it waits the completion of the inflight IOs. This patch fixes the issue by clearing queue, not just shutdown, when signal interrupt nbd_start_device_ioctl().
- https://git.kernel.org/stable/c/1de7c3cf48fc41cd95adb12bd1ea9033a917798a
- https://git.kernel.org/stable/c/3575949513ea3b387b30dac1e69468a923c86caf
- https://git.kernel.org/stable/c/35fb7d4a53d9e36d1b91161ea9870d9c6d57dccf
- https://git.kernel.org/stable/c/3ba3846cb3e2fb3c6fbf79e998472821b298419e
- https://git.kernel.org/stable/c/62006a72b05e0d38727eef5188700f2488be5e89
- https://git.kernel.org/stable/c/b2700f98b3f4dd19fb4315b70581e5caff89eb49
- https://git.kernel.org/stable/c/c0d73be0af8c1310713bc39a8d7a22e35084e14f
- https://git.kernel.org/stable/c/c7b4641bd2395c2f3cd3b0a0cbf292ed9d489398
Modified: 2025-12-04
CVE-2022-50315
In the Linux kernel, the following vulnerability has been resolved:
ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS
UBSAN complains about array-index-out-of-bounds:
[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41
[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'
[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu
[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010
[ 1.980718] kernel: Call Trace:
[ 1.980721] kernel:
- https://git.kernel.org/stable/c/1e41e693f458eef2d5728207dbd327cd3b16580a
- https://git.kernel.org/stable/c/303d0f761431d848dd8d7ff9fd9b8c101879cabe
- https://git.kernel.org/stable/c/383b7c50f5445ff8dbbf03080905648d6980c39d
- https://git.kernel.org/stable/c/67a00c299c5c143817c948fbc7de1a2fa1af38fb
- https://git.kernel.org/stable/c/8fbe13de1cc7cef2564be3cbf60400b33eee023b
- https://git.kernel.org/stable/c/d6314d5f68764550c84d732ce901ddd3ac6b415f
- https://git.kernel.org/stable/c/da2ea4a961d9f89ed248734e7032350c260dc3a3
- https://git.kernel.org/stable/c/f70bd4339cb68bc7e206af4c922bc0d249244403
Modified: 2025-12-04
CVE-2022-50317
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: megachips: Fix a null pointer dereference bug When removing the module we will get the following warning: [ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered [ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI [ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130 [ 31.921825] Call Trace: [ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw] [ 31.923139] i2c_device_remove+0x181/0x1f0 The two bridges (stdp2690, stdp4028) do not probe at the same time, so the driver does not call ge_b850v3_resgiter() when probing, causing the driver to try to remove the object that has not been initialized. Fix this by checking whether both the bridges are probed.
- https://git.kernel.org/stable/c/1daf69228e310938177119c4eadcd30fc75c81e0
- https://git.kernel.org/stable/c/1ff673333d46d2c1b053ebd0c1c7c7c79e36943e
- https://git.kernel.org/stable/c/21764467ab396d9f08921e0a5ffa1214244e1ad9
- https://git.kernel.org/stable/c/4610e7a4111fa3f3ce27c09d6d94008c55f1cd31
- https://git.kernel.org/stable/c/5bc20bafcd87ba0858ab772cefc7047cb51bc249
- https://git.kernel.org/stable/c/7371fad5cfe6eada6bb5523c895fd6074b15c2b9
- https://git.kernel.org/stable/c/877e92e9b1bdeb580b31a46061005936be902cd4
- https://git.kernel.org/stable/c/aaa512ad1e59f2edf8a9e4f2b167a44b24670679
Modified: 2025-12-04
CVE-2022-50320
In the Linux kernel, the following vulnerability has been resolved:
ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys address
On a Packard Bell Dot SC (Intel Atom N2600 model) there is a FPDT table
which contains invalid physical addresses, with high bits set which fall
outside the range of the CPU-s supported physical address range.
Calling acpi_os_map_memory() on such an invalid phys address leads to
the below WARN_ON in ioremap triggering resulting in an oops/stacktrace.
Add code to verify the physical address before calling acpi_os_map_memory()
to fix / avoid the oops.
[ 1.226900] ioremap: invalid physical address 3001000000000000
[ 1.226949] ------------[ cut here ]------------
[ 1.226962] WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:200 __ioremap_caller.cold+0x43/0x5f
[ 1.226996] Modules linked in:
[ 1.227016] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc3+ #490
[ 1.227029] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 1.227038] RIP: 0010:__ioremap_caller.cold+0x43/0x5f
[ 1.227054] Code: 96 00 00 e9 f8 af 24 ff 89 c6 48 c7 c7 d8 0c 84 99 e8 6a 96 00 00 e9 76 af 24 ff 48 89 fe 48 c7 c7 a8 0c 84 99 e8 56 96 00 00 <0f> 0b e9 60 af 24 ff 48 8b 34 24 48 c7 c7 40 0d 84 99 e8 3f 96 00
[ 1.227067] RSP: 0000:ffffb18c40033d60 EFLAGS: 00010286
[ 1.227084] RAX: 0000000000000032 RBX: 3001000000000000 RCX: 0000000000000000
[ 1.227095] RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff
[ 1.227105] RBP: 3001000000000000 R08: 0000000000000000 R09: ffffb18c40033c18
[ 1.227115] R10: 0000000000000003 R11: ffffffff99d62fe8 R12: 0000000000000008
[ 1.227124] R13: 0003001000000000 R14: 0000000000001000 R15: 3001000000000000
[ 1.227135] FS: 0000000000000000(0000) GS:ffff913a3c080000(0000) knlGS:0000000000000000
[ 1.227146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.227156] CR2: 0000000000000000 CR3: 0000000018c26000 CR4: 00000000000006e0
[ 1.227167] Call Trace:
[ 1.227176]
Modified: 2025-12-04
CVE-2022-50323
In the Linux kernel, the following vulnerability has been resolved: net: do not sense pfmemalloc status in skb_append_pagefrags() skb_append_pagefrags() is used by af_unix and udp sendpage() implementation so far. In commit 326140063946 ("tcp: TX zerocopy should not sense pfmemalloc status") we explained why we should not sense pfmemalloc status for pages owned by user space. We should also use skb_fill_page_desc_noacc() in skb_append_pagefrags() to avoid following KCSAN report: BUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:323 [inline] lru_add_fn+0x327/0x410 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 lru_add_drain_cpu+0x73/0x250 mm/swap.c:669 lru_add_drain+0x21/0x60 mm/swap.c:773 free_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311 tlb_batch_pages_flush mm/mmu_gather.c:59 [inline] tlb_flush_mmu_free mm/mmu_gather.c:256 [inline] tlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263 tlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363 exit_mmap+0x190/0x4d0 mm/mmap.c:3098 __mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copy_process+0x19fc/0x2100 kernel/fork.c:2518 kernel_clone+0x166/0x550 kernel/fork.c:2671 __do_sys_clone kernel/fork.c:2812 [inline] __se_sys_clone kernel/fork.c:2796 [inline] __x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1817 [inline] __skb_fill_page_desc include/linux/skbuff.h:2432 [inline] skb_fill_page_desc include/linux/skbuff.h:2453 [inline] skb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974 unix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xffffea00058fc188 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
Modified: 2025-12-03
CVE-2022-50326
In the Linux kernel, the following vulnerability has been resolved: media: airspy: fix memory leak in airspy probe The commit ca9dc8d06ab6 ("media: airspy: respect the DMA coherency rules") moves variable buf from stack to heap, however, it only frees buf in the error handling code, missing deallocation in the success path. Fix this by freeing buf in the success path since this variable does not have any references in other code.
Modified: 2025-12-04
CVE-2022-50328
In the Linux kernel, the following vulnerability has been resolved: jbd2: fix potential use-after-free in jbd2_fc_wait_bufs In 'jbd2_fc_wait_bufs' use 'bh' after put buffer head reference count which may lead to use-after-free. So judge buffer if uptodate before put buffer head reference count.
- https://git.kernel.org/stable/c/1d4d16daec2a6689b6d3fbfc7d2078643adc6619
- https://git.kernel.org/stable/c/243d1a5d505d0b0460c9af0ad56ed4a56ef0bebd
- https://git.kernel.org/stable/c/2e6d9f381c1ed844531a577783fc352de7a44c8a
- https://git.kernel.org/stable/c/d11d2ded293976a1a0d9d9471827a44dc9e3c63f
- https://git.kernel.org/stable/c/effd9b3c029ecdd853a11933dcf857f5a7ca8c3d
Modified: 2025-12-04
CVE-2022-50330
In the Linux kernel, the following vulnerability has been resolved: crypto: cavium - prevent integer overflow loading firmware The "code_length" value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly. The "ntohl(ucode->code_length) * 2" multiplication can have an integer overflow.
- https://git.kernel.org/stable/c/172c8a24fc8312cf6b88d3c88469653fdcb1c127
- https://git.kernel.org/stable/c/2526d6bf27d15054bb0778b2f7bc6625fd934905
- https://git.kernel.org/stable/c/371fa5129af53a79f6dddc90fe5bb0825cbe72a4
- https://git.kernel.org/stable/c/3a720eb89026c5241b8c4abb33370dc6fb565eee
- https://git.kernel.org/stable/c/584561e94260268abe1c83e00d9c205565cb7bc5
- https://git.kernel.org/stable/c/90e483e7f20c32287d2a9da967e122938f52737a
- https://git.kernel.org/stable/c/c4d4c2afd08dfb3cd1c880d1811ede2568e81a6d
- https://git.kernel.org/stable/c/e29fd7a6852376d2cfb95ad5d6d3eeff93f815e9
Modified: 2025-12-03
CVE-2022-50331
In the Linux kernel, the following vulnerability has been resolved: wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff88810152ad20 (size 8): comm "modprobe", pid 252, jiffies 4294849206 (age 22.713s) hex dump (first 8 bytes): 68 77 73 69 6d 30 00 ff hwsim0.. backtrace: [<000000009c3504ed>] __kmalloc_node_track_caller+0x44/0x1b0 [<00000000c0228a5e>] kvasprintf+0xb5/0x140 [<00000000cff8c21f>] kvasprintf_const+0x55/0x180 [<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150 [<000000000a80b139>] dev_set_name+0xab/0xe0
Modified: 2026-01-14
CVE-2022-50339
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev() syzbot is again reporting attempt to cancel uninitialized work at mgmt_index_removed() [1], for setting of HCI_MGMT flag from mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can race with testing of HCI_MGMT flag from mgmt_index_removed() from hci_sock_bind() due to lack of serialization via hci_dev_lock(). Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag after INIT_DELAYED_WORK() completed. This is a local fix based on mgmt_chan_list_lock. Lack of serialization via hci_dev_lock() might be causing different race conditions somewhere else. But a global fix based on hci_dev_lock() should deserve a future patch.
Modified: 2026-01-14
CVE-2022-50344
In the Linux kernel, the following vulnerability has been resolved: ext4: fix null-ptr-deref in ext4_write_info I caught a null-ptr-deref bug as follows: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339 RIP: 0010:ext4_write_info+0x53/0x1b0 [...] Call Trace: dquot_writeback_dquots+0x341/0x9a0 ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0 generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130 deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0 exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================== Above issue may happen as follows: ------------------------------------- exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount dentry = sb->s_root sb->s_root = NULL <--- Here set NULL sync_filesystem __sync_filesystem sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <--- Null pointer dereference To solve this problem, we use ext4_journal_start_sb directly to avoid s_root being used.
- https://git.kernel.org/stable/c/3638aa1c7d87c0ca0aef23cf58cae2c48e7daca4
- https://git.kernel.org/stable/c/4a657319cfabd6199fd0b7b65bbebf6ded7a11c1
- https://git.kernel.org/stable/c/533c60a0b97cee5daab376933f486207e6680fb7
- https://git.kernel.org/stable/c/947264e00c46de19a016fd81218118c708fed2f3
- https://git.kernel.org/stable/c/bb420e8afc854d2a1caaa23a0c129839acfb7888
- https://git.kernel.org/stable/c/dc451578446afd03c0c21913993c08898a691435
- https://git.kernel.org/stable/c/f34ab95162763cd7352f46df169296eec28b688d
- https://git.kernel.org/stable/c/f4b5ff0b794aa94afac7269c494550ca2f66511b
- https://git.kernel.org/stable/c/f9c1f248607d5546075d3f731e7607d5571f2b60
Modified: 2026-01-14
CVE-2022-50348
In the Linux kernel, the following vulnerability has been resolved: nfsd: Fix a memory leak in an error handling path If this memdup_user() call fails, the memory allocated in a previous call a few lines above should be freed. Otherwise it leaks.
- https://git.kernel.org/stable/c/733dd17158f96aaa25408dc39bbb2738fda9300e
- https://git.kernel.org/stable/c/acc393aecda05bf64ed13b732931462e07a1bf08
- https://git.kernel.org/stable/c/aed8816305575b38dcc77feb6f1bc1d0ed32f5b8
- https://git.kernel.org/stable/c/cc3bca2110ac85cd964da997ef83d84cab0d49fb
- https://git.kernel.org/stable/c/e060c4b9f33c1fca74df26d57a98e784295327e6
- https://git.kernel.org/stable/c/fd1ef88049de09bc70d60b549992524cfc0e66ff
Modified: 2026-01-14
CVE-2022-50351
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix xid leak in cifs_create() If the cifs already shutdown, we should free the xid before return, otherwise, the xid will be leaked.
Modified: 2026-01-14
CVE-2022-50352
In the Linux kernel, the following vulnerability has been resolved: net: hns: fix possible memory leak in hnae_ae_register() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
- https://git.kernel.org/stable/c/02dc0db19d944b4a90941db505ecf1aaec714be4
- https://git.kernel.org/stable/c/2974f3b330ef25f5d34a4948d04290c2cd7802cf
- https://git.kernel.org/stable/c/3b78453cca046d3b03853f0d077ad3ad130db886
- https://git.kernel.org/stable/c/7ae1345f6ad715acbcdc9e1ac28153684fd498bb
- https://git.kernel.org/stable/c/91f8f5342bee726ed5692583d58f69e7cc9ae60e
- https://git.kernel.org/stable/c/a3c148955c22fe1d94d7a2096005679c1f22eddf
- https://git.kernel.org/stable/c/dfc0337c6dceb6449403b33ecb141f4a1458a1e9
- https://git.kernel.org/stable/c/ff2f5ec5d009844ec28f171123f9e58750cef4bf
Modified: 2026-01-14
CVE-2022-50355
In the Linux kernel, the following vulnerability has been resolved: staging: vt6655: fix some erroneous memory clean-up loops In some initialization functions of this driver, memory is allocated with 'i' acting as an index variable and increasing from 0. The commit in "Fixes" introduces some clean-up codes in case of allocation failure, which free memory in reverse order with 'i' decreasing to 0. However, there are some problems: - The case i=0 is left out. Thus memory is leaked. - In case memory allocation fails right from the start, the memory freeing loops will start with i=-1 and invalid memory locations will be accessed. One of these loops has been fixed in commit c8ff91535880 ("staging: vt6655: fix potential memory leak"). Fix the remaining erroneous loops.
- https://git.kernel.org/stable/c/2a2db520e3ca5aafba7c211abfd397666c9b5f9d
- https://git.kernel.org/stable/c/637672a71f5016a40b0a6c0f3c8ad25eacedc8c3
- https://git.kernel.org/stable/c/88b9cc60f26e8a05d1ddbddf91b09ca2915f20e0
- https://git.kernel.org/stable/c/95ac62e8545be2b0a8cae0beef7c682e2e470e48
- https://git.kernel.org/stable/c/a9e9806d1c315bc50dce05479a079b9a104474b8
- https://git.kernel.org/stable/c/ed11b73c963292e7b49c0f37025c58ed3b7921d6
- https://git.kernel.org/stable/c/f19e5b7df54590c831f350381963f25585c8f7d5
Modified: 2026-01-14
CVE-2022-50356
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sfb: fix null pointer access issue when sfb_init() fails
When the default qdisc is sfb, if the qdisc of dev_queue fails to be
inited during mqprio_init(), sfb_reset() is invoked to clear resources.
In this case, the q->qdisc is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
sfb_init()
tcf_block_get() --->failed, q->qdisc is NULL
...
qdisc_put()
...
sfb_reset()
qdisc_reset(q->qdisc) --->q->qdisc is NULL
ops = qdisc->ops
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:qdisc_reset+0x2b/0x6f0
Call Trace:
Modified: 2026-01-14
CVE-2022-50357
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: fix some leaks in probe The dwc3_get_properties() function calls: dwc->usb_psy = power_supply_get_by_name(usb_psy_name); so there is some additional clean up required on these error paths.
Modified: 2026-01-14
CVE-2022-50359
In the Linux kernel, the following vulnerability has been resolved: media: cx88: Fix a null-ptr-deref bug in buffer_prepare() When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue(). The following log can reveal it: [ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516] __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0 Fix this by checking the return value of cx88_risc_buffer() [hverkuil: fix coding style issues]
- https://git.kernel.org/stable/c/10c99d1c46ea9cd940029e17bab11d021f315c21
- https://git.kernel.org/stable/c/2b064d91440b33fba5b452f2d1b31f13ae911d71
- https://git.kernel.org/stable/c/4befc7ffa18ef9a4b70d854465313a345a06862f
- https://git.kernel.org/stable/c/644d5a87ab1863eb606526ea743021752a17e9cb
- https://git.kernel.org/stable/c/6f21976095c1e92454ab030976f95f40d652351b
- https://git.kernel.org/stable/c/704838040f3bdb4aa07ff4f26505a666a3defcfe
- https://git.kernel.org/stable/c/9181af2dbf06e7f432e5dbe88d10b22343e851b9
- https://git.kernel.org/stable/c/c2257c8a501537afab276c306cb717b7260276e1
- https://git.kernel.org/stable/c/c76d04d2079a4b7369ce9a0e859c0f3f2250bcc1
Modified: 2026-01-14
CVE-2022-50360
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix aux-bus EP lifetime Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP aux-bus, an attempt to populate the bus a second time will simply fail ("DP AUX EP device already populated"). Fix this by tying the lifetime of the EP device to the DRM device rather than DP controller platform device. Patchwork: https://patchwork.freedesktop.org/patch/502672/
Modified: 2026-01-14
CVE-2022-50362
In the Linux kernel, the following vulnerability has been resolved: dmaengine: hisilicon: Add multi-thread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103] ESR = 0x96000044 [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107] SET = 0, FnV = 0 [383493.335108] EA = 0, S1PTW = 0 [383493.335109] FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111] ISV = 0, ISS = 0x00000044 [383493.364739] CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0 This occurs because the transmission timed out, and that's due to data race. Each thread rewrite channels's descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels's descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That's why timeout reports. With current fixes channels' descriptor changes it's value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel's descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing.
- https://git.kernel.org/stable/c/2cbb95883c990d0002a77e13d3278913ab26ad79
- https://git.kernel.org/stable/c/7cb9b20941e1fb20d22d0a2f460a3d4fa417274c
- https://git.kernel.org/stable/c/af12e209a9d559394d35875ba0e6c80407605888
- https://git.kernel.org/stable/c/d4a8ec5cc7ff5d442bd49a44f26d74b2021ba4c8
- https://git.kernel.org/stable/c/f4cee0b385cd0348e071d4d80c4c13cfe547c70d
Modified: 2026-01-14
CVE-2022-50363
In the Linux kernel, the following vulnerability has been resolved:
skmsg: pass gfp argument to alloc_sk_msg()
syzbot found that alloc_sk_msg() could be called from a
non sleepable context. sk_psock_verdict_recv() uses
rcu_read_lock() protection.
We need the callers to pass a gfp_t argument to avoid issues.
syzbot report was:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
INFO: lockdep is turned off.
CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
Modified: 2026-01-14
CVE-2022-50366
In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds: shift exponent 18446744073709551615 is too large for 32-bit type 'int' Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us
- https://git.kernel.org/stable/c/139bbbd01114433b80fe59f5e1330615aadf9752
- https://git.kernel.org/stable/c/1d94af37565e4d3c26b0d63428e093a37d5b4c32
- https://git.kernel.org/stable/c/2d93540014387d1c73b9ccc4d7895320df66d01b
- https://git.kernel.org/stable/c/3eb0ba70376f6ee40fa843fc9cee49269370b0b3
- https://git.kernel.org/stable/c/42f79dbb9514f726ff21df25f09cb0693b0b2445
- https://git.kernel.org/stable/c/49a6ffdaed60f0eb52c198fafebc05994e16e305
- https://git.kernel.org/stable/c/4ebba43384722adbd325baec3a12c572d94488eb
- https://git.kernel.org/stable/c/6216b685b8f48ab7b721a6fd5acbf526b41c13e8
- https://git.kernel.org/stable/c/708b9abe1b4a2f050a483db4b7edfc446b13df1f
Modified: 2026-01-14
CVE-2022-50368
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502668/
- https://git.kernel.org/stable/c/21c4679af01f1027cb559330c2e7d410089b2b36
- https://git.kernel.org/stable/c/2e786eb2f9cebb07e317226b60054df510b60c65
- https://git.kernel.org/stable/c/4e5587cddb334f7a5bb1c49ea8bbfc966fafe1b8
- https://git.kernel.org/stable/c/9f035d1fb30648fe70ee01627eb131c56d699b35
- https://git.kernel.org/stable/c/e83b354890a3c1d5256162f87a6cc38c47ae7f20
- https://git.kernel.org/stable/c/f649ed0e1b7a1545f8e27267d3c468b3cb222ece
Modified: 2026-01-14
CVE-2022-50370
In the Linux kernel, the following vulnerability has been resolved: i2c: designware: Fix handling of real but unexpected device interrupts Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep"). I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes: - Issue happens when resuming from S3 but not when resuming from "s2idle" - PCI device 00:15.0 == i2c_designware.0 is already in D0 state when system enters into pci_pm_resume_noirq() while all other i2c_designware PCI devices are in D3. Devices were runtime suspended and in D3 prior entering into suspend - Interrupt comes after pci_pm_resume_noirq() when device interrupts are re-enabled - According to register dump the interrupt really comes from the i2c_designware.0. Controller is enabled, I2C target address register points to a one detectable I2C device address 0x60 and the DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and TX_EMPTY bits are set indicating completed I2C transaction. My guess is that the firmware uses this controller to communicate with an on-board I2C device during resume but does not disable the controller before giving control to an operating system. I was told the UEFI update fixes this but never the less it revealed the driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device is supposed to be idle and state variables are not set (especially the dev->msgs pointer which may point to NULL or stale old data). Introduce a new software status flag STATUS_ACTIVE indicating when the controller is active in driver point of view. Now treat all interrupts that occur when is not set as unexpected and mask all interrupts from the controller.
Modified: 2026-01-14
CVE-2022-50372
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory leak when build ntlmssp negotiate blob failed There is a memory leak when mount cifs: unreferenced object 0xffff888166059600 (size 448): comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s) hex dump (first 32 bytes): fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000060609a61>] mempool_alloc+0xe1/0x260 [<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60 [<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460 [<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0 [<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480 [<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410 [<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0 [<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0 [<000000006cbc43d9>] mount_get_conns+0x7a/0x730 [<000000005922d816>] cifs_mount+0x103/0xd10 [<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90 [<0000000078034979>] smb3_get_tree+0x1d5/0x300 [<000000004371f980>] vfs_get_tree+0x41/0xf0 [<00000000b670d8a7>] path_mount+0x9b3/0xdd0 [<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0 [<000000009404c3b9>] do_syscall_64+0x35/0x80 When build ntlmssp negotiate blob failed, the session setup request should be freed.
Modified: 2026-01-14
CVE-2022-50373
In the Linux kernel, the following vulnerability has been resolved:
fs: dlm: fix race in lowcomms
This patch fixes a race between queue_work() in
_dlm_lowcomms_commit_msg() and srcu_read_unlock(). The queue_work() can
take the final reference of a dlm_msg and so msg->idx can contain
garbage which is signaled by the following warning:
[ 676.237050] ------------[ cut here ]------------
[ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50
[ 676.238945] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr
[ 676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19.0-rc3+ #1546
[ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014
[ 676.246460] RIP: 0010:dlm_lowcomms_commit_msg+0x41/0x50
[ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48
[ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282
[ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006
[ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e
[ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001
[ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005
[ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480
[ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000
[ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0
[ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 676.258397] PKRU: 55555554
[ 676.258729] Call Trace:
[ 676.259063]
Modified: 2026-01-14
CVE-2022-50374
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1], for rcu_sync_enter() is called without rcu_sync_init() due to hci_uart_tty_open() ignoring percpu_init_rwsem() failure. While we are at it, fix that hci_uart_register_device() ignores percpu_init_rwsem() failure and hci_uart_unregister_device() does not call percpu_free_rwsem().
- https://git.kernel.org/stable/c/3124d320c22f3f4388d9ac5c8f37eaad0cefd6b1
- https://git.kernel.org/stable/c/75b2c71ea581c7bb1303860d89366a42ad0506d2
- https://git.kernel.org/stable/c/98ce10f3f345e61fc6c83bff9cd11cda252b05ac
- https://git.kernel.org/stable/c/b8917dce2134739b39bc0a5648b18427f2cad569
- https://git.kernel.org/stable/c/d7cc0d51ffcbfd1caaa809fcf9cff05c46d0fb4d
Modified: 2026-01-14
CVE-2022-50375
In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can still occur which in turn tries to access dma apis if lpuart_dma_tx_use flag is true. At this point since dma is torn down, these dma apis can abort. Set lpuart_dma_tx_use and the corresponding rx flag lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not accessed after they are relinquished. Otherwise, when try to kill btattach, kernel may panic. This patch may fix this issue. root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200 ^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 90.189806] Modules linked in: moal(O) mlan(O) [ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37 [ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT) [ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60 [ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c [ 90.225237] sp : ffff800013f0bac0 [ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800 [ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00 [ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000 [ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000 [ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040 [ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090 [ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804 [ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480 [ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800 [ 90.299876] Call trace: [ 90.302321] fsl_edma3_disable_request+0x8/0x60 [ 90.306851] lpuart_flush_buffer+0x40/0x160 [ 90.311037] uart_flush_buffer+0x88/0x120 [ 90.315050] tty_driver_flush_buffer+0x20/0x30 [ 90.319496] hci_uart_flush+0x44/0x90 [ 90.323162] +0x34/0x12c [ 90.327253] tty_ldisc_close+0x38/0x70 [ 90.331005] tty_ldisc_release+0xa8/0x190 [ 90.335018] tty_release_struct+0x24/0x8c [ 90.339022] tty_release+0x3ec/0x4c0 [ 90.342593] __fput+0x70/0x234 [ 90.345652] ____fput+0x14/0x20 [ 90.348790] task_work_run+0x84/0x17c [ 90.352455] do_exit+0x310/0x96c [ 90.355688] do_group_exit+0x3c/0xa0 [ 90.359259] __arm64_sys_exit_group+0x1c/0x20 [ 90.363609] invoke_syscall+0x48/0x114 [ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc [ 90.372068] do_el0_svc+0x2c/0x94 [ 90.375379] el0_svc+0x28/0x80 [ 90.378438] el0t_64_sync_handler+0xa8/0x130 [ 90.382711] el0t_64_sync+0x1a0/0x1a4 [ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041) [ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]--- [ 90.397073] note: btattach[503] exited with preempt_count 1 [ 90.402636] Fixing recursive fault but reboot is needed!
- https://git.kernel.org/stable/c/29b897ac7b990882c74bd08605692214e7e58b83
- https://git.kernel.org/stable/c/316ae95c175a7d770d1bfe4c011192712f57aa4a
- https://git.kernel.org/stable/c/3953e7f261e2f4d9c35f0c025df9f166f46aa626
- https://git.kernel.org/stable/c/9a56ade124d4891a31ab1300c57665f07f5b24d5
- https://git.kernel.org/stable/c/c4293def8860fd587a84400ccba5b49cec56e2c3
- https://git.kernel.org/stable/c/d554c14eb73ee91d76fc9aece4616f0b687c295d
Modified: 2026-01-14
CVE-2022-50378
In the Linux kernel, the following vulnerability has been resolved: drm/meson: reorder driver deinit sequence to fix use-after-free bug Unloading the driver triggers the following KASAN warning: [ +0.006275] ============================================================= [ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0 [ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695 [ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000007] dump_backtrace+0x1ec/0x280 [ +0.000013] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000010] __list_del_entry_valid+0xe0/0x1a0 [ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm] [ +0.000172] drm_bridge_detach+0x94/0x260 [drm] [ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm] [ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm] [ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm] [ +0.000144] drm_managed_release+0x170/0x414 [drm] [ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm] [ +0.000143] drm_dev_put+0x20/0x30 [drm] [ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm] [ +0.000028] take_down_aggregate_device+0xb0/0x160 [ +0.000016] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000015] platform_remove+0x64/0xb0 [ +0.000009] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000009] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000011] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000018] Allocated by task 0: [ +0.000007] (stack is not available) [ +0.000011] Freed by task 2695: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] component_unbind+0x128/0x1e0 [ +0.000010] component_unbind_all+0x1b8/0x264 [ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm] [ +0.000025] take_down_aggregate_device+0xb0/0x160 [ +0.000009] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000012] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000011] __do_sys_delete_module+0x288/0x400 [ +0.000010] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] The buggy address belongs to the object at ffff000020c39000 ---truncated---
Modified: 2026-01-14
CVE-2022-50379
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between quota enable and quota rescan ioctl When enabling quotas, at btrfs_quota_enable(), after committing the transaction, we change fs_info->quota_root to point to the quota root we created and set BTRFS_FS_QUOTA_ENABLED at fs_info->flags. Then we try to start the qgroup rescan worker, first by initializing it with a call to qgroup_rescan_init() - however if that fails we end up freeing the quota root but we leave fs_info->quota_root still pointing to it, this can later result in a use-after-free somewhere else. We have previously set the flags BTRFS_FS_QUOTA_ENABLED and BTRFS_QGROUP_STATUS_FLAG_ON, so we can only fail with -EINPROGRESS at btrfs_quota_enable(), which is possible if someone already called the quota rescan ioctl, and therefore started the rescan worker. So fix this by ignoring an -EINPROGRESS and asserting we can't get any other error.
- https://git.kernel.org/stable/c/0efd9dfc00d677a1d0929319a6103cb2dfc41c22
- https://git.kernel.org/stable/c/26b7c0ac49a3eea15559c9d84863736a6d1164b4
- https://git.kernel.org/stable/c/331cd9461412e103d07595a10289de90004ac890
- https://git.kernel.org/stable/c/47b5ffe86332af95f0f52be0a63d4da7c2b37b55
- https://git.kernel.org/stable/c/4b996a3014ef014af8f97b60c35f5289210a4720
- https://git.kernel.org/stable/c/6c22f86dd221eba0c7af645b1af73dcbc04ee27b
- https://git.kernel.org/stable/c/c97f6d528c3f1c83a6b792a8a7928c236c80b8fe
Modified: 2026-01-14
CVE-2022-50380
In the Linux kernel, the following vulnerability has been resolved: mm: /proc/pid/smaps_rollup: fix no vma's null-deref Commit 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value seq_file") introduced a null-deref if there are no vma's in the task in show_smaps_rollup.
- https://git.kernel.org/stable/c/33fc9e26b7cb39f0d4219c875a2451802249c225
- https://git.kernel.org/stable/c/6bb8769326c46db3058780c0640dcc49d8187b24
- https://git.kernel.org/stable/c/97898139ca9b81ba9322a585e07490983c53b55a
- https://git.kernel.org/stable/c/a50ed2d28727ff605d95fb9a53be8ff94e8eaaf4
- https://git.kernel.org/stable/c/c4c84f06285e48f80e9843d0775ad92714ffc35a
- https://git.kernel.org/stable/c/dbe863bce7679c7f5ec0e993d834fe16c5e687b5
Modified: 2026-01-14
CVE-2022-50386
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix user-after-free This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
- https://git.kernel.org/stable/c/0c108cf3ad386e0084277093b55a351c49e0be27
- https://git.kernel.org/stable/c/11e40d6c0823f699d8ad501e48d1c3ae4be386cd
- https://git.kernel.org/stable/c/15fc21695eb606bdc5d483b92118ee42610a952d
- https://git.kernel.org/stable/c/35fcbc4243aad7e7d020b7c1dfb14bb888b20a4f
- https://git.kernel.org/stable/c/6ffde6e03085874ae22263ff4cef4869f797e84f
- https://git.kernel.org/stable/c/7d6f9cb24d2b2f6b6370eac074e2e6b1bafdad45
- https://git.kernel.org/stable/c/843fc4e386dd84b806a7f07fb062d8c3a44e5364
- https://git.kernel.org/stable/c/d1e894f950ad48897d1a7cb05909ea29d8c3810e
- https://git.kernel.org/stable/c/d91fc2836562f299f34e361e089e9fe154da4f73
Modified: 2026-01-14
CVE-2022-50387
In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix the issue of CMDQ memory leaks When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is not released correctly. Fix it.
Modified: 2026-01-14
CVE-2022-50393
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: SDMA update use unlocked iterator SDMA update page table may be called from unlocked context, this generate below warning. Use unlocked iterator to handle this case. WARNING: CPU: 0 PID: 1475 at drivers/dma-buf/dma-resv.c:483 dma_resv_iter_next Call Trace: dma_resv_iter_first+0x43/0xa0 amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu] amdgpu_vm_ptes_update+0x29c/0x870 [amdgpu] amdgpu_vm_update_range+0x2f6/0x6c0 [amdgpu] svm_range_unmap_from_gpus+0x115/0x300 [amdgpu] svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu] __mmu_notifier_invalidate_range_start+0x1d3/0x230 unmap_vmas+0x140/0x150 unmap_region+0xa8/0x110
Modified: 2026-01-14
CVE-2022-50398
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: add atomic_check to bridge ops DRM commit_tails() will disable downstream crtc/encoder/bridge if both disable crtc is required and crtc->active is set before pushing a new frame downstream. There is a rare case that user space display manager issue an extra screen update immediately followed by close DRM device while down stream display interface is disabled. This extra screen update will timeout due to the downstream interface is disabled but will cause crtc->active be set. Hence the followed commit_tails() called by drm_release() will pass the disable downstream crtc/encoder/bridge conditions checking even downstream interface is disabled. This cause the crash to happen at dp_bridge_disable() due to it trying to access the main link register to push the idle pattern out while main link clocks is disabled. This patch adds atomic_check to prevent the extra frame will not be pushed down if display interface is down so that crtc->active will not be set neither. This will fail the conditions checking of disabling down stream crtc/encoder/bridge which prevent drm_release() from calling dp_bridge_disable() so that crash at dp_bridge_disable() prevented. There is no protection in the DRM framework to check if the display pipeline has been already disabled before trying again. The only check is the crtc_state->active but this is controlled by usermode using UAPI. Hence if the usermode sets this and then crashes, the driver needs to protect against double disable. SError Interrupt on CPU7, code 0x00000000be000411 -- SError CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __cmpxchg_case_acq_32+0x14/0x2c lr : do_raw_spin_lock+0xa4/0xdc sp : ffffffc01092b6a0 x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038 x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000 x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008 x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000 x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0 x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4 x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001 x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0 x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) Call trace: dump_backtrace.part.0+0xbc/0xe4 show_stack+0x24/0x70 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 panic+0x14c/0x32c nmi_panic+0x58/0x7c arm64_serror_panic+0x78/0x84 do_serror+0x40/0x64 el1h_64_error_handler+0x30/0x48 el1h_64_error+0x68/0x6c __cmpxchg_case_acq_32+0x14/0x2c _raw_spin_lock_irqsave+0x38/0x4c lock_timer_base+0x40/0x78 __mod_timer+0xf4/0x25c schedule_timeout+0xd4/0xfc __wait_for_common+0xac/0x140 wait_for_completion_timeout+0x2c/0x54 dp_ctrl_push_idle+0x40/0x88 dp_bridge_disable+0x24/0x30 drm_atomic_bridge_chain_disable+0x90/0xbc drm_atomic_helper_commit_modeset_disables+0x198/0x444 msm_atomic_commit_tail+0x1d0/0x374 commit_tail+0x80/0x108 drm_atomic_helper_commit+0x118/0x11c drm_atomic_commit+0xb4/0xe0 drm_client_modeset_commit_atomic+0x184/0x224 drm_client_modeset_commit_locked+0x58/0x160 drm_client_modeset_commit+0x3c/0x64 __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac drm_fb_helper_set_par+0x74/0x80 drm_fb_helper_hotplug_event+0xdc/0xe0 __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c drm_fb_helper_lastclose+0x20/0x2c drm_lastclose+0x44/0x6c drm_release+0x88/0xd4 __fput+0x104/0x220 ____fput+0x1c/0x28 task_work_run+0x8c/0x100 d ---truncated---
Modified: 2026-01-14
CVE-2022-50399
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: prevent integer overflow in sh_css_set_black_frame() The "height" and "width" values come from the user so the "height * width" multiplication can overflow.
Modified: 2026-01-14
CVE-2022-50400
In the Linux kernel, the following vulnerability has been resolved: staging: greybus: audio_helper: remove unused and wrong debugfs usage In the greybus audio_helper code, the debugfs file for the dapm has the potential to be removed and memory will be leaked. There is also the very real potential for this code to remove ALL debugfs entries from the system, and it seems like this is what will really happen if this code ever runs. This all is very wrong as the greybus audio driver did not create this debugfs file, the sound core did and controls the lifespan of it. So remove all of the debugfs logic from the audio_helper code as there's no way it could be correct. If this really is needed, it can come back with a fixup for the incorrect usage of the debugfs_lookup() call which is what caused this to be noticed at all.
- https://git.kernel.org/stable/c/4dab0d27a4211a27135a6899d6c737e6e0759a11
- https://git.kernel.org/stable/c/5699afbff1fa2972722e863906c0320d55dd4d58
- https://git.kernel.org/stable/c/d0febad83e29d85bb66e4f5cac0115b022403338
- https://git.kernel.org/stable/c/d517cdeb904ddc0cbebcc959d43596426cac40b0
- https://git.kernel.org/stable/c/d835fa49d9589a780ff0d001bb7e6323238a4afb
Modified: 2026-01-14
CVE-2022-50406
In the Linux kernel, the following vulnerability has been resolved: iomap: iomap: fix memory corruption when recording errors during writeback Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---
Modified: 2026-01-14
CVE-2022-50408
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit() > ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb); may be schedule, and then complete before the line > ndev->stats.tx_bytes += skb->len; [ 46.912801] ================================================================== [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328 [ 46.935991] [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1 [ 46.947255] Hardware name: [REDACTED] [ 46.954568] Call trace: [ 46.957037] dump_backtrace+0x0/0x2b8 [ 46.960719] show_stack+0x24/0x30 [ 46.964052] dump_stack+0x128/0x194 [ 46.967557] print_address_description.isra.0+0x64/0x380 [ 46.972877] __kasan_report+0x1d4/0x240 [ 46.976723] kasan_report+0xc/0x18 [ 46.980138] __asan_report_load4_noabort+0x18/0x20 [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0 [ 46.994894] sch_direct_xmit+0x198/0xd08 [ 46.998827] __qdisc_run+0x37c/0x1dc0 [ 47.002500] __dev_queue_xmit+0x1528/0x21f8 [ 47.006692] dev_queue_xmit+0x24/0x30 [ 47.010366] neigh_resolve_output+0x37c/0x678 [ 47.014734] ip_finish_output2+0x598/0x2458 [ 47.018927] __ip_finish_output+0x300/0x730 [ 47.023118] ip_output+0x2e0/0x430 [ 47.026530] ip_local_out+0x90/0x140 [ 47.030117] igmpv3_sendpack+0x14c/0x228 [ 47.034049] igmpv3_send_cr+0x384/0x6b8 [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118 [ 47.042262] call_timer_fn+0x1cc/0xbe8 [ 47.046021] __run_timers+0x4d8/0xb28 [ 47.049693] run_timer_softirq+0x24/0x40 [ 47.053626] __do_softirq+0x2c0/0x117c [ 47.057387] irq_exit+0x2dc/0x388 [ 47.060715] __handle_domain_irq+0xb4/0x158 [ 47.064908] gic_handle_irq+0x58/0xb0 [ 47.068581] el0_irq_naked+0x50/0x5c [ 47.072162] [ 47.073665] Allocated by task 328: [ 47.077083] save_stack+0x24/0xb0 [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0 [ 47.084776] kasan_slab_alloc+0x14/0x20 [ 47.088622] kmem_cache_alloc+0x15c/0x468 [ 47.092643] __alloc_skb+0xa4/0x498 [ 47.096142] igmpv3_newpack+0x158/0xd78 [ 47.099987] add_grhead+0x210/0x288 [ 47.103485] add_grec+0x6b0/0xb70 [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8 [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118 [ 47.115027] call_timer_fn+0x1cc/0xbe8 [ 47.118785] __run_timers+0x4d8/0xb28 [ 47.122457] run_timer_softirq+0x24/0x40 [ 47.126389] __do_softirq+0x2c0/0x117c [ 47.130142] [ 47.131643] Freed by task 180: [ 47.134712] save_stack+0x24/0xb0 [ 47.138041] __kasan_slab_free+0x108/0x180 [ 47.142146] kasan_slab_free+0x10/0x18 [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0 [ 47.150444] kmem_cache_free+0x8c/0x528 [ 47.154292] kfree_skbmem+0x94/0x108 [ 47.157880] consume_skb+0x10c/0x5a8 [ 47.161466] __dev_kfree_skb_any+0x88/0xa0 [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil] [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac] [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac] [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac] [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac] [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac] [ 47.197859] process_one_work+0x7fc/0x1a80 [ 47.201965] worker_thread+0x31c/0xc40 [ 47.205726] kthread+0x2d8/0x370 [ 47.208967] ret_from_fork+0x10/0x18 [ 47.212546] [ 47.214051] The buggy address belongs to the object at ffffff803f588280 [ 47.214051] which belongs to the cache skbuff_head_cache of size 208 [ 47.227086] The buggy address is located 104 bytes inside of [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350) [ 47.238814] The buggy address belongs to the page: [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou ---truncated---
- https://git.kernel.org/stable/c/1613a7b24f1a7467cb727ba3ec77c9a808383560
- https://git.kernel.org/stable/c/232d59eca07f6ea27307022a33d226aff373bd02
- https://git.kernel.org/stable/c/27574a3f421c3a1694d0207f37c6bbf23d66978e
- https://git.kernel.org/stable/c/3f42faf6db431e04bf942d2ebe3ae88975723478
- https://git.kernel.org/stable/c/49c742afd60f552fce7799287080db02bffe1db2
- https://git.kernel.org/stable/c/c369836cff98d3877f98c98e15c0151462812d96
- https://git.kernel.org/stable/c/d79f4d903e14dde822c60b5fd3bedc5a289d25df
- https://git.kernel.org/stable/c/e01d96494a9de0f48b1167f0494f6d929fa773ed
Modified: 2025-12-23
CVE-2022-50409
In the Linux kernel, the following vulnerability has been resolved:
net: If sock is dead don't access sock's sk_wq in sk_stream_wait_memory
Fixes the below NULL pointer dereference:
[...]
[ 14.471200] Call Trace:
[ 14.471562]
- https://git.kernel.org/stable/c/124b7c773271f06af5a2cea694b283cdb5275cf5
- https://git.kernel.org/stable/c/35f5e70bdfa7432762ac4ffa75e5a7574ac5563e
- https://git.kernel.org/stable/c/3f8ef65af927db247418d4e1db49164d7a158fc5
- https://git.kernel.org/stable/c/435f5aa4421782af197b98d8525263977be4af5c
- https://git.kernel.org/stable/c/65029aaedd15d9fe5ea1a899134e236d83f627bb
- https://git.kernel.org/stable/c/a76462dbdd8bddcbeec9463bc9e54e509b860762
Modified: 2026-01-14
CVE-2022-50410
In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer overflow in NFSv2 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case.
- https://git.kernel.org/stable/c/1868332032eccbab8c1878a0d918193058c0a905
- https://git.kernel.org/stable/c/2007867c5874134f2271eb276398208070049dd3
- https://git.kernel.org/stable/c/2be9331ca6061bc6ea32247266f45b8b21030244
- https://git.kernel.org/stable/c/401bc1f90874280a80b93f23be33a0e7e2d1f912
- https://git.kernel.org/stable/c/ea4c3eee0fd72fcedaa238556044825639cd3607
Modified: 2026-01-14
CVE-2022-50412
In the Linux kernel, the following vulnerability has been resolved: drm: bridge: adv7511: unregister cec i2c device after cec adapter cec_unregister_adapter() assumes that the underlying adapter ops are callable. For example, if the CEC adapter currently has a valid physical address, then the unregistration procedure will invalidate the physical address by setting it to f.f.f.f. Whence the following kernel oops observed after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511] cec_adap_unconfigure+0x44/0x90 [cec] __cec_s_phys_addr.part.0+0x68/0x230 [cec] __cec_s_phys_addr+0x40/0x50 [cec] cec_unregister_adapter+0xb4/0x118 [cec] adv7511_remove+0x60/0x90 [adv7511] i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value ---[ end trace 0000000000000000 ]--- Protect against this scenario by unregistering i2c_cec after unregistering the CEC adapter. Duly disable the CEC clock afterwards too.
- https://git.kernel.org/stable/c/3747465c5da7a11957a34bbb9485d9fc253b91cc
- https://git.kernel.org/stable/c/40cdb02cb9f965732eb543d47f15bef8d10f0f5f
- https://git.kernel.org/stable/c/4d4d5bc659206b187263190ad9a03513f625659d
- https://git.kernel.org/stable/c/86ae5170786aea3e1751123ca55700fb9b37b623
- https://git.kernel.org/stable/c/f369fb4deed7ab997cfa703dc85ec08b3adc1af8
Modified: 2026-01-14
CVE-2022-50413
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free We've already freed the assoc_data at this point, so need to use another copy of the AP (MLD) address instead.
Modified: 2026-01-14
CVE-2022-50418
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register() mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets some error, mhi_ctrl should be freed with mhi_free_controller(). But when ath11k_mhi_read_addr_from_dt() fails, the function returns without calling mhi_free_controller(), which will lead to a memory leak. We can fix it by calling mhi_free_controller() when ath11k_mhi_read_addr_from_dt() fails.
Modified: 2026-01-14
CVE-2022-50419
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times
device_add shall not be called multiple times as stated in its
documentation:
'Do not call this routine or device_register() more than once for
any device structure'
Syzkaller reports a bug as follows [1]:
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:33!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[...]
Call Trace:
- https://git.kernel.org/stable/c/1b6c89571f453101251201f0fad1c26f7256e937
- https://git.kernel.org/stable/c/3423a50fa018e88aed4c900d59c3c8334d8ad583
- https://git.kernel.org/stable/c/448a496f760664d3e2e79466aa1787e6abc922b5
- https://git.kernel.org/stable/c/4bcefec3636208b4c97536b26014d5935d5c10a0
- https://git.kernel.org/stable/c/6144423712d570247b8ca26e50a277c30dd13702
- https://git.kernel.org/stable/c/671fee73e08ff415d36a7c16bdf238927df83884
- https://git.kernel.org/stable/c/6e85d2ad958c6f034b1b158d904019869dbb3c81
- https://git.kernel.org/stable/c/7b674dce4162bb46d396586e30e4653427023875
- https://git.kernel.org/stable/c/ef055094df4c10b73cfe67c8d43f9de1fb608a8b
Modified: 2026-01-14
CVE-2022-50421
In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Avoid double destroy of default endpoint The rpmsg_dev_remove() in rpmsg_core is the place for releasing this default endpoint. So need to avoid destroying the default endpoint in rpmsg_chrdev_eptdev_destroy(), this should be the same as rpmsg_eptdev_release(). Otherwise there will be double destroy issue that ept->refcount report warning: refcount_t: underflow; use-after-free. Call trace: refcount_warn_saturate+0xf8/0x150 virtio_rpmsg_destroy_ept+0xd4/0xec rpmsg_dev_remove+0x60/0x70 The issue can be reproduced by stopping remoteproc before closing the /dev/rpmsgX.
Modified: 2026-01-14
CVE-2022-50422
In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix use-after-free bug in smp_execute_task_sg() When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete "slow_task->timer". However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below: (thread 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the "task->slow_task" is deallocated.
- https://git.kernel.org/stable/c/117331a2a5227fb4369c2a1f321d3e3e2e2ef8fe
- https://git.kernel.org/stable/c/2e12ce270f0d926085c1209cc90397e307deef97
- https://git.kernel.org/stable/c/46ba53c30666717cb06c2b3c5d896301cd00d0c0
- https://git.kernel.org/stable/c/a9e5176ead6de64f572ad5c87a72825d9d3c82ae
- https://git.kernel.org/stable/c/e45a1516d2933703a4823d9db71e17c3abeba24f
- https://git.kernel.org/stable/c/f7a785177611ffc97d645fcbc196e6de6ad2421d
Modified: 2026-01-20
CVE-2022-50425
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly When an extended state component is not present in fpstate, but in init state, the function copies from init_fpstate via copy_feature(). But, dynamic states are not present in init_fpstate because of all-zeros init states. Then retrieving them from init_fpstate will explode like this: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:memcpy_erms+0x6/0x10 ? __copy_xstate_to_uabi_buf+0x381/0x870 fpu_copy_guest_fpstate_to_uabi+0x28/0x80 kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm] ? __this_cpu_preempt_check+0x13/0x20 ? vmx_vcpu_put+0x2e/0x260 [kvm_intel] kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? __fget_light+0xd4/0x130 __x64_sys_ioctl+0xe3/0x910 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x27/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Adjust the 'mask' to zero out the userspace buffer for the features that are not available both from fpstate and from init_fpstate. The dynamic features depend on the compacted XSAVE format. Ensure it is enabled before reading XCOMP_BV in init_fpstate.
Modified: 2026-01-20
CVE-2022-50427
In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix possible memory leak in snd_ac97_dev_register() If device_register() fails in snd_ac97_dev_register(), it should call put_device() to give up reference, or the name allocated in dev_set_name() is leaked.
- https://git.kernel.org/stable/c/0f8e9a15c8ecf95057061d370a2dddaf1cee4aeb
- https://git.kernel.org/stable/c/4881bda5ea05c8c240fc8afeaa928e2bc43f61fa
- https://git.kernel.org/stable/c/4fdf6f978c6b605ca0d67bf0e982b7a8fc0f4aab
- https://git.kernel.org/stable/c/758dbcc6fbf2286eff02743b093c70a18a407d66
- https://git.kernel.org/stable/c/a602ec9d88f177dba78bc97fb1adecc7a71ff279
- https://git.kernel.org/stable/c/bfce73088682ef0770da951f51156c36a89be490
- https://git.kernel.org/stable/c/c68b2e9ef246117f696e360bbdd2f5736b3a7127
- https://git.kernel.org/stable/c/ee8bf0946f62ef00e5db4b613a9f664ac567259a
Modified: 2026-01-21
CVE-2022-50429
In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount.
- https://git.kernel.org/stable/c/1d312c12c91f831fcc48623c921f2d4560edb159
- https://git.kernel.org/stable/c/3b321bf7687968a090cf6b62bd8e67d692f59a16
- https://git.kernel.org/stable/c/48af14fb0eaa63d9aa68f59fb0b205ec55a95636
- https://git.kernel.org/stable/c/7e053784c4c70df28324106d476778be7a4519b3
- https://git.kernel.org/stable/c/daab421fc2dc7d6ae7eb20a3f565ae09652c68b9
Modified: 2026-01-20
CVE-2022-50431
In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev() dev_set_name() in soundbus_add_one() allocates memory for name, it need be freed when of_device_register() fails, call soundbus_dev_put() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. And other resources are also freed in i2sbus_release_dev(), so it can return 0 directly.
- https://git.kernel.org/stable/c/027fee10e3a400cf6f3237374a1248da1082807b
- https://git.kernel.org/stable/c/4a4c8482e370d697738a78dcd7bf2780832cb712
- https://git.kernel.org/stable/c/5bdea674534153110b90d70b02f2fbaf48b2c0eb
- https://git.kernel.org/stable/c/802532a50acf501fdafe38a84ca2aa886d68af68
- https://git.kernel.org/stable/c/c7524279c8ddc7dbf3463bec70e0289097959944
- https://git.kernel.org/stable/c/ce6fd1c382a38b75557db85a2fe99d285540a03d
- https://git.kernel.org/stable/c/e81d7826b8f40430a1ea1b330e24d9a9eb4512c4
- https://git.kernel.org/stable/c/fd410d24665e4efb3c1796797181265efe553e9c
Modified: 2026-01-20
CVE-2022-50432
In the Linux kernel, the following vulnerability has been resolved:
kernfs: fix use-after-free in __kernfs_remove
Syzkaller managed to trigger concurrent calls to
kernfs_remove_by_name_ns() for the same file resulting in
a KASAN detected use-after-free. The race occurs when the root
node is freed during kernfs_drain().
To prevent this acquire an additional reference for the root
of the tree that is removed before calling __kernfs_remove().
Found by syzkaller with the following reproducer (slab_nomerge is
required):
syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0)
r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0)
close(r0)
pipe2(&(0x7f0000000140)={0xffffffffffffffff,
- https://git.kernel.org/stable/c/028cf780743eea79abffa7206b9dcfc080ad3546
- https://git.kernel.org/stable/c/02eb35131050735332658029082f61515b7dfe38
- https://git.kernel.org/stable/c/4abc99652812a2ddf932f137515d5c5a04723538
- https://git.kernel.org/stable/c/4dfd6a477a1525773469feaf3c514b2c0fef76b5
- https://git.kernel.org/stable/c/6f72a3977ba9d0e5491a5c01315204272e7f9c44
- https://git.kernel.org/stable/c/94d2643df1e70a4c310ebb5e2c493eec33df1a06
- https://git.kernel.org/stable/c/af1b57cc39beca203559576b3046094fc9e5eb32
- https://git.kernel.org/stable/c/c78b0dc6fb7fb389d674e491fd376388cdfb1d53
Modified: 2026-01-20
CVE-2022-50433
In the Linux kernel, the following vulnerability has been resolved: efi: ssdt: Don't free memory if ACPI table was loaded successfully Amadeusz reports KASAN use-after-free errors introduced by commit 3881ee0b1edc ("efi: avoid efivars layer when loading SSDTs from variables"). The problem appears to be that the memory that holds the new ACPI table is now freed unconditionally, instead of only when the ACPI core reported a failure to load the table. So let's fix this, by omitting the kfree() on success.
Modified: 2026-01-21
CVE-2022-50435
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid crash when inline data creation follows DIO write
When inode is created and written to using direct IO, there is nothing
to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets
truncated later to say 1 byte and written using normal write, we will
try to store the data as inline data. This confuses the code later
because the inode now has both normal block and inline data allocated
and the confusion manifests for example as:
kernel BUG at fs/ext4/inode.c:2721!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
RIP: 0010:ext4_writepages+0x363d/0x3660
RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293
RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180
RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000
RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b
R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128
R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001
FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0
Call Trace:
- https://git.kernel.org/stable/c/4bb26f2885ac6930984ee451b952c5a6042f2c0e
- https://git.kernel.org/stable/c/771f15782d95760cde352c8d4bfd6f2c70719568
- https://git.kernel.org/stable/c/89db2b50469bdbccb06ab072096d9d403124abac
- https://git.kernel.org/stable/c/d8e4af8314df54d94cf2a541cf9c8626afe81d41
- https://git.kernel.org/stable/c/fb98cb61efff3b2a1964939465ccaaf906af1d4f
Modified: 2026-01-21
CVE-2022-50437
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502670/
- https://git.kernel.org/stable/c/08c7375fa27a8ceee028868e03ffb3a0db919d44
- https://git.kernel.org/stable/c/3c43f3ec731c233eb84b66199ee76dbf3ec6ecae
- https://git.kernel.org/stable/c/4c1294da6aed1f16d47a417dcfe6602833c3c95c
- https://git.kernel.org/stable/c/9efb45b45ff6254bfd1f1997a06725cb3fc998a5
- https://git.kernel.org/stable/c/a9c1a6991a9b5aa6d0f2cbc9b8c3bf6c4d094dfa
- https://git.kernel.org/stable/c/b48949ab451eaf1e2c04c272c8a9a96a2b56546f
- https://git.kernel.org/stable/c/e8f916b84e4b028ecad6c6472eaad543cc7df806
- https://git.kernel.org/stable/c/ed7f1ff87a4afea1bc220d2ff00a7ce8e61f0b53
Modified: 2026-01-21
CVE-2022-50438
In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix memory leak when reading function table When the input parameter idx meets the expected case option in hinic_dbg_get_func_table(), read_data is not released. Fix it.
Modified: 2026-01-16
CVE-2022-50444
In the Linux kernel, the following vulnerability has been resolved: clk: tegra20: Fix refcount leak in tegra20_clock_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/0172d14f50098f5736b4b272a1529a3e05419bd6
- https://git.kernel.org/stable/c/4e343bafe03ff68a62f48f8235cf98f2c685468b
- https://git.kernel.org/stable/c/53531d00e2a8a28a3bf56ea58b18ff3611824f37
- https://git.kernel.org/stable/c/5d9fb09612defe7b1d5627db7b3833b46eb21e7b
- https://git.kernel.org/stable/c/6f76ef65899fcd93ca747ef38d7a41931e61e4fa
- https://git.kernel.org/stable/c/70f0a0a27d79f689defc5f5f0bd47d07813e6dea
- https://git.kernel.org/stable/c/8cd228892759d37f36a46616025f4fa0d0a63b5d
- https://git.kernel.org/stable/c/d6e750535b46e12cdde185b416c415e49e4e6e22
- https://git.kernel.org/stable/c/f9bdef9bb60814514a787b84184ecaa269a7c951
Modified: 2026-01-16
CVE-2022-50445
In the Linux kernel, the following vulnerability has been resolved: xfrm: Reinject transport-mode packets through workqueue The following warning is displayed when the tcp6-multi-diffip11 stress test case of the LTP test suite is tested: watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198] CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : des3_ede_encrypt+0x27c/0x460 [libdes] lr : 0x3f sp : ffff80000ceaa1b0 x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280 x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b x23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038 x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033 x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248 x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548 x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748 x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3 x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872 Call trace: des3_ede_encrypt+0x27c/0x460 [libdes] crypto_des3_ede_encrypt+0x1c/0x30 [des_generic] crypto_cbc_encrypt+0x148/0x190 crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_rcv_established+0x3c8/0x720 tcp_v6_do_rcv+0xdc/0x4a0 tcp_v6_rcv+0xc24/0xcb0 ip6_protocol_deliver_rcu+0xf0/0x574 ip6_input_finish+0x48/0x7c ip6_input+0x48/0xc0 ip6_rcv_finish+0x80/0x9c xfrm_trans_reinject+0xb0/0xf4 tasklet_action_common.constprop.0+0xf8/0x134 tasklet_action+0x30/0x3c __do_softirq+0x128/0x368 do_softirq+0xb4/0xc0 __local_bh_enable_ip+0xb0/0xb4 put_cpu_fpsimd_context+0x40/0x70 kernel_neon_end+0x20/0x40 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce] sha1_ce_finup+0x94/0x110 [sha1_ce] crypto_shash_finup+0x34/0xc0 hmac_finup+0x48/0xe0 crypto_shash_finup+0x34/0xc0 shash_digest_unaligned+0x74/0x90 crypto_shash_digest+0x4c/0x9c shash_ahash_digest+0xc8/0xf0 shash_async_digest+0x28/0x34 crypto_ahash_digest+0x48/0xcc crypto_authenc_genicv+0x88/0xcc [authenc] crypto_authenc_encrypt+0xd8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_push+0xb4/0x14c tcp_sendmsg_locked+0x71c/0xb64 tcp_sendmsg+0x40/0x6c inet6_sendmsg+0x4c/0x80 sock_sendmsg+0x5c/0x6c __sys_sendto+0x128/0x15c __arm64_sys_sendto+0x30/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x170/0x194 do_el0_svc+0x38/0x4c el0_svc+0x28/0xe0 el0t_64_sync_handler+0xbc/0x13c el0t_64_sync+0x180/0x184 Get softirq info by bcc tool: ./softirqs -NT 10 Tracing soft irq event time... Hit Ctrl-C to end. 15:34:34 SOFTIRQ TOTAL_nsecs block 158990 timer 20030920 sched 46577080 net_rx 676746820 tasklet 9906067650 15:34:45 SOFTIRQ TOTAL_nsecs block 86100 sched 38849790 net_rx ---truncated---
Modified: 2026-01-16
CVE-2022-50446
In the Linux kernel, the following vulnerability has been resolved: ARC: mm: fix leakage of memory allocated for PTE Since commit d9820ff ("ARC: mm: switch pgtable_t back to struct page *") a memory leakage problem occurs. Memory allocated for page table entries not released during process termination. This issue can be reproduced by a small program that allocates a large amount of memory. After several runs, you'll see that the amount of free memory has reduced and will continue to reduce after each run. All ARC CPUs are effected by this issue. The issue was introduced since the kernel stable release v5.15-rc1. As described in commit d9820ff after switch pgtable_t back to struct page *, a pointer to "struct page" and appropriate functions are used to allocate and free a memory page for PTEs, but the pmd_pgtable macro hasn't changed and returns the direct virtual address from the PMD (PGD) entry. Than this address used as a parameter in the __pte_free() and as a result this function couldn't release memory page allocated for PTEs. Fix this issue by changing the pmd_pgtable macro and returning pointer to struct page.
Modified: 2026-01-16
CVE-2022-50448
In the Linux kernel, the following vulnerability has been resolved: mm/uffd: fix warning without PTE_MARKER_UFFD_WP compiled in When PTE_MARKER_UFFD_WP not configured, it's still possible to reach pte marker code and trigger an warning. Add a few CONFIG_PTE_MARKER_UFFD_WP ifdefs to make sure the code won't be reached when not compiled in.
Modified: 2026-01-16
CVE-2022-50452
In the Linux kernel, the following vulnerability has been resolved:
net: sched: cake: fix null pointer access issue when cake_init() fails
When the default qdisc is cake, if the qdisc of dev_queue fails to be
inited during mqprio_init(), cake_reset() is invoked to clear
resources. In this case, the tins is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
cake_init()
q->tins = kvcalloc(...) --->failed, q->tins is NULL
...
qdisc_put()
...
cake_reset()
...
cake_dequeue_one()
b = &q->tins[...] --->q->tins is NULL
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:cake_dequeue_one+0xc9/0x3c0
Call Trace:
- https://git.kernel.org/stable/c/154f4c06d9dbec1a14e91286c70b6305810302e0
- https://git.kernel.org/stable/c/1dc0a019550fd38ec6cab2d73c90df2bd659c96b
- https://git.kernel.org/stable/c/51f9a8921ceacd7bf0d3f47fa867a64988ba1dcb
- https://git.kernel.org/stable/c/86aa1390898146f1de277bb6d2a8ed7fc7a43f12
- https://git.kernel.org/stable/c/ae48bee2830bf216800e1447baca39541e27a12e
- https://git.kernel.org/stable/c/bc8301ea7e7f1bb9d2ba2fcdf7b5ec2f0792b47e
Modified: 2026-01-16
CVE-2022-50454
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in nouveau_gem_prime_import_sg_table() nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and free the memory.Thus, when nouveau_bo_init() returns an error, the gem object has already been released. Then the call to nouveau_bo_ref() will use the freed "nvbo->bo" and lead to a use-after-free bug. We should delete the call to nouveau_bo_ref() to avoid the use-after-free.
- https://git.kernel.org/stable/c/3aeda2fe6517cc52663d4ce3588dd43f0d4124a7
- https://git.kernel.org/stable/c/540dfd188ea2940582841c1c220bd035a7db0e51
- https://git.kernel.org/stable/c/56ee9577915dc06f55309901012a9ef68dbdb5a8
- https://git.kernel.org/stable/c/5d6093c49c098d86c7b136aba9922df44aeb6944
- https://git.kernel.org/stable/c/7d80473e9f12548ac05b36af4fb9ce80f2f73509
- https://git.kernel.org/stable/c/861f085f81fd569b02cc2c11165a9e6cca144424
Modified: 2026-01-16
CVE-2022-50458
In the Linux kernel, the following vulnerability has been resolved: clk: tegra: Fix refcount leak in tegra210_clock_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1a6d97139b0a370a9d0809a00e91c41f5bcd3ef1
- https://git.kernel.org/stable/c/417ed4432b1b40526b1cb50e535d46900505f6d9
- https://git.kernel.org/stable/c/56c78cb1f00a9dde8cd762131ce8f4c5eb046fbb
- https://git.kernel.org/stable/c/6d3ac23b952f374017e1a5249d1f03bdbc7f9878
- https://git.kernel.org/stable/c/a19360db83d29bd6b0de4ffad2c815d79246ba99
- https://git.kernel.org/stable/c/ac010ec3484ba95c6ab3d946f9a83560005c13c6
- https://git.kernel.org/stable/c/e715510adc20a4a07f157ece4e6d068e648a0383
- https://git.kernel.org/stable/c/f38f34ba1e1029b927b81b9bf9d952f4ed4007bd
- https://git.kernel.org/stable/c/f487137a53b1a0692211f7ae82c0a7f87c30bdbe
Modified: 2026-01-16
CVE-2022-50459
In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername() Fix a NULL pointer crash that occurs when we are freeing the socket at the same time we access it via sysfs. The problem is that: 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold() does a get on the "struct sock". 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put on the "struct socket" and that does __sock_release() which sets the sock->ops to NULL. 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then call kernel_getpeername() which accesses the NULL sock->ops. Above we do a get on the "struct sock", but we needed a get on the "struct socket". Originally, we just held the frwd_lock the entire time but in commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while calling getpeername()") we switched to refcount based because the network layer changed and started taking a mutex in that path, so we could no longer hold the frwd_lock. Instead of trying to maintain multiple refcounts, this just has us use a mutex for accessing the socket in the interface code paths.
- https://git.kernel.org/stable/c/0a0b861fce2657ba08ec356a74346b37ca4b2008
- https://git.kernel.org/stable/c/57569c37f0add1b6489e1a1563c71519daf732cf
- https://git.kernel.org/stable/c/884a788f065578bb640382279a83d1df433b13e6
- https://git.kernel.org/stable/c/897dbbc57d71e8a34ec1af8e573a142de457da38
- https://git.kernel.org/stable/c/a26b0658751bb0a3b28386fca715333b104d32a2
Modified: 2026-01-16
CVE-2022-50460
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix xid leak in cifs_flock() If not flock, before return -ENOLCK, should free the xid, otherwise, the xid will be leaked.
Modified: 2026-01-16
CVE-2022-50466
In the Linux kernel, the following vulnerability has been resolved:
fs/binfmt_elf: Fix memory leak in load_elf_binary()
There is a memory leak reported by kmemleak:
unreferenced object 0xffff88817104ef80 (size 224):
comm "xfs_admin", pid 47165, jiffies 4298708825 (age 1333.476s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60 a8 b3 00 81 88 ff ff a8 10 5a 00 81 88 ff ff `.........Z.....
backtrace:
[
Modified: 2026-01-16
CVE-2022-50467
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null ndlp ptr dereference in abnormal exit path for GFT_ID An error case exit from lpfc_cmpl_ct_cmd_gft_id() results in a call to lpfc_nlp_put() with a null pointer to a nodelist structure. Changed lpfc_cmpl_ct_cmd_gft_id() to initialize nodelist pointer upon entry.
Modified: 2026-01-16
CVE-2022-50469
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential memory leak in rtw_init_drv_sw() In rtw_init_drv_sw(), there are various init functions are called to populate the padapter structure and some checks for their return value. However, except for the first one error path, the other five error paths do not properly release the previous allocated resources, which leads to various memory leaks. This patch fixes them and keeps the success and error separate. Note that these changes keep the form of `rtw_init_drv_sw()` in "drivers/staging/r8188eu/os_dep/os_intfs.c". As there is no proper device to test with, no runtime testing was performed.
Modified: 2026-01-23
CVE-2022-50470
In the Linux kernel, the following vulnerability has been resolved: xhci: Remove device endpoints from bandwidth list when freeing the device Endpoints are normally deleted from the bandwidth list when they are dropped, before the virt device is freed. If xHC host is dying or being removed then the endpoints aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host controller. So check and delete endpoints that are still on the bandwidth list when freeing the virt device. Solves a list_del corruption kernel crash when unbinding xhci-pci, caused by xhci_mem_cleanup() when it later tried to delete already freed endpoints from the bandwidth list. This only affects hosts that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
- https://git.kernel.org/stable/c/3bf860a41e0f2fcea0ac3aae8f7ef887a7994b70
- https://git.kernel.org/stable/c/5aed5b7c2430ce318a8e62f752f181e66f0d1053
- https://git.kernel.org/stable/c/5e4ce28ad907aa54f13b21d5f1dc490525957b0c
- https://git.kernel.org/stable/c/678d2cc2041cc6ce05030852dce9ad42719abcfc
- https://git.kernel.org/stable/c/8f1cd9633d1f21efc13e8fc75be8f2b6bb85e38c
- https://git.kernel.org/stable/c/c892a81c7424b4f6a660cb9c249d354ccf3afeca
- https://git.kernel.org/stable/c/cebbc8d335d6bcc1316584f779c08f80287c6af8
- https://git.kernel.org/stable/c/f0de39474078adef6ece7a183e34c15ce2c1d8d1
Modified: 2026-01-23
CVE-2022-50471
In the Linux kernel, the following vulnerability has been resolved:
xen/gntdev: Accommodate VMA splitting
Prior to this commit, the gntdev driver code did not handle the
following scenario correctly with paravirtualized (PV) Xen domains:
* User process sets up a gntdev mapping composed of two grant mappings
(i.e., two pages shared by another Xen domain).
* User process munmap()s one of the pages.
* User process munmap()s the remaining page.
* User process exits.
In the scenario above, the user process would cause the kernel to log
the following messages in dmesg for the first munmap(), and the second
munmap() call would result in similar log messages:
BUG: Bad page map in process doublemap.test pte:... pmd:...
page:0000000057c97bff refcount:1 mapcount:-1 \
mapping:0000000000000000 index:0x0 pfn:...
...
page dumped because: bad pte
...
file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0
...
Call Trace:
- https://git.kernel.org/stable/c/3c6a888e352283a14f37b9b433cd598a1a3a7dd0
- https://git.kernel.org/stable/c/4fb4053d90caa9985b87ec0e0c32c66a55bdfa3a
- https://git.kernel.org/stable/c/5c13a4a0291b30191eff9ead8d010e1ca43a4d0c
- https://git.kernel.org/stable/c/7c16d0a4e6a436b4e7c92bead3fab55aaa4c1141
- https://git.kernel.org/stable/c/cdafa219ace013c594e2491158ad1b51f9923dde
Modified: 2026-01-23
CVE-2022-50479
In the Linux kernel, the following vulnerability has been resolved: drm/amd: fix potential memory leak This patch fix potential memory leak (clk_src) when function run into last return NULL. s/free/kfree/ - Alex
Modified: 2026-01-23
CVE-2022-50480
In the Linux kernel, the following vulnerability has been resolved: memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe() The break of for_each_available_child_of_node() needs a corresponding of_node_put() when the reference 'child' is not used anymore. Here we do not need to call of_node_put() in fail path as '!match' means no break. While the of_platform_device_create() will created a new reference by 'child' but it has considered the refcounting.
- https://git.kernel.org/stable/c/44db35ceb94756ba513dcf6b69bf9e949b28469c
- https://git.kernel.org/stable/c/49605dc25e7fb33bf8b671279d4468531da90f89
- https://git.kernel.org/stable/c/566b143aa5112a0c2784e20603778518bb799537
- https://git.kernel.org/stable/c/61b3c876c1cbdb1efd1f52a1f348580e6e14efb6
- https://git.kernel.org/stable/c/b37f4a711e5d4bf3608ccbc6de82b52e92b441a0
- https://git.kernel.org/stable/c/fde46754d5483bc398018bbec3c8ef5c55219e67
Modified: 2026-01-23
CVE-2022-50482
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clean up si_domain in the init_dmars() error path A splat from kmem_cache_destroy() was seen with a kernel prior to commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") when there was a failure in init_dmars(), because the iommu_domain cache still had objects. While the mempool code is now gone, there still is a leak of the si_domain memory if init_dmars() fails. So clean up si_domain in the init_dmars() error path.
- https://git.kernel.org/stable/c/0365d6af75f9f2696e94a0fef24a2c8464c037c8
- https://git.kernel.org/stable/c/5cecfe151874b835331efe086bbdcaeaf64f6b90
- https://git.kernel.org/stable/c/620bf9f981365c18cc2766c53d92bf8131c63f32
- https://git.kernel.org/stable/c/724483b585a1b1e063d42ac5aa835707ff2ec165
- https://git.kernel.org/stable/c/749bea542b67513e99240dc58bbfc099e842d508
- https://git.kernel.org/stable/c/c4ad3ae4c6be9d8b0701761c839771116bca6ea3
- https://git.kernel.org/stable/c/d74196bb278b8f8af88e16bd595997dfa3d6fdb0
Modified: 2026-01-23
CVE-2022-50484
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential memory leaks When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point. Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list.
- https://git.kernel.org/stable/c/0604e5e5537af099ea2f6dfd892afe5c92db8a80
- https://git.kernel.org/stable/c/0672215994e2347a9b4f145e2bc1709b1e01cee3
- https://git.kernel.org/stable/c/28d8d267af5d73f91d7640cbdb4024703256e36c
- https://git.kernel.org/stable/c/46f0aed47673e275d682af60ed26dcc28add8eae
- https://git.kernel.org/stable/c/6382da0828995af87aa8b8bef28cc61aceb4aff3
- https://git.kernel.org/stable/c/988ec0cd0a2643c25c1658f7c33de2e15a5a2e31
- https://git.kernel.org/stable/c/bc1d16d282bca421c6fc31de4b8fd412010f01bd
- https://git.kernel.org/stable/c/e4442410f76d66b9f7e854010bce04853f665324
- https://git.kernel.org/stable/c/faa8c1ed77d0169955b9b3516b714cc5fb512f27
Modified: 2026-03-25
CVE-2022-50489
In the Linux kernel, the following vulnerability has been resolved: drm/mipi-dsi: Detach devices when removing the host Whenever the MIPI-DSI host is unregistered, the code of mipi_dsi_host_unregister() loops over every device currently found on that bus and will unregister it. However, it doesn't detach it from the bus first, which leads to all kind of resource leaks if the host wants to perform some clean up whenever a device is detached.
- https://git.kernel.org/stable/c/262364574b05676d4b9ebde2ddd3588cd2efd8ce
- https://git.kernel.org/stable/c/26c1b4cfe56f040f71a51c92da1f4cac2e3b9455
- https://git.kernel.org/stable/c/353ab1c13fdd6e524edde780235a8ce9b892c81c
- https://git.kernel.org/stable/c/45120fa5e522d444e3fc1c5a9afc5d53eed91d00
- https://git.kernel.org/stable/c/668a8f17b5290d04ef7343636a5588a0692731a1
- https://git.kernel.org/stable/c/6fc2cd40db1969ba372ce9536dcfcdb87271eac4
- https://git.kernel.org/stable/c/8242167cfc83dd7e4c96f44b45f108db9bb88146
- https://git.kernel.org/stable/c/95ae458209f5a556bba98aff872f933694914eb7
- https://git.kernel.org/stable/c/c202cda08cd5693645d4990ad1eb2e8068a884ec
Modified: 2026-03-25
CVE-2022-50490
In the Linux kernel, the following vulnerability has been resolved: bpf: Propagate error from htab_lock_bucket() to userspace In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns -EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current bucket_cnt is greater than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY when htab_lock_bucket() fails, and the application can retry or skip the busy batch as needed.
Modified: 2026-03-25
CVE-2022-50491
In the Linux kernel, the following vulnerability has been resolved:
coresight: cti: Fix hang in cti_disable_hw()
cti_enable_hw() and cti_disable_hw() are called from an atomic context
so shouldn't use runtime PM because it can result in a sleep when
communicating with firmware.
Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock
management to the SCMI power domain""), this causes a hang on Juno when
running the Perf Coresight tests or running this command:
perf record -e cs_etm//u -- ls
This was also missed until the revert commit because pm_runtime_put()
was called with the wrong device until commit 692c9a499b28 ("coresight:
cti: Correct the parameter for pm_runtime_put")
With lock and scheduler debugging enabled the following is output:
coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti
BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<0000000000000000>] 0x0
hardirqs last disabled at (0): [
Modified: 2026-01-23
CVE-2022-50492
In the Linux kernel, the following vulnerability has been resolved: drm/msm: fix use-after-free on probe deferral The bridge counter was never reset when tearing down the DRM device so that stale pointers to deallocated structures would be accessed on the next tear down (e.g. after a second late bind deferral). Given enough bridges and a few probe deferrals this could currently also lead to data beyond the bridge array being corrupted. Patchwork: https://patchwork.freedesktop.org/patch/502665/
Modified: 2026-01-23
CVE-2022-50494
In the Linux kernel, the following vulnerability has been resolved:
thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash
When CPU 0 is offline and intel_powerclamp is used to inject
idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687
caller is debug_smp_processor_id+0x17/0x20
CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57
Call Trace:
- https://git.kernel.org/stable/c/0f91f66c568b316b19cb042cf50584467b3bdff4
- https://git.kernel.org/stable/c/3e799e815097febbcb81b472285be824f5d089f9
- https://git.kernel.org/stable/c/418fae0700e85a498062424f8656435c32cdb200
- https://git.kernel.org/stable/c/513943bf879d45005213e6f5cfb7d9e9943f589f
- https://git.kernel.org/stable/c/5614908434451aafbf9b24cb5247cf1d21269f76
- https://git.kernel.org/stable/c/5a646c38f648185ee2c62f2a19da3c6f04e27612
- https://git.kernel.org/stable/c/68b99e94a4a2db6ba9b31fe0485e057b9354a640
- https://git.kernel.org/stable/c/6904727db0eb62fb0c2dce1cf331c341d97ee4b7
- https://git.kernel.org/stable/c/6e2a347b304224b2aeb1c0ea000d1cf8a02cc592
Modified: 2026-01-22
CVE-2022-50498
In the Linux kernel, the following vulnerability has been resolved:
eth: alx: take rtnl_lock on resume
Zbynek reports that alx trips an rtnl assertion on resume:
RTNL: assertion failed at net/core/dev.c (2891)
RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0
Call Trace:
Modified: 2026-01-22
CVE-2022-50500
In the Linux kernel, the following vulnerability has been resolved: netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed If some items in nsim_dev_resources_register() fail, memory leak will occur. The following is the memory leak information. unreferenced object 0xffff888074c02600 (size 128): comm "echo", pid 8159, jiffies 4294945184 (age 493.530s) hex dump (first 32 bytes): 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<0000000011a31c98>] kmalloc_trace+0x22/0x60 [<0000000027384c69>] devl_resource_register+0x144/0x4e0 [<00000000a16db248>] nsim_drv_probe+0x37a/0x1260 [<000000007d1f448c>] really_probe+0x20b/0xb10 [<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0 [<00000000077e0351>] driver_probe_device+0x49/0x140 [<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0 [<000000008538f359>] bus_for_each_drv+0x151/0x1d0 [<0000000038e09747>] __device_attach+0x1c9/0x4e0 [<00000000dd86e533>] bus_probe_device+0x1d5/0x280 [<00000000839bea35>] device_add+0xae0/0x1cb0 [<000000009c2abf46>] new_device_store+0x3b6/0x5f0 [<00000000fb823d7f>] bus_attr_store+0x72/0xa0 [<000000007acc4295>] sysfs_kf_write+0x106/0x160 [<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0 [<0000000075eb41bf>] vfs_write+0x8f0/0xc80
Modified: 2026-03-25
CVE-2022-50506
In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a bio_set_dev call (which has since been removed) to "earlier", from drbd_request_prepare to drbd_req_new. The problem is that this accesses device->ldev->backing_bdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref. So, only allocate the private_bio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case.
Modified: 2026-03-17
CVE-2022-50512
In the Linux kernel, the following vulnerability has been resolved: ext4: fix potential memory leak in ext4_fc_record_regions() As krealloc may return NULL, in this case 'state->fc_regions' may not be freed by krealloc, but 'state->fc_regions' already set NULL. Then will lead to 'state->fc_regions' memory leak.
- https://git.kernel.org/stable/c/2cfb769d60a2a57eb3566765428b6131cd16dcfe
- https://git.kernel.org/stable/c/417b0455a0b6d0f60a2930592731d1f8340e24be
- https://git.kernel.org/stable/c/518566e71ad86b7c2f1bf6d9caee9588bb7ac158
- https://git.kernel.org/stable/c/7069d105c1f15c442b68af43f7fde784f3126739
- https://git.kernel.org/stable/c/a4058b869e6c5e517c79e30532a350d0f3115c3e
Modified: 2026-03-17
CVE-2022-50513
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv() In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocated in failure, then `pcmdpriv->cmd_allocated_buf` will be not properly released. Besides, considering there are only two error paths and the first one can directly return, so we do not need implicitly jump to the `exit` tag to execute the error handler. So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the error path to release the resource and simplified the return logic of rtw_init_cmd_priv(). As there is no proper device to test with, no runtime testing was performed.
- https://git.kernel.org/stable/c/39bef9c6a91bbb790d04c1347cfeae584541fb6a
- https://git.kernel.org/stable/c/708056fba733a73d926772ea4ce9a42d240345da
- https://git.kernel.org/stable/c/8db6ca84eee0ac258706f3fca54f7c021cb159ef
- https://git.kernel.org/stable/c/a5be64ff6d21f7805a91e6d81f53fc19cd9f0fae
- https://git.kernel.org/stable/c/e5d8f05edb36fc4ab15beec62cb6ab62f5a60fe2
- https://git.kernel.org/stable/c/e6cc39db24a63f68314473621020ed8cad7be423
Modified: 2026-03-17
CVE-2022-50515
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue() If construction of the array of work queues to handle hpd_rx_irq offload work fails, we need to unwind. Destroy all the created workqueues and the allocated memory for the hpd_rx_irq_offload_work_queue struct array.
Modified: 2026-03-17
CVE-2022-50516
In the Linux kernel, the following vulnerability has been resolved:
fs: dlm: fix invalid derefence of sb_lvbptr
I experience issues when putting a lkbsb on the stack and have sb_lvbptr
field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash
with the following kernel message, the dangled pointer is here
0xdeadbeef as example:
[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef
[ 102.749320] #PF: supervisor read access in kernel mode
[ 102.749323] #PF: error_code(0x0000) - not-present page
[ 102.749325] PGD 0 P4D 0
[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI
[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565
[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014
[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10
[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1
- https://git.kernel.org/stable/c/1ab6d3030652b5de0015176a5b0ad9df9b847514
- https://git.kernel.org/stable/c/57c1cfb5781068e5d3632bc6e5f74a8fcc4f1a30
- https://git.kernel.org/stable/c/7175e131ebba47afef47e6ac4d5bab474d1e6e49
- https://git.kernel.org/stable/c/ea7be82fd7e1f5de72208bce93fbbe6de6c13dec
- https://git.kernel.org/stable/c/ef3033b435a6bac547166b793025578fab2f9df3
Modified: 2026-03-17
CVE-2022-50517
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: do not clobber swp_entry_t during THP split
The following has been observed when running stressng mmap since commit
b653db77350c ("mm: Clear page->private when splitting or migrating a page")
watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546]
CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374
Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016
RIP: 0010:xas_descend+0x28/0x80
Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2
RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246
RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002
RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0
RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0
R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000
R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88
FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2026-03-17
CVE-2022-50526
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502664/
Modified: 2026-03-17
CVE-2022-50530
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping() Our syzkaller report a null pointer dereference, root cause is following: __blk_mq_alloc_map_and_rqs set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs blk_mq_alloc_map_and_rqs blk_mq_alloc_rqs // failed due to oom alloc_pages_node // set->tags[hctx_idx] is still NULL blk_mq_free_rqs drv_tags = set->tags[hctx_idx]; // null pointer dereference is triggered blk_mq_clear_rq_mapping(drv_tags, ...) This is because commit 63064be150e4 ("blk-mq: Add blk_mq_alloc_map_and_rqs()") merged the two steps: 1) set->tags[hctx_idx] = blk_mq_alloc_rq_map() 2) blk_mq_alloc_rqs(..., set->tags[hctx_idx]) into one step: set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs() Since tags is not initialized yet in this case, fix the problem by checking if tags is NULL pointer in blk_mq_clear_rq_mapping().
Modified: 2026-03-17
CVE-2022-50531
In the Linux kernel, the following vulnerability has been resolved: tipc: fix an information leak in tipc_topsrv_kern_subscr Use a 8-byte write to initialize sub.usr_handle in tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized when issuing setsockopt(..., SOL_TIPC, ...). This resulted in an infoleak reported by KMSAN when the packet was received: ===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169 instrument_copy_to_user ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/iov_iter.c:169 _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527 copy_to_iter ./include/linux/uio.h:176 simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419 skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527 skb_copy_datagram_msg ./include/linux/skbuff.h:3903 packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469 ____sys_recvmsg+0x2c4/0x810 net/socket.c:? ___sys_recvmsg+0x217/0x840 net/socket.c:2743 __sys_recvmsg net/socket.c:2773 __do_sys_recvmsg net/socket.c:2783 __se_sys_recvmsg net/socket.c:2780 __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 ... Uninit was stored to memory at: tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375 tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084 tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201 __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 __se_sys_setsockopt net/socket.c:2260 __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 Local variable sub created at: tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================
- https://git.kernel.org/stable/c/3d1b83ff7b6575a4e41283203e6b2e25ea700cd7
- https://git.kernel.org/stable/c/567f8de358b61015dcfb8878a1f06c5369a45f54
- https://git.kernel.org/stable/c/777ecaabd614d47c482a5c9031579e66da13989a
- https://git.kernel.org/stable/c/dbc01c0a4e202a7e925dad1d4b7c1d6eb0c81154
- https://git.kernel.org/stable/c/e558e148938442dd49628cd7ef61c360832bef31
- https://git.kernel.org/stable/c/fef70f978bc289642501d88d2a3f5e841bd31a67
Modified: 2026-02-26
CVE-2022-50540
In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom-adm: fix wrong sizeof config in slave_config Fix broken slave_config function that uncorrectly compare the peripheral_size with the size of the config pointer instead of the size of the config struct. This cause the crci value to be ignored and cause a kernel panic on any slave that use adm driver. To fix this, compare to the size of the struct and NOT the size of the pointer.
Modified: 2026-02-26
CVE-2022-50541
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics. These registers are 32-bit hardware counters and the driver uses these counters to monitor the operational progress status for a channel, when transferring more than 4GB of data it was observed that these counters overflow and completion calculation of a operation gets affected and the transfer hangs indefinitely. This commit adds changes to decrease the byte count for every complete transaction so that these registers never overflow and the proper byte count statistics is maintained for ongoing transaction by the RT counters. Earlier uc->bcnt used to maintain a count of the completed bytes at driver side, since the RT counters maintain the statistics of current transaction now, the maintenance of uc->bcnt is not necessary.
Modified: 2026-02-26
CVE-2022-50544
In the Linux kernel, the following vulnerability has been resolved: usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info() xhci_alloc_stream_info() allocates stream context array for stream_info ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs, stream_info->stream_ctx_array is not released, which will lead to a memory leak. We can fix it by releasing the stream_info->stream_ctx_array with xhci_free_stream_ctx() on the error path to avoid the potential memory leak.
- https://git.kernel.org/stable/c/782c873f8e7686f5b3c47e8b099f7e08c3dd1fdc
- https://git.kernel.org/stable/c/7e271f42a5cc3768cd2622b929ba66859ae21f97
- https://git.kernel.org/stable/c/7fc6bab3413e6a42bb1264ff7c9149808c93a4c7
- https://git.kernel.org/stable/c/91271a3e772e180bbb8afb114c72fd294a02f93d
- https://git.kernel.org/stable/c/9fa81cbd2dd300aa8fe9bac70e068b9a11cbb144
- https://git.kernel.org/stable/c/a40ad475236022f3432880e3091c380e46e71a71
- https://git.kernel.org/stable/c/ddab9fe76296840aad686c66888a9c1dfdbff5ff
- https://git.kernel.org/stable/c/e702de2f5c893bf2cdb0152191f99a6ad1411823
- https://git.kernel.org/stable/c/fcd594da0b5955119d9707e4e0a8d0fb1c969101
Modified: 2026-02-26
CVE-2022-50552
In the Linux kernel, the following vulnerability has been resolved: blk-mq: use quiesced elevator switch when reinitializing queues The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0
Modified: 2026-02-05
CVE-2022-50555
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a null-ptr-deref in tipc_topsrv_accept
syzbot found a crash in tipc_topsrv_accept:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
Workqueue: tipc_rcv tipc_topsrv_accept
RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487
Call Trace:
- https://git.kernel.org/stable/c/24b129aed8730e48f47d852d58d76825ab6f407c
- https://git.kernel.org/stable/c/32a3d4660b34ce49ac0162338ebe362098e2f5df
- https://git.kernel.org/stable/c/7a939503fc32bff4ed60800b73ff7fbb4aea2142
- https://git.kernel.org/stable/c/82cb4e4612c633a9ce320e1773114875604a3cce
- https://git.kernel.org/stable/c/ce69bdac2310152bb70845024d5d704c52aabfc3
- https://git.kernel.org/stable/c/cedb41664e27b2cae7e21487f1bee22dcd84037d
Modified: 2025-04-01
CVE-2023-0468
A use-after-free flaw was found in io_uring/poll.c in io_poll_check_events in the io_uring subcomponent in the Linux Kernel due to a race condition of poll_refs. This flaw may cause a NULL pointer dereference.
Modified: 2025-04-01
CVE-2023-0469
A use-after-free flaw was found in io_uring/filetable.c in io_install_fixed_file in the io_uring subcomponent in the Linux Kernel during call cleanup. This flaw may lead to a denial of service.
Modified: 2024-11-21
CVE-2023-0590
A use-after-free flaw was found in qdisc_graft in net/sched/sch_api.c in the Linux Kernel due to a race problem. This flaw leads to a denial of service issue. If patch ebda44da44f6 ("net: sched: fix race condition in qdisc_graft()") not applied yet, then kernel could be affected.
Modified: 2025-03-18
CVE-2023-1195
A use-after-free flaw was found in reconn_set_ipaddr_from_hostname in fs/cifs/connect.c in the Linux kernel. The issue occurs when it forgets to set the free pointer server->hostname to NULL, leading to an invalid pointer request.
Modified: 2025-03-19
CVE-2023-1382
A data race flaw was found in the Linux kernel, between where con is allocated and con->sock is set. This issue leads to a NULL pointer dereference when accessing con->sock->sk in net/tipc/topsrv.c in the tipc protocol in the Linux kernel.
Modified: 2025-04-23
CVE-2023-2006
A race condition was found in the Linux kernel's RxRPC network protocol, within the processing of RxRPC bundles. This issue results from the lack of proper locking when performing operations on an object. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel.
- https://bugzilla.redhat.com/show_bug.cgi?id=2189112
- https://github.com/torvalds/linux/commit/3bcd6c7eaa53
- https://security.netapp.com/advisory/ntap-20230609-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-439/
- https://bugzilla.redhat.com/show_bug.cgi?id=2189112
- https://github.com/torvalds/linux/commit/3bcd6c7eaa53
- https://security.netapp.com/advisory/ntap-20230609-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-439/
Modified: 2025-02-05
CVE-2023-2166
A null pointer dereference issue was found in can protocol in net/can/af_can.c in the Linux before Linux. ml_priv may not be initialized in the receive path of CAN frames. A local user could use this flaw to crash the system or potentially cause a denial of service.
Modified: 2025-02-13
CVE-2023-2236
A use-after-free vulnerability in the Linux Kernel io_uring subsystem can be exploited to achieve local privilege escalation. Both io_install_fixed_file and its callers call fput in a file in case of an error, causing a reference underflow which leads to a use-after-free vulnerability. We recommend upgrading past commit 9d94c04c0db024922e886c9fd429659f22f48ea4.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d94c04c0db024922e886c9fd429659f22f48ea4
- https://kernel.dance/9d94c04c0db024922e886c9fd429659f22f48ea4
- https://security.netapp.com/advisory/ntap-20230601-0010/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d94c04c0db024922e886c9fd429659f22f48ea4
- https://kernel.dance/9d94c04c0db024922e886c9fd429659f22f48ea4
- https://security.netapp.com/advisory/ntap-20230601-0010/
Modified: 2025-03-19
CVE-2023-22998
In the Linux kernel before 6.0.3, drivers/gpu/drm/virtio/virtgpu_object.c misinterprets the drm_gem_shmem_get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer).
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.3
- https://github.com/torvalds/linux/commit/c24968734abfed81c8f93dc5f44a7b7a9aecadfa
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.3
- https://github.com/torvalds/linux/commit/c24968734abfed81c8f93dc5f44a7b7a9aecadfa
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
Modified: 2025-05-05
CVE-2023-26607
In the Linux kernel 6.0.8, there is an out-of-bounds read in ntfs_attr_find in fs/ntfs/attrib.c.
- https://bugzilla.suse.com/show_bug.cgi?id=1208703
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36a4d82dddbbd421d2b8e79e1cab68c8126d5075
- https://lkml.org/lkml/2023/2/21/1353
- https://security.netapp.com/advisory/ntap-20230316-0010/
- https://bugzilla.suse.com/show_bug.cgi?id=1208703
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36a4d82dddbbd421d2b8e79e1cab68c8126d5075
- https://lkml.org/lkml/2023/2/21/1353
- https://security.netapp.com/advisory/ntap-20230316-0010/
Modified: 2024-11-21
CVE-2023-3355
A NULL pointer dereference flaw was found in the Linux kernel's drivers/gpu/drm/msm/msm_gem_submit.c code in the submit_lookup_cmds function, which fails because it lacks a check of the return value of kmalloc(). This issue allows a local user to crash the system.
- https://access.redhat.com/security/cve/CVE-2023-3355
- https://bugzilla.redhat.com/show_bug.cgi?id=2217820
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d839f0811a31322c087a859c2b181e2383daa7be
- https://access.redhat.com/security/cve/CVE-2023-3355
- https://bugzilla.redhat.com/show_bug.cgi?id=2217820
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d839f0811a31322c087a859c2b181e2383daa7be
Modified: 2025-03-10
CVE-2023-3357
A NULL pointer dereference flaw was found in the Linux kernel AMD Sensor Fusion Hub driver. This flaw allows a local user to crash the system.
Modified: 2024-11-21
CVE-2023-3812
An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
Modified: 2025-11-03
CVE-2024-50121
In the Linux kernel, the following vulnerability has been resolved: nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net In the normal case, when we excute `echo 0 > /proc/fs/nfsd/threads`, the function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will release all resources related to the hashed `nfs4_client`. If the `nfsd_client_shrinker` is running concurrently, the `expire_client` function will first unhash this client and then destroy it. This can lead to the following warning. Additionally, numerous use-after-free errors may occur as well. nfsd_client_shrinker echo 0 > /proc/fs/nfsd/threads expire_client nfsd_shutdown_net unhash_client ... nfs4_state_shutdown_net /* won't wait shrinker exit */ /* cancel_work(&nn->nfsd_shrinker_work) * nfsd_file for this /* won't destroy unhashed client1 */ * client1 still alive nfs4_state_destroy_net */ nfsd_file_cache_shutdown /* trigger warning */ kmem_cache_destroy(nfsd_file_slab) kmem_cache_destroy(nfsd_file_mark_slab) /* release nfsd_file and mark */ __destroy_client ==================================================================== BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown() -------------------------------------------------------------------- CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================== BUG nfsd_file_mark (Tainted: G B W ): Objects remaining nfsd_file_mark on __kmem_cache_shutdown() -------------------------------------------------------------------- dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xc8/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e To resolve this issue, cancel `nfsd_shrinker_work` using synchronous mode in nfs4_state_shutdown_net.
- https://git.kernel.org/stable/c/36775f42e039b01d4abe8998bf66771a37d3cdcc
- https://git.kernel.org/stable/c/5ade4382de16c34d9259cb548f36ec5c4555913c
- https://git.kernel.org/stable/c/add1df5eba163a3a6ece11cb85890e2e410baaea
- https://git.kernel.org/stable/c/d5ff2fb2e7167e9483846e34148e60c0c016a1f6
- https://git.kernel.org/stable/c/f67138dd338cb564ade7d3755c8cd4f68b46d397
- https://git.kernel.org/stable/c/f965dc0f099a54fca100acf6909abe52d0c85328
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
