ALT-BU-2023-2748-21
Branch c9f2 update bulletin.
Package kernel-image-std-def updated to version 5.10.170-alt0.c9f.2 for branch c9f2 in task 315798.
Closed vulnerabilities
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: 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-08-19
BDU:2022-07509
Уязвимость подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ и повысить свои привилегии
Modified: 2025-01-29
BDU:2023-00061
Уязвимость драйвера GPU i915 ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-00359
Уязвимость драйвера drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2023-00361
Уязвимость функций gru_set_context_option(), gru_fault() и gru_handle_user_call_os() драйвера SGI GRU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-09-30
BDU:2023-00380
Уязвимость драйвера drivers/net/wireless/rndis_wlan.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-30
BDU:2023-00382
Уязвимость компонента ALSA:pcm (звуковой подсистемы) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании и получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-24
BDU:2023-00383
Уязвимость компонентa netfilter ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации и повысить свои привилегии.
Modified: 2025-01-29
BDU:2023-00749
Уязвимость функции ib_prctl_set() ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
Modified: 2025-01-29
BDU:2023-00946
Уязвимость функции follow_page_pte файла mm/gup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или получить несанкционированный доступ к защищаемой информации
Modified: 2024-03-01
BDU:2023-01196
Уязвимость модуля io_uring.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2025-08-19
BDU:2023-01200
Уязвимость реализации протокола Upper Level Protocol (ULP) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии, выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2023-01205
Уязвимость функции rds_rm_zerocopy_callback() в модуле net/rds/message.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-01571
Уязвимость функции tcf_exts_exec() фильтра индексирования системы контроля трафика tcindex ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-30
BDU:2023-02532
Уязвимость функции _copy_from_user() в модуле lib/usercopy.c ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-01-09
BDU:2023-02604
Уязвимость функции rxrpc_unbundle_conn() ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-12-05
BDU:2023-03726
Уязвимость подсистемы io_uring ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии до уровня root
Modified: 2024-10-04
BDU:2024-06622
Уязвимость компонента hci_qca ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-04
BDU:2024-06623
Уязвимость компонента efi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06855
Уязвимость функции ieee80211_tx_ba_session_handle_start() в компоненте mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07447
Уязвимость компонентов btrfs ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07448
Уязвимость функции axi_chan_handle_err () ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07449
Уязвимость функций xhci_free_dev() и xhci_kill_endpoint_urbs() компонентов xhci ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07450
Уязвимость компонентов nilfs2 ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07451
Уязвимость компонентов xhci ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07452
Уязвимость компонента io_uring ядра операционной системы Linux, связанная с неправильной блокировкой, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07453
Уязвимость компонента act_mpls ядра операционной системы Linux, связанная с неправильной проверкой входных данных, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-26
BDU:2024-07454
Уязвимость компонента nfc ядра операционной системы Linux, связанная с использованием памяти после освобождения, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-18
BDU:2024-07587
Уязвимость компонента qcom-geni-serial ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность и доступность защищаемой информации
Modified: 2024-10-11
BDU:2024-07607
Уязвимость компонента f_ncm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07613
Уязвимость компонента gsmi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07617
Уязвимость компонента drm/virtio ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность
Modified: 2024-11-06
BDU:2024-07620
Уязвимость функции dp_aux_cmd_fifo_tx() компонента dp ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07626
Уязвимость компонента ixgbe ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07627
Уязвимость компонента da9211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07628
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-18
BDU:2024-07629
Уязвимость компонента fastrpc ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-18
BDU:2024-07630
Уязвимость компонента fastrpc ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-11
BDU:2024-07632
Уязвимость компонента gadgetfs ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2024-08163
Уязвимость компонента vivid ядра операционной системы 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, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-19
BDU:2024-09786
Уязвимость функции ibmpex_register_bmc() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
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, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2024-10366
Уязвимость компонента mmc_spi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10367
Уязвимость компонентов sched/psi ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10369
Уязвимость компонента hda ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10370
Уязвимость компонента cifs ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
BDU:2024-10371
Уязвимость компонента USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10372
Уязвимость компонента sdio ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
BDU:2024-10373
Уязвимость функции __free_pages ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10499
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10501
Уязвимость компонентов xfrm/compat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10502
Уязвимость компонентов IB/hfi1 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-02-26
BDU:2025-01679
Уязвимость компонента media ядра операционной системы 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-01683
Уязвимость компонента HID ядра операционной системы 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-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-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-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-01711
Уязвимость компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-26
BDU:2025-01712
Уязвимость компонента xen-netfront ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04356
Уязвимость функции pcs_set_mux() модуля drivers/pinctrl/pinctrl-single.c - драйвера поддержки контроллеров выводов PINCTRL ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06025
Уязвимость функции nft_payload() модуля net/netfilter /nft_payload.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06232
Уязвимость функции ip_metrics_convert() компонента ipv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06234
Уязвимость функции bpf_send_signal_common() компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06236
Уязвимость функции add_secret_dac_path() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06238
Уязвимость функции tcp_bpf_prots() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06239
Уязвимость функции dp83822_config_intr() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06247
Уязвимость функции efi_mem_reserve_persistent() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06252
Уязвимость функции iscsi_sw_tcp_host_get_param() и iscsi_sw_tcp_session_create() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06260
Уязвимость функции fib_metrics_match() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06265
Уязвимость функции init_ISA_irqs() и make_8259A_irq() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06269
Уязвимость функции skb_segment_list() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06270
Уязвимость функции ioctl_send_response() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06271
Уязвимость функции vcs_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06286
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06287
Уязвимость компонентов perf/x86/amd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06288
Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06289
Уязвимость компонента w1 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06290
Уязвимость компонентов mm/swapfile ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06292
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06293
Уязвимость компонента fbdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06296
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06299
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06301
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06303
Уязвимость компонентов EDAC/highbank ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06308
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06311
Уязвимость компонентов drm/i915 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06315
Уязвимость компонента Squashfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06318
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06330
Уязвимость функции create_hist_field() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06332
Уязвимость функции local_cleanup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06336
Уязвимость функции init_events() и early_trace_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06339
Уязвимость функции check_stack_write_fixed_off() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06340
Уязвимость функции EXPORT_SYMBOL() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06346
Уязвимость функции taprio_reset() и taprio_destroy() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06348
Уязвимость функции EXPORT_SYMBOL() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06350
Уязвимость функции l2tp_xmit_core(), l2tp_tunnel_create() и l2tp_tunnel_register() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06351
Уязвимость функции betopff_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06359
Уязвимость функции smbd_destroy() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06360
Уязвимость функции dump_syn_reg(), llcc_ecc_irq_handler() и qcom_llcc_edac_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06362
Уязвимость функции validate_nla() и __nla_validate_parse() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06396
Уязвимость функции j1939_session_deactivate() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-07469
Уязвимость функции retract_page_tables() модуля mm/khugepaged.c подсистемы управления памятью ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-07504
Уязвимость функции dyn_event_release() модуля kernel/trace/trace_dynevent.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10566
Уязвимость функции ovs_meter_cmd_set() модуля net/openvswitch/meter.c поддержки маршрутизаторов Open vSwitch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-12794
Уязвимость функции rockchip_clk_register_pll() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2025-12795
Уязвимость функции chameleon_parse_gdd() в модуле drivers/mcb/mcb-parse.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-12796
Уязвимость функции mxm_wmi_call_mx() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12801
Уязвимость функции radeon_atrm_get_bios() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12809
Уязвимость модуля drivers/usb/gadget/function/f_hid.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12811
Уязвимость функции get_default_font() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12813
Уязвимость функции arm_smmu_pmu_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12814
Уязвимость модуля drivers/media/platform/chips-media/coda-bit.c ядра операционной системы 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-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-14275
Уязвимость функции coretemp_remove_core() модуля drivers/hwmon/coretemp.c драйвера мониторинга оборудования ядра операционной системы 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-14280
Уязвимость функции ixgbevf_init_module() модуля drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14291
Уязвимость функции aio_ring_mremap() модуля fs/aio.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14570
Уязвимость функции tpm_pm_suspend() модуля drivers/char/tpm/tpm-interface.c драйвера поддержки алфавитно-цифровых устройств с TPM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14587
Уязвимость функции nilfs_ioctl_set_alloc_range() модуля fs/nilfs2/ioctl.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15324
Уязвимость функции kalmia_send_init_packet() модуля drivers/net/usb/kalmia.c - драйвера поддержки сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01289
Уязвимость функции si470x_usb_driver_probe() модуля drivers/media/radio/si470x/radio-si470x-usb.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01290
Уязвимость функции brcmf_fw_alloc_request() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01541
Уязвимость функции hci_sync_conn_complete_evt() модуля net/bluetooth/hci_event.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02174
Уязвимость функции igb_alloc_q_vector() в модуле drivers/net/ethernet/intel/igb/igb_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02176
Уязвимость драйвера dvb-core ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02185
Уязвимость функции acpi_ds_call_control_method() в модуле drivers/acpi/acpica/dsmethod.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02263
Уязвимость функции dbMount() в модуле fs/jfs/jfs_dmap.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02265
Уязвимость функции crypt_message() в модуле fs/cifs/smb2ops.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02270
Уязвимость функции destroy() в модуле drivers/md/dm-cache-target.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02277
Уязвимость функции ismt_access() модуля drivers/i2c/busses/i2c-ismt.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02338
Уязвимость функции set_machine_constraints() в модуле drivers/regulator/core.c драйвера регуляторов напряжения и тока ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02340
Уязвимость функции blk_mq_register_hctx() в модуле block/blk-mq-sysfs.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02341
Уязвимость функции add_all_parents() в модуле fs/btrfs/backref.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02343
Уязвимость функции rtas_os_term() в модуле arch/powerpc/kernel/rtas.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02357
Уязвимость функции ext4_clu_mapped() в модуле fs/ext4/extents.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02371
Уязвимость функции tsi148_dma_list_add() модуля drivers/staging/vme_user/vme_tsi148.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02437
Уязвимость функции nvme_trace_bio_complete() модуля [модуль] ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02439
Уязвимость функции setup_callback_client() модуля fs/nfsd/nfs4callback.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02440
Уязвимость функции udp_tunnel_sock_release() модуля net/ipv4/udp_tunnel_core.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02519
Уязвимость функции vub300_probe() модуля drivers/mmc/host/vub300.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02522
Уязвимость функции radeon_acpi_vfct_bios() модуля drivers/gpu/drm/radeon/radeon_bios.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02525
Уязвимость функции get_dvsec_vendor0() модуля drivers/misc/ocxl/config.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02573
Уязвимость функции nft_tproxy_dump() в модуле net/netfilter/nft_tproxy.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03266
Уязвимость функции brcmf_pcie_init_ringbuffers() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03271
Уязвимость функции panfrost_ioctl_create_bo() модуля drivers/gpu/drm/panfrost/panfrost_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03584
Уязвимость функции cpufreq_policy_alloc() модуля drivers/cpufreq/cpufreq.c драйвера масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03737
Уязвимость функций tcpci_register_port() и tcpci_unregister_port() модуля drivers/usb/typec/tcpm/tcpci.c драйвера диспетчера контроллеров портов USB TypeC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
Modified: 2026-04-20
BDU:2026-03769
Уязвимость функции pnp_alloc_dev() модуля drivers/pnp/core.c ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, вызвать отказ в обслуживании
BDU:2026-03772
Уязвимость функции pxa2xx_flash_probe() модуля drivers/mtd/maps/pxa2xx-flash.c драйвера доступа к устройствам памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03773
Уязвимость функции crb_acpi_add() модуля drivers/char/tpm/tpm_crb.c драйвера алфавитноцифровых устройств с TPM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03812
Уязвимость функций rk3288_lvds_poweron() и px30_lvds_poweron() модуля drivers/gpu/drm/rockchip/rockchip_lvds.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03813
Уязвимость функции mpt3sas_transport_port_add() модуля drivers/scsi/mpt3sas/mpt3sas_transport.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03814
Уязвимость функции fake_init() модуля drivers/staging/vme_user/vme_fake.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03841
Уязвимость функции acpi_ut_copy_ipackage_to_ipackage() модуля drivers/acpi/acpica/utcopy.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03854
Уязвимость функции bitmap_ip_create() модуля net/netfilter/ipset/ip_set_bitmap_ip.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03944
Уязвимость функции cfctrl_linkup_request() модуля net/caif/cfctrl.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03980
Уязвимость функции nest_imc_event_init() модуля arch/powerpc/perf/imc-pmu.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04049
Уязвимость функции test_firmware_init() модуля lib/test_firmware.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04053
Уязвимость функции solo_sysfs_init() модуля drivers/media/pci/solo6x10/solo6x10-core.c драйвера мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04054
Уязвимость функции _samsung_clk_register_pll() модуля drivers/clk/samsung/clk-pll.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04058
Уязвимость функции ppr_notifier() модуля drivers/iommu/amd/iommu_v2.c драйвера IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04061
Уязвимость функции __open_metadata() модуля drivers/md/dm-thin-metadata.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04063
Уязвимость функции tcp_bpf_send_verdict() модуля net/ipv4/tcp_bpf.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04084
Уязвимость функции rpi_firmware_probe() модуля drivers/firmware/raspberrypi.c драйвера прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04085
Уязвимость функции fsl_pamu_probe() модуля drivers/iommu/fsl_pamu.c драйвера IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04087
Уязвимость функции mpc52xx_lpbfifo_probe() модуля arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04092
Уязвимость функции intel_gvt_debugfs_add_vgpu() модуля drivers/gpu/drm/i915/gvt/debugfs.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04437
Уязвимость функции sifive_gpio_probe() модуля drivers/gpio/gpio-sifive.c драйвера GPIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04555
Уязвимость функции ceph_update_snap_trace() модуля fs/ceph/snap.c поддержки распределенной файловой системы Ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04861
Уязвимость функций sti_dvo_connector_mode_valid() (drivers/gpu/drm/sti/sti_dvo.c), sti_hda_connector_mode_valid() (drivers/gpu/drm/sti/sti_hda.c) и sti_hdmi_connector_mode_valid() (drivers/gpu/drm/sti/sti_hdmi.c) драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04863
Уязвимость функции hugetlbfs_parse_param() модуля fs/hugetlbfs/inode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04867
Уязвимость функции ext4_rename() модуля fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05734
Уязвимость функции __dev_queue_xmit() модуля net/core/filter.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05769
Уязвимость подсистемы switchdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05859
Уязвимость функции ext4_unlink() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05861
Уязвимость функции ioctl() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05863
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05951
Уязвимость функций pci_init_afu() и cxl_pci_init_adapter() модуля drivers/misc/cxl/pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05954
Уязвимость функции sock_map_free() модуля net/core/sock_map.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05955
Уязвимость функции moxart_probe() модуля drivers/mmc/host/moxart-mmc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05968
Уязвимость функции sc7180_lpass_init() модуля sound/soc/qcom/lpass-sc7180.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05969
Уязвимость функции cxl_calc_capp_routing() модуля drivers/misc/cxl/pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05970
Уязвимость функции hswep_has_limit_sbox() модуля arch/x86/events/intel/uncore_snbep.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05972
Уязвимость функции rtsx_usb_sdmmc_drv_probe() модуля drivers/mmc/host/rtsx_usb_sdmmc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05973
Уязвимость функции tifm_7xx1_switch_media() модуля drivers/misc/tifm_7xx1.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05974
Уязвимость функции wmt_mci_probe() модуля drivers/mmc/host/wmt-sdmmc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05975
Уязвимость функции __pskb_pull_tail() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05977
Уязвимость функции padata_do_parallel() модуля kernel/padata.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05980
Уязвимость функции integrity_init_keyring() модуля security/integrity/digsig.c подсистемы обеспечения безопасности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05981
Уязвимость функции md_bitmap_resize() модуля drivers/md/md-bitmap.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05983
Уязвимость функции fcoe_init() модуля drivers/scsi/fcoe/fcoe.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06000
Уязвимость функции ext4_sb_release() модуля fs/ext4/sysfs.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06027
Уязвимость функции md_end_flush() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06028
Уязвимость функции nfs_d_automount() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06070
Уязвимость функции iwl_mvm_tx_skb_sta() в модуле drivers/net/wireless/intel/iwlwifi/mvm/tx.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06072
Уязвимость функции az6027_i2c_xfer() в модуле drivers/media/usb/dvb-usb/az6027.c драйвера мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06073
Уязвимость функции power_supply_get_battery_info() в модуле drivers/power/supply/power_supply_core.c драйвера управления питанием ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06075
Уязвимость функции propagate_one() в модуле fs/pnode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06076
Уязвимость функции cdev_device_add() в модуле fs/char_dev.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06078
Уязвимость функции send_eject_command() в модуле drivers/net/wireless/ath/ath9k/hif_usb.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06082
Уязвимость функции vub300_enable_sdio_irq() в модуле drivers/mmc/host/vub300.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06085
Уязвимость функции mt8173_afe_pcm_dev_probe() в модуле sound/soc/mediatek/mt8173/mt8173-afe-pcm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06093
Уязвимость функции cros_usbpd_notify_init() в модуле drivers/platform/chrome/cros_usbpd_notify.c поддержки платформы оборудования Chrome OS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-28
CVE-2021-4454
In the Linux kernel, the following vulnerability has been resolved: can: j1939: fix errant WARN_ON_ONCE in j1939_session_deactivate The conclusion "j1939_session_deactivate() should be called with a session ref-count of at least 2" is incorrect. In some concurrent scenarios, j1939_session_deactivate can be called with the session ref-count less than 2. But there is not any problem because it will check the session active state before session putting in j1939_session_deactivate_locked(). Here is the concurrent scenario of the problem reported by syzbot and my reproduction log. cpu0 cpu1 j1939_xtp_rx_eoma j1939_xtp_rx_abort_one j1939_session_get_by_addr [kref == 2] j1939_session_get_by_addr [kref == 3] j1939_session_deactivate [kref == 2] j1939_session_put [kref == 1] j1939_session_completed j1939_session_deactivate WARN_ON_ONCE(kref < 2) ===================================================== WARNING: CPU: 1 PID: 21 at net/can/j1939/transport.c:1088 j1939_session_deactivate+0x5f/0x70 CPU: 1 PID: 21 Comm: ksoftirqd/1 Not tainted 5.14.0-rc7+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:j1939_session_deactivate+0x5f/0x70 Call Trace: j1939_session_deactivate_activate_next+0x11/0x28 j1939_xtp_rx_eoma+0x12a/0x180 j1939_tp_recv+0x4a2/0x510 j1939_can_recv+0x226/0x380 can_rcv_filter+0xf8/0x220 can_receive+0x102/0x220 ? process_backlog+0xf0/0x2c0 can_rcv+0x53/0xf0 __netif_receive_skb_one_core+0x67/0x90 ? process_backlog+0x97/0x2c0 __netif_receive_skb+0x22/0x80
- https://git.kernel.org/stable/c/1740a1e45eee65099a92fb502e1e67e63aad277d
- https://git.kernel.org/stable/c/6950df42a03c9ac9290503ced3f371199cb68fa9
- https://git.kernel.org/stable/c/9ab896775f98ff54b68512f345eed178bf961084
- https://git.kernel.org/stable/c/b6d44072117bba057d50f7a2f96e5d070c65926d
- https://git.kernel.org/stable/c/d0553680f94c49bbe0e39eb50d033ba563b4212d
Modified: 2025-02-13
CVE-2022-2196
A regression exists in the Linux Kernel within KVM: nVMX that allowed for speculative execution attacks. L2 can carry out Spectre v2 attacks on L1 due to L1 thinking it doesn't need retpolines or IBPB after running L2 due to KVM (L0) advertising eIBRS support to L1. An attacker at L2 with code execution can execute code on an indirect branch on the host machine. We recommend upgrading to Kernel 6.2 or past commit 2e7eab81425a
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5
- https://kernel.dance/#2e7eab81425a
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5
- https://kernel.dance/#2e7eab81425a
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://security.netapp.com/advisory/ntap-20230223-0002/
Modified: 2025-03-06
CVE-2022-3424
A use-after-free flaw was found in the Linux kernel’s SGI GRU driver in the way the first gru_file_unlocked_ioctl function is called by the user, where a fail pass occurs in the gru_check_chiplet_assignment function. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2132640
- https://github.com/torvalds/linux/commit/643a16a0eb1d6ac23744bb6e90a00fc21148a9dc
- 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/20221019031445.901570-1-zyytlz.wz%40163.com/
- https://security.netapp.com/advisory/ntap-20230406-0005/
- https://www.spinics.net/lists/kernel/msg4518970.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2132640
- https://github.com/torvalds/linux/commit/643a16a0eb1d6ac23744bb6e90a00fc21148a9dc
- 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/20221019031445.901570-1-zyytlz.wz%40163.com/
- https://security.netapp.com/advisory/ntap-20230406-0005/
- https://www.spinics.net/lists/kernel/msg4518970.html
Modified: 2024-11-21
CVE-2022-3545
A vulnerability has been found in Linux Kernel and classified as critical. Affected by this vulnerability is the function area_cache_get of the file drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211045 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20221223-0003/
- https://vuldb.com/?id.211045
- https://www.debian.org/security/2023/dsa-5324
- https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20221223-0003/
- https://vuldb.com/?id.211045
- https://www.debian.org/security/2023/dsa-5324
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: 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: 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: 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-12-31
CVE-2022-48708
In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix potential NULL dereference Added checking of pointer "function" in pcs_set_mux(). pinmux_generic_get_function() can return NULL and the pointer "function" was dereferenced without checking against NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/1177bdafe87cbe543a2dc48a9bbac265aa5864db
- https://git.kernel.org/stable/c/2b763f7de108cb1a5ad5ed08e617d677341947cb
- https://git.kernel.org/stable/c/6e2a0521e4e84a2698f2da3950fb5c5496a4d208
- https://git.kernel.org/stable/c/71668706fbe7d20e6f172fa3287fa8aac1b56c26
- https://git.kernel.org/stable/c/bcc487001a15f71f103d102cba4ac8145d7a68f2
- https://git.kernel.org/stable/c/d2d73e6d4822140445ad4a7b1c6091e0f5fe703b
- https://git.kernel.org/stable/c/e671e63587c92b3fd767cf82e73129f6d5feeb33
- https://git.kernel.org/stable/c/1177bdafe87cbe543a2dc48a9bbac265aa5864db
- https://git.kernel.org/stable/c/2b763f7de108cb1a5ad5ed08e617d677341947cb
- https://git.kernel.org/stable/c/6e2a0521e4e84a2698f2da3950fb5c5496a4d208
- https://git.kernel.org/stable/c/71668706fbe7d20e6f172fa3287fa8aac1b56c26
- https://git.kernel.org/stable/c/bcc487001a15f71f103d102cba4ac8145d7a68f2
- https://git.kernel.org/stable/c/d2d73e6d4822140445ad4a7b1c6091e0f5fe703b
- https://git.kernel.org/stable/c/e671e63587c92b3fd767cf82e73129f6d5feeb33
Modified: 2024-09-06
CVE-2022-48869
In the Linux kernel, the following vulnerability has been resolved:
USB: gadgetfs: Fix race between mounting and unmounting
The syzbot fuzzer and Gerald Lee have identified a use-after-free bug
in the gadgetfs driver, involving processes concurrently mounting and
unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super()
can race with gadgetfs_kill_sb(), causing the latter to deallocate
the_device while the former is using it. The output from KASAN says,
in part:
BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]
BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]
BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]
BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689
CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/616fd34d017000ecf9097368b13d8a266f4920b3
- https://git.kernel.org/stable/c/856e4b5e53f21edbd15d275dde62228dd94fb2b4
- https://git.kernel.org/stable/c/9a39f4626b361ee7aa10fd990401c37ec3b466ae
- https://git.kernel.org/stable/c/a2e075f40122d8daf587db126c562a67abd69cf9
- https://git.kernel.org/stable/c/d18dcfe9860e842f394e37ba01ca9440ab2178f4
Modified: 2024-09-06
CVE-2022-48871
In the Linux kernel, the following vulnerability has been resolved: tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer.
Modified: 2024-09-06
CVE-2022-48872
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free race condition for maps It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted. Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted. Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall
- https://git.kernel.org/stable/c/079c78c68714f7d8d58e66c477b0243b31806907
- https://git.kernel.org/stable/c/556dfdb226ce1e5231d8836159b23f8bb0395bf4
- https://git.kernel.org/stable/c/61a0890cb95afec5c8a2f4a879de2b6220984ef1
- https://git.kernel.org/stable/c/96b328d119eca7563c1edcc4e1039a62e6370ecb
- https://git.kernel.org/stable/c/b171d0d2cf1b8387c72c8d325c5d5746fa271e39
Modified: 2024-09-06
CVE-2022-48873
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Don't remove map on creater_process and device_release Do not remove the map from the list on error path in fastrpc_init_create_process, instead call fastrpc_map_put, to avoid use-after-free. Do not remove it on fastrpc_device_release either, call fastrpc_map_put instead. The fastrpc_free_map is the only proper place to remove the map. This is called only after the reference count is 0.
- https://git.kernel.org/stable/c/193cd853145b63e670bd73740250983af1475330
- https://git.kernel.org/stable/c/1b7b7bb400dd13dcb03fc6e591bb7ca4664bbec8
- https://git.kernel.org/stable/c/35ddd482345c43d9eec1f3406c0f20a95ed4054b
- https://git.kernel.org/stable/c/4b5c44e924a571d0ad07054de549624fbc04e4d7
- https://git.kernel.org/stable/c/5bb96c8f9268e2fdb0e5321cbc358ee5941efc15
Modified: 2024-09-04
CVE-2022-48875
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: sdata can be NULL during AMPDU start
ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a
deauthentication is ongoing.
Here a trace triggering the race with the hostapd test
multi_ap_fronthaul_on_ap:
(gdb) list *drv_ampdu_action+0x46
0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).
391 int ret = -EOPNOTSUPP;
392
393 might_sleep();
394
395 sdata = get_bss_sdata(sdata);
396 if (!check_sdata_in_driver(sdata))
397 return -EIO;
398
399 trace_drv_ampdu_action(local, sdata, params);
400
wlan0: moving STA 02:00:00:00:03:00 to state 3
wlan0: associated
wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)
wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0
wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)
wlan0: moving STA 02:00:00:00:03:00 to state 2
wlan0: moving STA 02:00:00:00:03:00 to state 1
wlan0: Removed STA 02:00:00:00:03:00
wlan0: Destroyed STA 02:00:00:00:03:00
BUG: unable to handle page fault for address: fffffffffffffb48
PGD 11814067 P4D 11814067 PUD 11816067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Workqueue: phy3 ieee80211_ba_session_work [mac80211]
RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]
Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85
RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287
RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240
RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40
RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0
R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8
FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0
Call Trace:
Modified: 2024-09-05
CVE-2022-48877
In the Linux kernel, the following vulnerability has been resolved: f2fs: let's avoid panic if extent_tree is not created This patch avoids the below panic. pc : __lookup_extent_tree+0xd8/0x760 lr : f2fs_do_write_data_page+0x104/0x87c sp : ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 x26: ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e90900 x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: ffffff802da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9 : ffffff8023195800 x8 : ffffff802da49078 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0000000000000006 x4 : ffffffc010cbba28 x3 : 0000000000000000 x2 : ffffffc010cbb480 x1 : 0000000000000000 x0 : ffffff8803e7ed40 Call trace: __lookup_extent_tree+0xd8/0x760 f2fs_do_write_data_page+0x104/0x87c f2fs_write_single_data_page+0x420/0xb60 f2fs_write_cache_pages+0x418/0xb1c __f2fs_write_data_pages+0x428/0x58c f2fs_write_data_pages+0x30/0x40 do_writepages+0x88/0x190 __writeback_single_inode+0x48/0x448 writeback_sb_inodes+0x468/0x9e8 __writeback_inodes_wb+0xb8/0x2a4 wb_writeback+0x33c/0x740 wb_do_writeback+0x2b4/0x400 wb_workfn+0xe4/0x34c process_one_work+0x24c/0x5bc worker_thread+0x3e8/0xa50 kthread+0x150/0x1b4
- https://git.kernel.org/stable/c/1c38cdc747f00daf7394535eae5afc4c503c59bb
- https://git.kernel.org/stable/c/2c129e868992621a739bdd57a5bffa3985ef1b91
- https://git.kernel.org/stable/c/557e85ff9afef6d45020b6f09357111d38033c31
- https://git.kernel.org/stable/c/72009139a661ade5cb1da4239734ed02fa1cfff0
- https://git.kernel.org/stable/c/dd83a9763e29ed7a21c8a43f7a62cd0a6bf74692
- https://git.kernel.org/stable/c/df9d44b645b83fffccfb4e28c1f93376585fdec8
- https://git.kernel.org/stable/c/ff85a1dbd90d29f73033177ff8d8de4a27d9721c
Modified: 2024-08-29
CVE-2022-48878
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Fix driver shutdown on closed serdev The driver shutdown callback (which sends EDL_SOC_RESET to the device over serdev) should not be invoked when HCI device is not open (e.g. if hci_dev_open_sync() failed), because the serdev and its TTY are not open either. Also skip this step if device is powered off (qca_power_shutdown()). The shutdown callback causes use-after-free during system reboot with Qualcomm Atheros Bluetooth: Unable to handle kernel paging request at virtual address 0072662f67726fd7 ... CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W 6.1.0-rt5-00325-g8a5f56bcfcca #8 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: tty_driver_flush_buffer+0x4/0x30 serdev_device_write_flush+0x24/0x34 qca_serdev_shutdown+0x80/0x130 [hci_uart] device_shutdown+0x15c/0x260 kernel_restart+0x48/0xac KASAN report: BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50 Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1 CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xdc/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x68/0x84 print_report+0x188/0x488 kasan_report+0xa4/0xf0 __asan_load8+0x80/0xac tty_driver_flush_buffer+0x1c/0x50 ttyport_write_flush+0x34/0x44 serdev_device_write_flush+0x48/0x60 qca_serdev_shutdown+0x124/0x274 device_shutdown+0x1e8/0x350 kernel_restart+0x48/0xb0 __do_sys_reboot+0x244/0x2d0 __arm64_sys_reboot+0x54/0x70 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x44/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xbc/0x140 el0t_64_sync+0x190/0x194
Modified: 2024-08-29
CVE-2022-48879
In the Linux kernel, the following vulnerability has been resolved: efi: fix NULL-deref in init error path In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated. Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer.
- https://git.kernel.org/stable/c/4ca71bc0e1995d15486cd7b60845602a28399cb5
- https://git.kernel.org/stable/c/585a0b2b3ae7903c6abee3087d09c69e955a7794
- https://git.kernel.org/stable/c/5fcf75a8a4c3e7ee9122d143684083c9faf20452
- https://git.kernel.org/stable/c/703c13fe3c9af557d312f5895ed6a5fda2711104
- https://git.kernel.org/stable/c/adc96d30f6503d30dc68670c013716f1d9fcc747
- https://git.kernel.org/stable/c/e2ea55564229e4bea1474af15b111b3a3043b76f
Modified: 2024-09-06
CVE-2022-48891
In the Linux kernel, the following vulnerability has been resolved: regulator: da9211: Use irq handler when ready If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us. If we enable the IRQ handler before its structures are ready, we crash. This patch fixes: [ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blocking_notifier_call_chain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c [ 1.327825] da9211_irq_handler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154
- https://git.kernel.org/stable/c/02228f6aa6a64d588bc31e3267d05ff184d772eb
- https://git.kernel.org/stable/c/1c1afcb8839b91c09d211ea304faa269763b1f91
- https://git.kernel.org/stable/c/470f6a9175f13a53810734658c35cc5bba33be01
- https://git.kernel.org/stable/c/ad1336274f733a7cb1f87b5c5908165a2c14df53
- https://git.kernel.org/stable/c/d443308edbfb6e9e757b478af908515110d1efd5
- https://git.kernel.org/stable/c/d4aa749e046435f054e94ebf50cad143d6229fae
- https://git.kernel.org/stable/c/f75cde714e0a67f73ef169aa50d4ed77d04f7236
Modified: 2024-09-11
CVE-2022-48896
In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix pci device refcount leak As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(), pci_dev_put() is called to avoid leak.
- https://git.kernel.org/stable/c/112df4cd2b09acd64bcd18f5ef83ba5d07b34bf0
- https://git.kernel.org/stable/c/4c93422a54cd6a349988f42e1c6bf082cf4ea9d8
- https://git.kernel.org/stable/c/53cefa802f070d46c0c518f4865be2c749818a18
- https://git.kernel.org/stable/c/b93fb4405fcb5112c5739c5349afb52ec7f15c07
- https://git.kernel.org/stable/c/c49996c6aa03590e4ef5add8772cb6068d99fd59
Modified: 2024-09-11
CVE-2022-48898
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set. Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption. Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID Changes in v2: -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr() -- add more commit text Changes in v3: -- add Stephen suggested -- dp_aux_isr() return IRQ_XXX back to caller -- dp_ctrl_isr() return IRQ_XXX back to caller Changes in v4: -- split into two patches Changes in v5: -- delete empty line between tags Changes in v6: -- remove extra "that" and fixed line more than 75 char at commit text Patchwork: https://patchwork.freedesktop.org/patch/516121/
Modified: 2024-09-11
CVE-2022-48899
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix GEM handle creation UAF Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object.
- https://git.kernel.org/stable/c/011ecdbcd520c90c344b872ca6b4821f7783b2f8
- https://git.kernel.org/stable/c/19ec87d06acfab2313ee82b2a689bf0c154e57ea
- https://git.kernel.org/stable/c/52531258318ed59a2dc5a43df2eaf0eb1d65438e
- https://git.kernel.org/stable/c/68bcd063857075d2f9edfed6024387ac377923e2
- https://git.kernel.org/stable/c/adc48e5e408afbb01d261bd303fd9fbbbaa3e317
- https://git.kernel.org/stable/c/d01d6d2b06c0d8390adf8f3ba08aa60b5642ef73
Modified: 2025-10-08
CVE-2022-48945
In the Linux kernel, the following vulnerability has been resolved:
media: vivid: fix compose size exceed boundary
syzkaller found a bug:
BUG: unable to handle page fault for address: ffffc9000a3b1000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:memcpy_erms+0x6/0x10
[...]
Call Trace:
- https://git.kernel.org/stable/c/2f558c5208b0f70c8140e08ce09fcc84da48e789
- https://git.kernel.org/stable/c/54f259906039dbfe46c550011409fa16f72370f6
- https://git.kernel.org/stable/c/5edc3604151919da8da0fb092b71d7dce07d848a
- https://git.kernel.org/stable/c/8c0ee15d9a102c732d0745566d254040085d5663
- https://git.kernel.org/stable/c/94a7ad9283464b75b12516c5512541d467cefcf8
- https://git.kernel.org/stable/c/9c7fba9503b826f0c061d136f8f0c9f953ed18b9
- https://git.kernel.org/stable/c/ab54081a2843aefb837812fac5488cc8f1696142
- https://git.kernel.org/stable/c/ccb5392c4fea0e7d9f7ab35567e839d74cb3998b
- https://git.kernel.org/stable/c/f9d19f3a044ca651b0be52a4bf951ffe74259b9f
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-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-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-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-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-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-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-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-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-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-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-48987
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-dv-timings.c: fix too strict blanking sanity checks Sanity checks were added to verify the v4l2_bt_timings blanking fields in order to avoid integer overflows when userspace passes weird values. But that assumed that userspace would correctly fill in the front porch, backporch and sync values, but sometimes all you know is the total blanking, which is then assigned to just one of these fields. And that can fail with these checks. So instead set a maximum for the total horizontal and vertical blanking and check that each field remains below that. That is still sufficient to avoid integer overflows, but it also allows for more flexibility in how userspace fills in these fields.
- https://git.kernel.org/stable/c/0d73b49c4037199472b29574ae21c21aef493971
- https://git.kernel.org/stable/c/2572ab14b73aa45b6ae7e4c089ccf119fed5cf89
- https://git.kernel.org/stable/c/32f01f0306a98629508f84d7ef0d1d037bc274a2
- https://git.kernel.org/stable/c/4afc77068e36cee45b39d4fdc7513de26980f72c
- https://git.kernel.org/stable/c/5eef2141776da02772c44ec406d6871a790761ee
- https://git.kernel.org/stable/c/6fb8bc29bfa80707994a63cc97e2f9920e0b0608
- https://git.kernel.org/stable/c/a2b56627c0d13009e02f6f2c0206c0451ed19a0e
- https://git.kernel.org/stable/c/d3d14cdf1c7ae2caa3e999bae95ba99e955fb7c3
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-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-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-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-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-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-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-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-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-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-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-49139
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL.
- https://git.kernel.org/stable/c/0f9db1209f59844839175b5b907d3778cafde93d
- https://git.kernel.org/stable/c/1c1291a84e94f6501644634c97544bb8291e9a1a
- https://git.kernel.org/stable/c/3afee2118132e93e5f6fa636dfde86201a860ab3
- https://git.kernel.org/stable/c/c1aa0dd52db4ce888be0bd820c3fa918d350ca0b
- https://git.kernel.org/stable/c/f61c23e73dc653b957781066abfa8105c3fa3f5b
Modified: 2025-10-01
CVE-2022-49738
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on i_extra_isize in is_alive()
syzbot found a f2fs bug:
BUG: KASAN: slab-out-of-bounds in data_blkaddr fs/f2fs/f2fs.h:2891 [inline]
BUG: KASAN: slab-out-of-bounds in is_alive fs/f2fs/gc.c:1117 [inline]
BUG: KASAN: slab-out-of-bounds in gc_data_segment fs/f2fs/gc.c:1520 [inline]
BUG: KASAN: slab-out-of-bounds in do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734
Read of size 4 at addr ffff888076557568 by task kworker/u4:3/52
CPU: 1 PID: 52 Comm: kworker/u4:3 Not tainted 6.1.0-rc4-syzkaller-00362-gfef7fd48922d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
- https://git.kernel.org/stable/c/5b25035fb888cb2f78bf0b9c9f95b1dc54480d36
- https://git.kernel.org/stable/c/914e38f02a490dafd980ff0f39cccedc074deb29
- https://git.kernel.org/stable/c/97ccfffcc061e54ce87e4a51a40e2e9cb0b7076a
- https://git.kernel.org/stable/c/d3b7b4afd6b2c344eabf9cc26b8bfa903c164c7c
- https://git.kernel.org/stable/c/e5142a4935c1f15841d06047b8130078fc4d7b8f
Modified: 2025-10-01
CVE-2022-49740
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads This patch fixes slab-out-of-bounds reads in brcmfmac that occur in brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count value of channel specifications provided by the device is greater than the length of 'list->element[]', decided by the size of the 'list' allocated with kzalloc(). The patch adds checks that make the functions free the buffer and return -EINVAL if that is the case. Note that the negative return is handled by the caller, brcmf_setup_wiphybands() or brcmf_cfg80211_attach(). Found by a modified version of syzkaller. Crash Report from brcmf_construct_chaninfo(): ================================================================== BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430 Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896 CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0.cold+0x93/0x334 kasan_report.cold+0x83/0xdf brcmf_setup_wiphybands+0x1238/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 Allocated by task 1896: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 kmem_cache_alloc_trace+0x19e/0x330 brcmf_setup_wiphybands+0x290/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888115f24000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1536 bytes inside of 2048-byte region [ffff888115f24000, ffff888115f24800) Memory state around the buggy address: ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Crash Report from brcmf_enable_bw40_2g(): ========== ---truncated---
- https://git.kernel.org/stable/c/4920ab131b2dbae7464b72bdcac465d070254209
- https://git.kernel.org/stable/c/9cf5e99c1ae1a85286a76c9a970202750538394c
- https://git.kernel.org/stable/c/b2e412879595821ff1b5545cbed5f108fba7f5b6
- https://git.kernel.org/stable/c/e4991910f15013db72f6ec0db7038ea67a57052e
- https://git.kernel.org/stable/c/f06de1bb6d61f0c18b0213bbc6298960037f9d42
Modified: 2025-10-01
CVE-2022-49741
In the Linux kernel, the following vulnerability has been resolved:
fbdev: smscufx: fix error handling code in ufx_usb_probe
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0xffff88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.............
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/1b4c08844628dfc8d72d3f51b657f2a5e63b7b4b
- https://git.kernel.org/stable/c/3931014367ef31d26af65386a4ca496f50f0cfdf
- https://git.kernel.org/stable/c/3b3d3127f5b4291ae4caaf50f7b66089ad600480
- https://git.kernel.org/stable/c/64fa364ad3245508d393e16ed4886f92d7eb423c
- https://git.kernel.org/stable/c/b76449ee75e21acfe9fa4c653d8598f191ed7d68
Modified: 2025-10-01
CVE-2022-49746
In the Linux kernel, the following vulnerability has been resolved: dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init If the function sdma_load_context() fails, the sdma_desc will be freed, but the allocated desc->bd is forgot to be freed. We already met the sdma_load_context() failure case and the log as below: [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready ... In this case, the desc->bd will not be freed without this change.
- https://git.kernel.org/stable/c/1417f59ac0b02130ee56c0c50794b9b257be3d17
- https://git.kernel.org/stable/c/43acd767bd90c5d4172ce7fee5d9007a9a08dea9
- https://git.kernel.org/stable/c/80ee99e52936b2c04cc37b17a14b2ae2f9d282ac
- https://git.kernel.org/stable/c/bd0050b7ffa87c7b260d563646af612f4112a778
- https://git.kernel.org/stable/c/ce4745a6b8016fae74c95dcd457d4ceef7d98af1
- https://git.kernel.org/stable/c/dbe634ce824329d8f14079c3e9f8f11670894bec
Modified: 2025-10-01
CVE-2022-49748
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: fix potential integer overflow on shift of a int The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then passed as a 64 bit function argument. In the case where i is 32 or more this can lead to an overflow. Avoid this by shifting using the BIT_ULL macro instead.
- https://git.kernel.org/stable/c/08245672cdc6505550d1a5020603b0a8d4a6dcc7
- https://git.kernel.org/stable/c/14cc13e433e1067557435b1adbf05608d7d47a93
- https://git.kernel.org/stable/c/a4d01fb87ece45d4164fd725890211ccf9a307a9
- https://git.kernel.org/stable/c/f84c9b72fb200633774704d8020f769c88a4b249
- https://git.kernel.org/stable/c/fbf7b0e4cef3b5470b610f14fb9faa5ee7f63954
Modified: 2025-10-01
CVE-2022-49749
In the Linux kernel, the following vulnerability has been resolved: i2c: designware: use casting of u64 in clock multiplication to avoid overflow In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow by depending on the values of the given parameters including the ic_clk. For example in our use case where ic_clk is larger than one million, multiplication of ic_clk * 4700 will result in 32 bit overflow. Add cast of u64 to the calculation to avoid multiplication overflow, and use the corresponding define for divide.
Modified: 2025-10-01
CVE-2022-49751
In the Linux kernel, the following vulnerability has been resolved: w1: fix WARNING after calling w1_process() I got the following WARNING message while removing driver(ds2482): ------------[ cut here ]------------ do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Call Trace: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30 The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(), set it to TASK_RUNNING when it breaks out of the loop to avoid the warning.
- https://git.kernel.org/stable/c/190b5c3bbd5df685bb1063bda048831d72b8f1d4
- https://git.kernel.org/stable/c/216f35db6ec6a667cd9db4838d657c1d2f4684da
- https://git.kernel.org/stable/c/276052159ba94d4d9f5b453fb4707d6798c6b845
- https://git.kernel.org/stable/c/36225a7c72e9e3e1ce4001b6ce72849f5c9a2d3b
- https://git.kernel.org/stable/c/89c62cee5d4d65ac75d99b5f986f7f94290e888f
- https://git.kernel.org/stable/c/bccd6df4c177b1ad766f16565ccc298653d027d0
- https://git.kernel.org/stable/c/cfc7462ff824ed6718ed0272ee9aae88e20d469a
Modified: 2025-04-01
CVE-2022-49753
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: Fix double increment of client_count in dma_chan_get()
The first time dma_chan_get() is called for a channel the channel
client_count is incorrectly incremented twice for public channels,
first in balance_ref_count(), and again prior to returning. This
results in an incorrect client count which will lead to the
channel resources not being freed when they should be. A simple
test of repeated module load and unload of async_tx on a Dell
Power Edge R7425 also shows this resulting in a kref underflow
warning.
[ 124.329662] async_tx: api initialized (async)
[ 129.000627] async_tx: api initialized (async)
[ 130.047839] ------------[ cut here ]------------
[ 130.052472] refcount_t: underflow; use-after-free.
[ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28
refcount_warn_saturate+0xba/0x110
[ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr
intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm
mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si
syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops
k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat
fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul
libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas
i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: async_tx]
[ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not
tainted 5.14.0-185.el9.x86_64 #1
[ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS
1.18.0 01/17/2022
[ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110
[ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d
26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a
bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff
48 c7
[ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286
[ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000
[ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0
[ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff
[ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970
[ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000)
knlGS:0000000000000000
[ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0
[ 130.219729] Call Trace:
[ 130.222192]
- https://git.kernel.org/stable/c/142d644fd2cc059ffa042fbfb68e766433ef3afd
- https://git.kernel.org/stable/c/18dd3b30d4c7e8440c63118c7a7b687372b9567f
- https://git.kernel.org/stable/c/1b409e14b4b7af034e0450f95c165b6c5c87dbc1
- https://git.kernel.org/stable/c/42ecd72f02cd657b00b559621e7ef7d2c4d3e5f1
- https://git.kernel.org/stable/c/71c601965532c38030133535f7cd93c1efa75af1
- https://git.kernel.org/stable/c/c6221afe573413fd2981e291f7df4a58283e0654
- https://git.kernel.org/stable/c/f3dc1b3b4750851a94212dba249703dd0e50bb20
Modified: 2025-04-01
CVE-2022-49755
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait While performing fast composition switch, there is a possibility that the process of ffs_ep0_write/ffs_ep0_read get into a race condition due to ep0req being freed up from functionfs_unbind. Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't bounded so it can go ahead and mark the ep0req to NULL, and since there is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free. Fix this by making a serialized execution between the two functions using a mutex_lock(ffs->mutex).
- https://git.kernel.org/stable/c/6a19da111057f69214b97c62fb0ac59023970850
- https://git.kernel.org/stable/c/6aee197b7fbcd61596a78b47d553f2f99111f217
- https://git.kernel.org/stable/c/6dd9ea05534f323668db94fcc2726c7a84547e78
- https://git.kernel.org/stable/c/a8d40942df074f4ebcb9bd3413596d92f323b064
- https://git.kernel.org/stable/c/ae8e136bcaae96163b5821984de1036efc9abb1a
- https://git.kernel.org/stable/c/e9036e951f93fb8d7b5e9d6e2c7f94a4da312ae4
- https://git.kernel.org/stable/c/facf353c9e8d7885b686d9a4b173d4e0af6441d2
Modified: 2025-10-01
CVE-2022-49757
In the Linux kernel, the following vulnerability has been resolved: EDAC/highbank: Fix memory leak in highbank_mc_probe() When devres_open_group() fails, it returns -ENOMEM without freeing memory allocated by edac_mc_alloc(). Call edac_mc_free() on the error handling path to avoid a memory leak. [ bp: Massage commit message. ]
- https://git.kernel.org/stable/c/0db40e23b56d217eebd385bebb64057ef764b2c7
- https://git.kernel.org/stable/c/329fbd260352a7b9a83781d8b8bd96f95844a51f
- https://git.kernel.org/stable/c/8d23f5d25264beb223ee79cdb530b88c237719fc
- https://git.kernel.org/stable/c/b7863ef8a8f0fee96b4eb41211f4918c0e047253
- https://git.kernel.org/stable/c/caffa7fed1397d1395052272c93900176de86557
- https://git.kernel.org/stable/c/e7a293658c20a7945014570e1921bf7d25d68a36
- https://git.kernel.org/stable/c/f1b3e23ed8df87d779ee86ac37f379e79a24169a
Modified: 2025-04-01
CVE-2022-49761
In the Linux kernel, the following vulnerability has been resolved: btrfs: always report error in run_one_delayed_ref() Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but if end users hit such problem, there will be no chance that btrfs_debug() is enabled. This can lead to very little useful info for debugging. This patch will: - Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod - Replace the btrfs_debug() with btrfs_err() - Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller. This error should only be triggered at most once. As if run_one_delayed_ref() failed, we trigger the error message, then causing the call chain to error out: btrfs_run_delayed_refs() `- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref() And we will abort the current transaction in btrfs_run_delayed_refs(). If we have to run delayed refs for the abort transaction, run_one_delayed_ref() will just cleanup the refs and do nothing, thus no new error messages would be output.
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-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-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-11-14
CVE-2022-50001
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tproxy: restrict to prerouting hook TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this. This fixes a crash (null dereference) when using tproxy from e.g. output.
- https://git.kernel.org/stable/c/0b21edf4cc13516716848e0a4fdf726aa2a62cd9
- https://git.kernel.org/stable/c/18bbc3213383a82b05383827f4b1b882e3f0a5a5
- https://git.kernel.org/stable/c/343fed6b0daeb528ae5c9d4d84d9ff763ac95619
- https://git.kernel.org/stable/c/83ef55c4281f1b4c6bd4457c2e96ccd1c9e80200
- https://git.kernel.org/stable/c/9a1d92cbeac3335fee99fa865b8c5b0f2e71a8f7
- https://git.kernel.org/stable/c/eaba3f9b672c3a3f820da8ee9584b9520674eafa
Modified: 2025-11-24
CVE-2022-50242
In the Linux kernel, the following vulnerability has been resolved: drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init() If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp needs to be freed.
- https://git.kernel.org/stable/c/01de1123322e4fe1bbd0fcdf0982511b55519c03
- https://git.kernel.org/stable/c/0aefadf23ee5e33b747df195ace42d3be2025e4e
- https://git.kernel.org/stable/c/132c502919bb08e16e3054cb28bb7b149ec20cf5
- https://git.kernel.org/stable/c/14b349a15c297cf3e01b5deb4116f7cf297b6184
- https://git.kernel.org/stable/c/15770edc01edfce773269e8a443ca8e420f6f859
- https://git.kernel.org/stable/c/8399b9893548c03fdb18be277bf99d985dbde925
- https://git.kernel.org/stable/c/a44490abaf00f5b0cc5c448a17eae331c6195d0a
- https://git.kernel.org/stable/c/aa2d179544b6815b4a23c0c44543ba0971d49fce
- https://git.kernel.org/stable/c/dcae92a249551d1a447804b4be1c9fab0e8c95e8
Modified: 2025-11-24
CVE-2022-50244
In the Linux kernel, the following vulnerability has been resolved: cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter() If device_register() fails in cxl_pci_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails.
- https://git.kernel.org/stable/c/02cd3032b154fa02fdf90e7467abaeed889330b2
- https://git.kernel.org/stable/c/0f63c0ddc2ea20d783d29243f4dbe0f9e95dfdec
- https://git.kernel.org/stable/c/139abd4c626a6f7ce02789ed5f73aa2256e0542b
- https://git.kernel.org/stable/c/22511eefa61db26e12c97dd7ada3071dbdfcb004
- https://git.kernel.org/stable/c/2f5fd31b2f24b9b8a80ab566fd8c4e1e94cb4339
- https://git.kernel.org/stable/c/361412dae1690d4b5df6f92fc943cdc773c95cbc
- https://git.kernel.org/stable/c/82e5481428faf11c79b9c094dd24a1849bbf64ac
- https://git.kernel.org/stable/c/82e68432668ae75b4c814d160f6987ecb0681273
- https://git.kernel.org/stable/c/c4b2e35df919d99bbbed033c2fa0b607f9f463b5
Modified: 2025-11-24
CVE-2022-50245
In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible UAF when kfifo_alloc() fails If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free priv. But priv is still in the chdev->file_list, then list traversal may cause UAF. This fixes the following smatch warning: drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list
- https://git.kernel.org/stable/c/02d7d89f816951e0862147d751b1150d67aaebdd
- https://git.kernel.org/stable/c/2a6c75adf8192f07ddcdd4a1a13488c890a73919
- https://git.kernel.org/stable/c/2ba06e57f933f0eac242e8b389433da1cc00d4d5
- https://git.kernel.org/stable/c/2dfd60724d271a6ab99f93f40f38f2ced1ddbb87
- https://git.kernel.org/stable/c/2f5cc7fd73fd6253cc71214f0dd499cc62feb469
- https://git.kernel.org/stable/c/311b488405ac45af46756b1c8f1d27007b68b07e
- https://git.kernel.org/stable/c/5ee850645e42f541ce1ea8130c2b27cc495f965c
- https://git.kernel.org/stable/c/a253dde0403a153075ffb254f6f7b2635e49e97a
- https://git.kernel.org/stable/c/cb87af2c19c0993f6e21f75b963a5599c5a73e76
Modified: 2025-11-24
CVE-2022-50246
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpci: fix of node refcount leak in tcpci_register_port() I got the following report while doing device(mt6370-tcpc) 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 /i2c/pmic@34/tcpc/connector The 'fwnode' set in tcpci_parse_config() which is called in tcpci_register_port(), its node refcount is increased in device_get_named_child_node(). It needs be put while exiting, so call fwnode_handle_put() in the error path of tcpci_register_port() and in tcpci_unregister_port() to avoid leak.
- https://git.kernel.org/stable/c/0384e87e3fec735e47f1c133c796f32ef7a72a9b
- https://git.kernel.org/stable/c/4f257e2eba419ab4cd880c822346450e4e7b2af3
- https://git.kernel.org/stable/c/5f125507d2270035dfcf83fbff6cff5a143e200c
- https://git.kernel.org/stable/c/ba75be6f0d9d028d20852564206565a4c03e3288
- https://git.kernel.org/stable/c/d3b6c28a71f111a6c67ddc3238aab95910fd86cf
- https://git.kernel.org/stable/c/e75a324409715bd71348f79a49aa61b69dbeb676
Modified: 2025-11-25
CVE-2022-50248
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix double free on tx path.
We see kernel crashes and lockups and KASAN errors related to ax210
firmware crashes. One of the KASAN dumps pointed at the tx path,
and it appears there is indeed a way to double-free an skb.
If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the
method will be freed. But, in case where we build TSO skb buffer,
the skb may also be freed in error case. So, return 0 in that particular
error case and do cleanup manually.
BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000000 | tsf hi
Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650
CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5
iwlwifi 0000:06:00.0: 0x00000000 | time gp1
Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019
Call Trace:
- https://git.kernel.org/stable/c/0473cbae2137b963bd0eaa74336131cb1d3bc6c3
- https://git.kernel.org/stable/c/0e1e311fd929c6a8dcfddcb4748c47b07e39821f
- https://git.kernel.org/stable/c/3a2ecd1ec14075117ccb3e85f0fed224578ec228
- https://git.kernel.org/stable/c/8fabe41fba907e4fd826acbbdb42e09c681c515e
- https://git.kernel.org/stable/c/ae966649f665bc3868b935157dd4a3c31810dcc0
- https://git.kernel.org/stable/c/d8e32f1bf1a9183a6aad560c6688500222d24299
Modified: 2025-11-25
CVE-2022-50250
In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix use_count leakage when handling boot-on I found a use_count leakage towards supply regulator of rdev with boot-on option. ┌───────────────────┐ ┌───────────────────┐ │ regulator_dev A │ │ regulator_dev B │ │ (boot-on) │ │ (boot-on) │ │ use_count=0 │◀──supply──│ use_count=1 │ │ │ │ │ └───────────────────┘ └───────────────────┘ In case of rdev(A) configured with `regulator-boot-on', the use_count of supplying regulator(B) will increment inside regulator_enable(rdev->supply). Thus, B will acts like always-on, and further balanced regulator_enable/disable cannot actually disable it anymore. However, B was also configured with `regulator-boot-on', we wish it could be disabled afterwards.
- https://git.kernel.org/stable/c/0591b14ce0398125439c759f889647369aa616a0
- https://git.kernel.org/stable/c/4b737246ff50f810d6ab4be13c1388a07f0c14b1
- https://git.kernel.org/stable/c/4dd6e1cc9c7403f1ee1b7eee85bc31b797ae8347
- https://git.kernel.org/stable/c/5bfc53df288e8ea54ca6866fb92034214940183f
- https://git.kernel.org/stable/c/bc6c381df5793ebcf32db88a3e65acf7870379fc
- https://git.kernel.org/stable/c/dc3391d49479bc2bf8a2b88dbf86fdd800882fee
- https://git.kernel.org/stable/c/feb847e6591e8c7a09cc39721cc9ca74fd9a5d80
Modified: 2025-11-26
CVE-2022-50251
In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, the timer added before mmc_add_host() needs be del. And this patch fixes another missing call mmc_free_host() if usb_control_msg() fails.
- https://git.kernel.org/stable/c/0613ad2401f88bdeae5594c30afe318e93b14676
- https://git.kernel.org/stable/c/2044b2ea77945f372ef161d1bbf814e471767ff2
- https://git.kernel.org/stable/c/25f05d762ca5e1c685002a53dd44f68e78ca3feb
- https://git.kernel.org/stable/c/3049a3b927a40d89d4582ff1033cd7953be773c7
- https://git.kernel.org/stable/c/3b29f8769d32016b2d89183db4d80c7a71b7e35e
- https://git.kernel.org/stable/c/41ed46bdbd2878cd6567abe0974a445f8b1b8ec8
- https://git.kernel.org/stable/c/a46e681151bbdacdf6b89ee8c4e5bad0555142bb
- https://git.kernel.org/stable/c/afc898019e7bf18c5eb7a0ac19852fcb1b341b3c
- https://git.kernel.org/stable/c/c9e85979b59cb86f0a15defa8199d740e2b36b90
Modified: 2025-11-26
CVE-2022-50252
In the Linux kernel, the following vulnerability has been resolved: igb: Do not free q_vector unless new one was allocated Avoid potential use-after-free condition under memory pressure. If the kzalloc() fails, q_vector will be freed but left in the original adapter->q_vector[v_idx] array position.
- https://git.kernel.org/stable/c/0200f0fbb11e359cc35af72ab10b2ec224e6f633
- https://git.kernel.org/stable/c/0668716506ca66f90d395f36ccdaebc3e0e84801
- https://git.kernel.org/stable/c/314f7092b27749bdde44c14095b5533afa2a3bc8
- https://git.kernel.org/stable/c/3cb18dea11196fb4a06f78294cec5e61985e1aff
- https://git.kernel.org/stable/c/56483aecf6b22eb7dff6315b3a174688c6ad494c
- https://git.kernel.org/stable/c/64ca1969599857143e91aeec4440640656100803
- https://git.kernel.org/stable/c/68e8adbcaf7a8743e473343b38b9dad66e2ac6f3
- https://git.kernel.org/stable/c/6e399577bd397a517df4b938601108c63769ce0a
- https://git.kernel.org/stable/c/f96bd8adc8adde25390965a8c1ee81b73cb62075
Modified: 2025-11-26
CVE-2022-50253
In the Linux kernel, the following vulnerability has been resolved: bpf: make sure skb->len != 0 when redirecting to a tunneling device syzkaller managed to trigger another case where skb->len == 0 when we enter __dev_queue_xmit: WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline] WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295 Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6 The reproducer doesn't really reproduce outside of syzkaller environment, so I'm taking a guess here. It looks like we do generate correct ETH_HLEN-sized packet, but we redirect the packet to the tunneling device. Before we do so, we __skb_pull l2 header and arrive again at skb->len == 0. Doesn't seem like we can do anything better than having an explicit check after __skb_pull?
- https://git.kernel.org/stable/c/07ec7b502800ba9f7b8b15cb01dd6556bb41aaca
- https://git.kernel.org/stable/c/1b65704b8c08ae92db29f720d3b298031131da53
- https://git.kernel.org/stable/c/5d3f4478d22b2cb1810f6fe0f797411e9d87b3e5
- https://git.kernel.org/stable/c/6d935a02658be82585ecb39aab339faa84496650
- https://git.kernel.org/stable/c/772431f30ca040cfbf31b791d468bac6a9ca74d3
- https://git.kernel.org/stable/c/e6a63203e5a90a39392fa1a7ffc60f5e9baf642a
- https://git.kernel.org/stable/c/f186303845a01cc7e991f9dc51d7e5a3cdc7aedb
- https://git.kernel.org/stable/c/ffbccc5fb0a67424e12f7f8da210c04c8063f797
Modified: 2025-11-25
CVE-2022-50259
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: fix race in sock_map_free()
sock_map_free() calls release_sock(sk) without owning a reference
on the socket. This can cause use-after-free as syzbot found [1]
Jakub Sitnicki already took care of a similar issue
in sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:
Synchronize delete from bucket list on map free")
[1]
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Modules linked in:
CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: events_unbound bpf_map_free_deferred
RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff
RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246
RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0
RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000
RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5
R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004
R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0a182f8d607464911756b4dbef5d6cad8de22469
- https://git.kernel.org/stable/c/4cabc3af4a6f36c222fecb15858c1060e59218e7
- https://git.kernel.org/stable/c/5c3568166129bc73fd6b37748d2d8f95cd8f22f3
- https://git.kernel.org/stable/c/a443c55d96dede82a724df6e70a318ad15c199e1
- https://git.kernel.org/stable/c/be719496ae6a7fc325e9e5056a52f63ebc84cc0c
- https://git.kernel.org/stable/c/e8b2b392a646bf5cb9413c1cc7a39d99c1b65a62
Modified: 2025-11-25
CVE-2022-50261
In the Linux kernel, the following vulnerability has been resolved: drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid() 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. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hda_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_dvo_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure.
- https://git.kernel.org/stable/c/04371a75a58422a301a9ff9ae3babd310ac3bb3f
- https://git.kernel.org/stable/c/0ad811cc08a937d875cbad0149c1bab17f84ba05
- https://git.kernel.org/stable/c/511b48ee8e4aec2d03d2af06b363d9eb3230b017
- https://git.kernel.org/stable/c/6e3c4d3fa5d458d685561ecbaf8daa9dba14979e
- https://git.kernel.org/stable/c/8f9941dea3a70b73f2063f9dcc4aaae6af03c5ba
- https://git.kernel.org/stable/c/a075c21ee026f4a74f9fce5928ea3c8d18a8af13
- https://git.kernel.org/stable/c/b2c92b2a3801b09b709cbefd9a9e4944b72400bf
- https://git.kernel.org/stable/c/b4307c7d35e346b909edfdc1f280902150570bb6
- https://git.kernel.org/stable/c/e578b0906b6a81479cd5b5b6c848a7096addf5e9
Modified: 2025-12-02
CVE-2022-50264
In the Linux kernel, the following vulnerability has been resolved: clk: socfpga: Fix memory leak in socfpga_gate_init() Free @socfpga_clk and @ops on the error path to avoid memory leak issue.
- https://git.kernel.org/stable/c/0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b
- https://git.kernel.org/stable/c/3e8fd1d0fab4d5c9a50d225dddc207deac12f13a
- https://git.kernel.org/stable/c/6f2198914fb9aac286a6ff6cf09b23752141e04f
- https://git.kernel.org/stable/c/9de42116fc4540f6a1ceb51fd037b734ab7be12e
- https://git.kernel.org/stable/c/9f9bb9f5ba9fd501a90f255eb746b4cf2ceeaaae
- https://git.kernel.org/stable/c/bd72ab5e6fc1c4d3e6b84636141d26a41b977b03
Modified: 2025-12-03
CVE-2022-50268
In the Linux kernel, the following vulnerability has been resolved: mmc: moxart: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host().
- https://git.kernel.org/stable/c/0ca18d09c744fb030ae9bc5836c3e357e0237dea
- https://git.kernel.org/stable/c/40aa73c70e8a5706f9cbe01409a5e51cc0f1750e
- https://git.kernel.org/stable/c/7c3b301ca8b0cab392c71da8fcdfa499074f8e97
- https://git.kernel.org/stable/c/8f8bb62c7c5c833758ef1563fe738afd579c3efe
- https://git.kernel.org/stable/c/a4c765f5d8e58138cff69f1510b2e8942ec37022
- https://git.kernel.org/stable/c/a94d466f31a5201995d39bc1208e2c09ab04f0bf
- https://git.kernel.org/stable/c/b174f2b36c638fc7737df6c8aac1889a646be98f
- https://git.kernel.org/stable/c/c7e9a2059fb943fc3c3fa12261518fd72a0fc136
- https://git.kernel.org/stable/c/f0502fe86a2db2336c9498d2de3e97f22dcf85ae
Modified: 2025-12-03
CVE-2022-50272
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()
Wei Chen reports a kernel bug as blew:
general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
...
Call Trace:
- https://git.kernel.org/stable/c/0ed554fd769a19ea8464bb83e9ac201002ef74ad
- https://git.kernel.org/stable/c/210fcf64be4db82c0e190e74b5111e4eef661a7a
- https://git.kernel.org/stable/c/2b6a8a1a32746981044e7ab06649c804acb4068a
- https://git.kernel.org/stable/c/559891d430e3f3a178040c4371ed419edbfa7d65
- https://git.kernel.org/stable/c/6b60cf73a931af34b7a0a3f467a79d9fe0df2d70
- https://git.kernel.org/stable/c/6fbc44731a4665cbe92a5090e9804a388a72214b
- https://git.kernel.org/stable/c/7abfe467cd685f5da7ecb415441e45e3e4e2baa8
- https://git.kernel.org/stable/c/8b256d23361c51aa4b7fdb71176c1ca50966fb39
- https://git.kernel.org/stable/c/c712d1ccbfb787620422b437a5b8fac0802547bd
Modified: 2025-12-03
CVE-2022-50274
In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: adopts refcnt to avoid UAF dvb_unregister_device() is known that prone to use-after-free. That is, the cleanup from dvb_unregister_device() releases the dvb_device even if there are pointers stored in file->private_data still refer to it. This patch adds a reference counter into struct dvb_device and delays its deallocation until no pointer refers to the object.
- https://git.kernel.org/stable/c/0fc044b2b5e2d05a1fa1fb0d7f270367a7855d79
- https://git.kernel.org/stable/c/219b44bf94203bd433aa91b7796475bf656348e5
- https://git.kernel.org/stable/c/2abd73433872194bccdf1432a0980e4ec5273c2a
- https://git.kernel.org/stable/c/6d18b44bb44e1f4d97dfe0efe92ac0f0984739c2
- https://git.kernel.org/stable/c/88a6f8a72d167294c0931c7874941bf37a41b6dd
- https://git.kernel.org/stable/c/9945d05d6693710574f354c5dbddc47f5101eb77
- https://git.kernel.org/stable/c/a2f0a08aa613176c9688c81d7b598a7779974991
- https://git.kernel.org/stable/c/ac521bbe3d00fa574e66a9361763f2b37725bc97
Modified: 2025-12-03
CVE-2022-50275
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Add the missed acpi_put_table() to fix memory leak When the radeon driver reads the bios information from ACPI table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table() to release the ACPI memory after the init, so add acpi_put_table() properly to fix the memory leak. v2: fix text formatting (Alex)
- https://git.kernel.org/stable/c/10276a20be1115e1f76c189330da2992df980eee
- https://git.kernel.org/stable/c/4539e3211a9bd2418e76797718a4e60a7ae34fcf
- https://git.kernel.org/stable/c/4760fa67aff6bd8ef0b14c1fa04c295e734c7309
- https://git.kernel.org/stable/c/50113de0f1e913c0b733e21d3e61fe9c0f2e9d50
- https://git.kernel.org/stable/c/6d25bc63708145c10f9c099d5c005602a7f2ef5f
- https://git.kernel.org/stable/c/9e203e437310f61fdf3c1107f41f85864cf4f6b1
- https://git.kernel.org/stable/c/a0f26560be2c566b62331cb0eeffa52929aa4d44
- https://git.kernel.org/stable/c/b4b30f56ec512e2c35fc0761bc90b0e519d8fa6e
Modified: 2025-12-03
CVE-2022-50276
In the Linux kernel, the following vulnerability has been resolved: power: supply: fix null pointer dereferencing in power_supply_get_battery_info when kmalloc() fail to allocate memory in kasprintf(), propname will be NULL, strcmp() called by of_get_property() will cause null pointer dereference. So return ENOMEM if kasprintf() return NULL pointer.
- https://git.kernel.org/stable/c/104bb8a663451404a26331263ce5b96c34504049
- https://git.kernel.org/stable/c/279af90e65cbdb3e5c4519b0043324d7876bc5ec
- https://git.kernel.org/stable/c/5beadb55f4e36fafe5d6df5dcd5f85d803f3f134
- https://git.kernel.org/stable/c/8ea68b4e3fa9392ef9dae303abc8735a033c280f
- https://git.kernel.org/stable/c/b8131efb89d9f837c9244f900f0fc2699fd1181d
- https://git.kernel.org/stable/c/d21534ab4fd7883e1c8037a76671d4e8b6ea14cb
Modified: 2025-12-03
CVE-2022-50278
In the Linux kernel, the following vulnerability has been resolved: PNP: fix name memory leak in pnp_alloc_dev() After commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak.
- https://git.kernel.org/stable/c/110d7b0325c55ff3620073ba4201845f59e22ebf
- https://git.kernel.org/stable/c/1f50c7497a5f89de0c31f2edf086af41ff834320
- https://git.kernel.org/stable/c/290dd73b943c95c006df973257076ff163adf4d0
- https://git.kernel.org/stable/c/693a0c13c1f0c0fcaa1e38cb806cc0789bd415aa
- https://git.kernel.org/stable/c/81b024df4755e6bb6993b786584eca6eabbb9791
- https://git.kernel.org/stable/c/bbcf772216aa237036cc3ae3158288d0a95aaf4d
- https://git.kernel.org/stable/c/c12b314bb23dc0c83e03402cc84574700947e3b2
- https://git.kernel.org/stable/c/dac87e295cddc8ab316cff14ab2071b5221d84fa
- https://git.kernel.org/stable/c/ea77b4b761cd75e5456f677311babfa0418f289a
Modified: 2025-12-04
CVE-2022-50280
In the Linux kernel, the following vulnerability has been resolved: pnode: terminate at peers of source The propagate_mnt() function handles mount propagation when creating mounts and propagates the source mount tree @source_mnt to all applicable nodes of the destination propagation mount tree headed by @dest_mnt. Unfortunately it contains a bug where it fails to terminate at peers of @source_mnt when looking up copies of the source mount that become masters for copies of the source mount tree mounted on top of slaves in the destination propagation tree causing a NULL dereference. Once the mechanics of the bug are understood it's easy to trigger. Because of unprivileged user namespaces it is available to unprivileged users. While fixing this bug we've gotten confused multiple times due to unclear terminology or missing concepts. So let's start this with some clarifications: * The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group. * A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share. * The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list. * The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group. * Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked. * Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from. * A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group. If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mnt_master. IOW, all peers in peer group pg1 appear on the same ->mnt_slave_list. IOW, they cannot be slaves to different peer groups. * A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group. * A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mnt_master. IOW, all slave mounts such that @slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id. The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree. For example, in propagate_mnt() the immediate peers of @dest_mnt and all slaves of @dest_mnt's peer group form a propagation group pr ---truncated---
- https://git.kernel.org/stable/c/11933cf1d91d57da9e5c53822a540bbdc2656c16
- https://git.kernel.org/stable/c/2dae4211b579ce98985876a73a78466e285238ff
- https://git.kernel.org/stable/c/784a4f995ee24460aa72e00b085612fad57ebce5
- https://git.kernel.org/stable/c/7f57df69de7f05302fad584eb8e3f34de39e0311
- https://git.kernel.org/stable/c/b591b2919d018ef91b4a9571edca94105bcad3df
- https://git.kernel.org/stable/c/c24cc476acd8bccb5af54849aac5e779d8223bf5
- https://git.kernel.org/stable/c/cad0d17fb2b0540180ab59e2cd48ad348cc1ee4c
- https://git.kernel.org/stable/c/cc997490be65da0af8c75a6244fc80bb66c53ce0
- https://git.kernel.org/stable/c/e7c9f10c44a8919cd8bbd51b228c84d0caf7d518
Modified: 2025-12-04
CVE-2022-50282
In the Linux kernel, the following vulnerability has been resolved:
chardev: fix error handling in cdev_device_add()
While doing fault injection test, I got the following report:
------------[ cut here ]------------
kobject: '(null)' (0000000039956980): is not initialized, yet kobject_put() is being called.
WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0
CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:kobject_put+0x23d/0x4e0
Call Trace:
- https://git.kernel.org/stable/c/11fa7fefe3d8fac7da56bc9aa3dd5fb3081ca797
- https://git.kernel.org/stable/c/28dc61cc49c6e995121c6d86bef4b73df78dda80
- https://git.kernel.org/stable/c/34d17b39bceef25e4cf9805cd59250ae05d0a139
- https://git.kernel.org/stable/c/5d2146889fad4cb9e6c13e790d4cfd871486eca8
- https://git.kernel.org/stable/c/6acf8597c5b04f455ee0649e11e5f3bcd28f381e
- https://git.kernel.org/stable/c/85a5660491b507d33662b8e81c142e6041e642eb
- https://git.kernel.org/stable/c/b5de1eac71fec1af7723f1083d23a24789fd795c
- https://git.kernel.org/stable/c/c46db6088bccff5115674d583fef46ede80077a2
- https://git.kernel.org/stable/c/d85b5247a79355b8432bfd9ac871f96117f750d4
Modified: 2025-12-23
CVE-2022-50286
In the Linux kernel, the following vulnerability has been resolved: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline When converting files with inline data to extents, delayed allocations made on a file system created with both the bigalloc and inline options can result in invalid extent status cache content, incorrect reserved cluster counts, kernel memory leaks, and potential kernel panics. With bigalloc, the code that determines whether a block must be delayed allocated searches the extent tree to see if that block maps to a previously allocated cluster. If not, the block is delayed allocated, and otherwise, it isn't. However, if the inline option is also used, and if the file containing the block is marked as able to store data inline, there isn't a valid extent tree associated with the file. The current code in ext4_clu_mapped() calls ext4_find_extent() to search the non-existent tree for a previously allocated cluster anyway, which typically finds nothing, as desired. However, a side effect of the search can be to cache invalid content from the non-existent tree (garbage) in the extent status tree, including bogus entries in the pending reservation tree. To fix this, avoid searching the extent tree when allocating blocks for bigalloc + inline files that are being converted from inline to extent mapped.
- https://git.kernel.org/stable/c/131294c35ed6f777bd4e79d42af13b5c41bf2775
- https://git.kernel.org/stable/c/6f4200ec76a0d31200c308ec5a71c68df5417004
- https://git.kernel.org/stable/c/81b915181c630ee1cffa052e52874fe4e1ba91ac
- https://git.kernel.org/stable/c/9404839e0c9db5a517ea83c0ca3388b39d105fdf
- https://git.kernel.org/stable/c/c0c8edbc8abbe8f16d80a1d794d1ba2c12b6f193
- https://git.kernel.org/stable/c/d440d6427a5e3a877c1c259b8d2b216ddb65e185
- https://git.kernel.org/stable/c/f83391339d8493b9ff24167516aaa5a5e88d8f81
Modified: 2025-12-03
CVE-2022-50288
In the Linux kernel, the following vulnerability has been resolved: qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure adapter->dcb would get silently freed inside qlcnic_dcb_enable() in case qlcnic_dcb_attach() would return an error, which always happens under OOM conditions. This would lead to use-after-free because both of the existing callers invoke qlcnic_dcb_get_info() on the obtained pointer, which is potentially freed at that point. Propagate errors from qlcnic_dcb_enable(), and instead free the dcb pointer at callsite using qlcnic_dcb_free(). This also removes the now unused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around kfree() also causing memory leaks for partially initialized dcb. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/13a7c8964afcd8ca43c0b6001ebb0127baa95362
- https://git.kernel.org/stable/c/36999236f0b12d5de21a6f40e93b570727b9ceb2
- https://git.kernel.org/stable/c/513787ff9a331b461115e8a145a983d650a84fcb
- https://git.kernel.org/stable/c/8df1dc04ce0e4c03b51a756749c250a9cb17d707
- https://git.kernel.org/stable/c/8f97eeb02a553cdc78c83a0596448a370e1518c4
- https://git.kernel.org/stable/c/95df720e64a6409d8152827a776c43f615e3321a
- https://git.kernel.org/stable/c/a2a694e6edbdb3efb34e1613a31fdcf6cf444a55
- https://git.kernel.org/stable/c/d12a7510293d3370b234b0b7c5eda33e58786768
Modified: 2025-12-03
CVE-2022-50289
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix memory leak in ocfs2_stack_glue_init() ocfs2_table_header should be free in ocfs2_stack_glue_init() if ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak. BUG: memory leak unreferenced object 0xffff88810eeb5800 (size 128): comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s) hex dump (first 32 bytes): c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@.............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0 [<00000000c04f70f7>] 0xffffffffa0050037 [<000000001bd12912>] do_one_initcall+0xdb/0x480 [<0000000064f766c9>] do_init_module+0x1cf/0x680 [<000000002ba52db0>] load_module+0x6441/0x6f20 [<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0 [<00000000380c1f22>] do_syscall_64+0x3f/0x90 [<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
- https://git.kernel.org/stable/c/0000281f019111526f7abccc61f2746d2eb626ca
- https://git.kernel.org/stable/c/0b2128b70849f2728949babfc1c760096ef72f5d
- https://git.kernel.org/stable/c/13b6269dd022aaa69ca8d1df374ab327504121cf
- https://git.kernel.org/stable/c/61d68cf2ba79128c48d4b3fa4d10c34dc18ba572
- https://git.kernel.org/stable/c/6f6c13776cbee4b6a515f4cd3b859f046be4f6f9
- https://git.kernel.org/stable/c/7c8bf45cea9c8d6fb3e14d8cd5ae60e0372f39b7
- https://git.kernel.org/stable/c/802abe2bc654e87334e6a0ab6c1adc2b6d5f6394
- https://git.kernel.org/stable/c/b0822faebd79971617abd495beb2d6f5356b88bf
- https://git.kernel.org/stable/c/f5f2682d3a34dd8350bf63f232d885fd95f25b92
Modified: 2025-12-04
CVE-2022-50297
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: verify the expected usb_endpoints are present The bug arises when a USB device claims to be an ATH9K but doesn't have the expected endpoints. (In this case there was an interrupt endpoint where the driver expected a bulk endpoint.) The kernel needs to be able to handle such devices without getting an internal error. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Modules linked in: CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events request_firmware_work_func RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Call Trace: ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline] ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019 ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline] ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242 request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097 process_one_work+0x9af/0x1600 kernel/workqueue.c:2279 worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425 kthread+0x3b4/0x4a0 kernel/kthread.c:313 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/0b7e6d681e00a96cde2b32a15ffa70e1be2e3209
- https://git.kernel.org/stable/c/16ef02bad239f11f322df8425d302be62f0443ce
- https://git.kernel.org/stable/c/1824ccabee5445347b83642e4087cc2eca070343
- https://git.kernel.org/stable/c/2d2eccf52ea0215c8d386b62af0b5fd4fc122bd5
- https://git.kernel.org/stable/c/932f0a5e829fb0b823f96d7fa9a0f4fc96660b77
- https://git.kernel.org/stable/c/c319196a0e34ed2e66d6f876f58d8d446335c2a7
- https://git.kernel.org/stable/c/ca57748593ddd8e46d033fbaeb9d01ec533a6bfe
- https://git.kernel.org/stable/c/d008a202a0528a058bac658e657c010ce8534f4a
- https://git.kernel.org/stable/c/d64436af0bc3c9e579be761d7684f228fb95f3bb
Modified: 2025-12-04
CVE-2022-50308
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference.
- https://git.kernel.org/stable/c/1bf5ee979076ceb121ee51c95197d890b1cee7f4
- https://git.kernel.org/stable/c/4518d7cc38b7d1a7ce5a7878ca601c91e19fe47d
- https://git.kernel.org/stable/c/7830e2289eb4b74970b6cd1b6cc68dcd021c2281
- https://git.kernel.org/stable/c/b1e4f92dd0c1d3c162d7ca6c1196995565cca96d
- https://git.kernel.org/stable/c/f849c116d320e85d1e2c2804c0edb0be3953b62d
Modified: 2025-12-04
CVE-2022-50311
In the Linux kernel, the following vulnerability has been resolved: cxl: Fix refcount leak in cxl_calc_capp_routing of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function only calls of_node_put() in normal path, missing it in the error path. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1d09697ff22908ae487fc8c4fbde1811732be523
- https://git.kernel.org/stable/c/2d7b6580384e6d65419933ddc525bd176095da54
- https://git.kernel.org/stable/c/651e8bc9d0418c20a1989b7c078c64c2a6346fa3
- https://git.kernel.org/stable/c/6a310e8db5409676b4b3e6c1f54dff174e4fd04d
- https://git.kernel.org/stable/c/81c8bbf5b2b5f0c8030fff1716c00849cda8571a
- https://git.kernel.org/stable/c/c9bebc503881c1391f6c4f820134884adecf1519
- https://git.kernel.org/stable/c/ee870f72465015327ad96204b0e92450d04870cd
- https://git.kernel.org/stable/c/f2d60f6ba173cded65081cee690b67802395a479
Modified: 2025-12-04
CVE-2022-50318
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox() pci_get_device() will increase the reference count for the returned 'dev'. We need to call pci_dev_put() to decrease the reference count. Since 'dev' is only used in pci_read_config_dword(), let's add pci_dev_put() right after it.
- https://git.kernel.org/stable/c/1ff9dd6e7071a561f803135c1d684b13c7a7d01d
- https://git.kernel.org/stable/c/3485f197518061371568f842405159aa9e4df551
- https://git.kernel.org/stable/c/48f32b9a74e2ac8e854bb87bfefdbc745125a123
- https://git.kernel.org/stable/c/5a96c10a56037db006ba6769307a9731cf6073be
- https://git.kernel.org/stable/c/bd66877c0b3b42eed0ecee0bd2a2a505c1e54177
- https://git.kernel.org/stable/c/c0539d5d474ee6fa4ebc41f927a0f98f81244f25
- https://git.kernel.org/stable/c/e293263248f25c6b8aa1caf7c1103d40aa03311e
Modified: 2025-12-03
CVE-2022-50324
In the Linux kernel, the following vulnerability has been resolved:
mtd: maps: pxa2xx-flash: fix memory leak in probe
Free 'info' upon remapping error to avoid a memory leak.
[
- https://git.kernel.org/stable/c/1d0c2b762dad2b8dd166e17c0e90b88b86a3284f
- https://git.kernel.org/stable/c/2399401feee27c639addc5b7e6ba519d3ca341bf
- https://git.kernel.org/stable/c/6fa9550ef3e13d7e9b2d4db6dd57292ccd072a90
- https://git.kernel.org/stable/c/932baf593eb63dff40e40d7674f076fb7932cd5b
- https://git.kernel.org/stable/c/a1b061cafdbcb1ff259731f30e2bdc1de64dcaba
- https://git.kernel.org/stable/c/cb3f35f44887a8486737fe88d58050f1df290758
- https://git.kernel.org/stable/c/cf9c4c25caad05c6b492cbba739a467511814279
- https://git.kernel.org/stable/c/e2324a0912ad26a0ea5baaf81aed0ca880804158
- https://git.kernel.org/stable/c/f35981083cb3fc1ba6427c1543152c5e3f59d104
Modified: 2025-12-04
CVE-2022-50333
In the Linux kernel, the following vulnerability has been resolved: fs: jfs: fix shift-out-of-bounds in dbDiscardAG This should be applied to most URSAN bugs found recently by syzbot, by guarding the dbMount. As syzbot feeding rubbish into the bmap descriptor.
- https://git.kernel.org/stable/c/0183c8f46ab5bcd0740f41c87f5141c6ca2bf1bb
- https://git.kernel.org/stable/c/10b87da8fae79c7daf5eda6a9e4f1d31b85b4d92
- https://git.kernel.org/stable/c/25e70c6162f207828dd405b432d8f2a98dbf7082
- https://git.kernel.org/stable/c/3d340b684dcec5e34efc470227cd1c7d2df121ad
- https://git.kernel.org/stable/c/50163a115831ef4e6402db5a7ef487d1989d7249
- https://git.kernel.org/stable/c/624843f1bac448150f6859999c72c4841c14a2e3
- https://git.kernel.org/stable/c/911999b193735cd378517b6cd5fe585ee345d49c
- https://git.kernel.org/stable/c/ab5cd3d62c2493eca3337e7d0178cc7bd819ca64
- https://git.kernel.org/stable/c/f8d4d0bac603616e2fa4a3907e81ed13f8f3c380
Modified: 2025-12-04
CVE-2022-50334
In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()
Syzkaller reports a null-ptr-deref bug as follows:
======================================================
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380
[...]
Call Trace:
- https://git.kernel.org/stable/c/26215b7ee923b9251f7bb12c4e5f09dc465d35f2
- https://git.kernel.org/stable/c/965e8f8ae0f642b5528f5a82b7bcaf15a659d5bd
- https://git.kernel.org/stable/c/9a8862820cbf1f18dca4f3b4c289d88561b3a384
- https://git.kernel.org/stable/c/dcd28191be9bbf307ba51a5b485773a55b0037c4
- https://git.kernel.org/stable/c/f2207145693ae5697a7b59e2add4b92f9e5b0e3c
- https://git.kernel.org/stable/c/fa71639873518e3587632ae58e25e4a96b57fa90
Modified: 2025-12-04
CVE-2022-50337
In the Linux kernel, the following vulnerability has been resolved: ocxl: fix pci device refcount leak when calling get_function_0() get_function_0() calls pci_get_domain_bus_and_slot(), as comment says, it returns a pci device with refcount increment, so after using it, pci_dev_put() needs be called. Get the device reference when get_function_0() is not called, so pci_dev_put() can be called in the error path and callers unconditionally. And add comment above get_dvsec_vendor0() to tell callers to call pci_dev_put().
- https://git.kernel.org/stable/c/27158c72678b39ee01cc01de1aba6b51c71abe2f
- https://git.kernel.org/stable/c/37a13b274e4513c757e50c002ddcbf4bc89adbb2
- https://git.kernel.org/stable/c/40ff4c2335a98f0ee96b099bfd70b8e6644f321f
- https://git.kernel.org/stable/c/9a1b3148975b71fdc194e62612478346bbe618cd
- https://git.kernel.org/stable/c/a40e1b0a922a53fa925ea8b296e3de30a31ed028
Modified: 2026-01-14
CVE-2022-50340
In the Linux kernel, the following vulnerability has been resolved:
media: vimc: Fix wrong function called when vimc_init() fails
In vimc_init(), when platform_driver_register(&vimc_pdrv) fails,
platform_driver_unregister(&vimc_pdrv) is wrongly called rather than
platform_device_unregister(&vimc_pdev), which causes kernel warning:
Unexpected driver unregister!
WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0
RIP: 0010:driver_unregister+0x8f/0xb0
Call Trace:
- https://git.kernel.org/stable/c/14d85b600bb1f6f8ef61fa8fc1907e2e623d8350
- https://git.kernel.org/stable/c/681ac2902039d9b497b3ae18fdc204314979e61e
- https://git.kernel.org/stable/c/9c9ff35d68691aaea85b2e93763772e23930b3a3
- https://git.kernel.org/stable/c/f38df8984ef1b45ba23888d0e232cc21a95bd04b
- https://git.kernel.org/stable/c/f74d3f326d1d5b8951ce263c59a121ecfa65e7c0
Modified: 2026-01-14
CVE-2022-50341
In the Linux kernel, the following vulnerability has been resolved: cifs: fix oops during encryption When running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses.
- https://git.kernel.org/stable/c/a13e51760703f71c25d5fc1f4a62dfa4b0cc80e9
- https://git.kernel.org/stable/c/bf0543b93740916ee91956f9a63da6fc0d79daaa
- https://git.kernel.org/stable/c/e8d16a54842d609fd4a3ed2d81d4333d6329aa94
- https://git.kernel.org/stable/c/e8e2861cc3258dbe407d01ea8c59bb5a53132301
- https://git.kernel.org/stable/c/f7f291e14dde32a07b1f0aa06921d28f875a7b54
- https://git.kernel.org/stable/c/fe6ea044c4f05706cb71040055b1c70c6c8275e0
Modified: 2026-01-14
CVE-2022-50343
In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible name leaks when rio_add_device() fails Patch series "rapidio: fix three possible memory leaks". This patchset fixes three name leaks in error handling. - patch #1 fixes two name leaks while rio_add_device() fails. - patch #2 fixes a name leak while rio_register_mport() fails. This patch (of 2): If rio_add_device() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and the 'rdev' can be freed in rio_release_dev().
- https://git.kernel.org/stable/c/3b4676f274a6b5d001176f15d0542100bbf4b59a
- https://git.kernel.org/stable/c/440afd7fd9b164fdde6fc9da8c47d3d7f20dcce8
- https://git.kernel.org/stable/c/80fad2e53eaed2b3a2ff596575f65669e13ceda5
- https://git.kernel.org/stable/c/85fbf58b15c09d3a6a03098c1e42ebfe9002f39d
- https://git.kernel.org/stable/c/88fa351b20ca300693a206ccd3c4b0e0647944d8
- https://git.kernel.org/stable/c/c413f65011ff8caffabcde0e1c3ceede48a48d6f
- https://git.kernel.org/stable/c/c482cb0deb57924335103fe592c379a076d867f8
- https://git.kernel.org/stable/c/ec3f04f74f50d0b6bac04d795c93c2b852753a7a
- https://git.kernel.org/stable/c/f9574cd48679926e2a569e1957a5a1bcc8a719ac
Modified: 2026-01-14
CVE-2022-50346
In the Linux kernel, the following vulnerability has been resolved:
ext4: init quota for 'old.inode' in 'ext4_rename'
Syzbot found the following issue:
ext4_parse_param: s_want_extra_isize=128
ext4_inode_info_init: s_want_extra_isize=32
ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828
__ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128
__ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128
ext4_xattr_block_set: inode=ffff88823869a2c8
------------[ cut here ]------------
WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980
Modules linked in:
RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980
RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000
RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178
RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e
R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000
R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000
FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/13271fbbe85d73a7c47058f56a52f2a7f00d6e39
- https://git.kernel.org/stable/c/135ba9146f4d38abed48a540ef8a8770ff0bd34f
- https://git.kernel.org/stable/c/33fd7031d634f3b46e59f61adfbb0ea9fe514fef
- https://git.kernel.org/stable/c/67f6d5a4043f3db0c6bb0e14a0d97a7be8bfb8b5
- https://git.kernel.org/stable/c/7dfb8259f66faafa68d23a261b284d2c2c67649b
- https://git.kernel.org/stable/c/84a2f2ed49d6a4d92b354219077434c57d334620
- https://git.kernel.org/stable/c/def7a39091e60e1c4a2f623629082a00092602be
- https://git.kernel.org/stable/c/f263e349bacc2f303526dcfa61c4bc50132418b1
- https://git.kernel.org/stable/c/fae381a3d79bb94aa2eb752170d47458d778b797
Modified: 2026-01-14
CVE-2022-50347
In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called.
- https://git.kernel.org/stable/c/1491667d5450778a265eddddd294219acfd648cb
- https://git.kernel.org/stable/c/7fa922c7a3dd623fd59f1af50e8896fd9ca7f654
- https://git.kernel.org/stable/c/89303ddbb502c3bc8edbf864f9f85500c8fe07e9
- https://git.kernel.org/stable/c/937112e991ed25d1727d878734adcbef3b900274
- https://git.kernel.org/stable/c/a522e26a20a43dcfbef9ee9f71ed803290e852b0
- https://git.kernel.org/stable/c/d7ad7278be401b09c9f9a9f522cf4c449c7fd489
- https://git.kernel.org/stable/c/df683201c7ffbd21a806a7cad657b661c5ebfb6f
- https://git.kernel.org/stable/c/e598c9683fe1cf97c2b11b800cc3cee072108220
- https://git.kernel.org/stable/c/fc38a5a10e9e5a75eb9189854abeb8405b214cc9
Modified: 2026-01-14
CVE-2022-50349
In the Linux kernel, the following vulnerability has been resolved: misc: tifm: fix possible memory leak in tifm_7xx1_switch_media() If device_register() returns error in tifm_7xx1_switch_media(), name of kobject which is allocated in dev_set_name() called in device_add() is leaked. Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized.
- https://git.kernel.org/stable/c/1695b1adcc3a7d985cd22fa3b55761edf3fab50d
- https://git.kernel.org/stable/c/2bbb222a54ff501f77ce593d21b76b79c905045e
- https://git.kernel.org/stable/c/35abbc8406cc39e72d3ce85f6e869555afe50d54
- https://git.kernel.org/stable/c/57c857353d5020bdec8284d9c0fee447484fe5e0
- https://git.kernel.org/stable/c/848c45964ded537107e010aaf353aa30a0855387
- https://git.kernel.org/stable/c/d861b7d41b17942b337d4b87a70de7cd1dc44d4e
- https://git.kernel.org/stable/c/ee2715faf7e7153f5142ed09aacfa89a64d45dcb
- https://git.kernel.org/stable/c/ef843ee20576039126d34d6eb5f45d14c3e6ce18
- https://git.kernel.org/stable/c/fd2c930cf6a5b9176382c15f9acb1996e76e25ad
Modified: 2026-01-14
CVE-2022-50353
In the Linux kernel, the following vulnerability has been resolved: mmc: wmt-sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, clk_disable_unprepare() also needs be called.
- https://git.kernel.org/stable/c/29276d56f6ed138db0f38cd31aedc0b725c8c76c
- https://git.kernel.org/stable/c/58c3a8d0f1abeb1ca5c2df948be58ad4f7bb6f67
- https://git.kernel.org/stable/c/70b0620afab3c69d95a7e2dd7ceff162a21c4009
- https://git.kernel.org/stable/c/9bedf64dda84b29151e41591d8ded9ff0e6d336a
- https://git.kernel.org/stable/c/b40ac3b696a9c84b36211ef0c3f5a422650c101b
- https://git.kernel.org/stable/c/c7a328cea791cc2769b6417943939420913b4a46
- https://git.kernel.org/stable/c/eb7a2d516d4fbd165c07877a20feccb047342b1f
- https://git.kernel.org/stable/c/ecd6f77af3478f5223aa4011642a891b7dc91228
Modified: 2026-01-14
CVE-2022-50358
In the Linux kernel, the following vulnerability has been resolved: brcmfmac: return error when getting invalid max_flowrings from dongle When firmware hit trap at initialization, host will read abnormal max_flowrings number from dongle, and it will cause kernel panic when doing iowrite to initialize dongle ring. To detect this error at early stage, we directly return error when getting invalid max_flowrings(>256).
- https://git.kernel.org/stable/c/10c4b63d09a5b0ebf1b61af1dae7f25555cf58b6
- https://git.kernel.org/stable/c/200347eb3b2608cc8b54c13dd1d5e03809ba2eb2
- https://git.kernel.org/stable/c/2aca4f3734bd717e04943ddf340d49ab62299a00
- https://git.kernel.org/stable/c/2e8bb402b060a6c22160de3d72cee057698177c8
- https://git.kernel.org/stable/c/3cc9299036bdb647408e11e41de3eb1ff6d428cd
- https://git.kernel.org/stable/c/87f126b25fa8562196f0f4c0aa46a446026199bf
Modified: 2026-01-14
CVE-2022-50364
In the Linux kernel, the following vulnerability has been resolved: i2c: mux: reg: check return value after calling platform_get_resource() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code.
- https://git.kernel.org/stable/c/2d47b79d2bd39cc6369eccf94a06568d84c906ae
- https://git.kernel.org/stable/c/61df25c41b8e0d2c988ccf17139f70075a2e1ba4
- https://git.kernel.org/stable/c/8212800943997fab61874550278d653cb378c60c
- https://git.kernel.org/stable/c/f5049b3ad9446203b916ee375f30fa217735f63a
- https://git.kernel.org/stable/c/f7a440c89b6d460154efeb058272760e41bdfea8
Modified: 2026-01-14
CVE-2022-50365
In the Linux kernel, the following vulnerability has been resolved: skbuff: Account for tail adjustment during pull operations Extending the tail can have some unexpected side effects if a program uses a helper like BPF_FUNC_skb_pull_data to read partial content beyond the head skb headlen when all the skbs in the gso frag_list are linear with no head_frag - kernel BUG at net/core/skbuff.c:4219! pc : skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60 Fix this by marking these skbs as GSO_DODGY so segmentation can handle the tail updates accordingly.
- https://git.kernel.org/stable/c/2d59f0ca153e9573ec4f140988c0ccca0eb4181b
- https://git.kernel.org/stable/c/2d7afdcbc9d32423f177ee12b7c93783aea338fb
- https://git.kernel.org/stable/c/331615d837f4979eb91a336a223a5c7f7886ecd5
- https://git.kernel.org/stable/c/668dc454bcbd1da73605201ff43f988c70848215
- https://git.kernel.org/stable/c/6ac417d71b80e74b002313fcd73f7e9008e8e457
- https://git.kernel.org/stable/c/821be5a5ab09a40ba09cb5ba354f18cf7996fea0
- https://git.kernel.org/stable/c/8fb773eed4909ef5dc1bbeb3629a337d3336df7e
- https://git.kernel.org/stable/c/946dd5dc4fcc4123cdfe3942b20012c4448cf89a
- https://git.kernel.org/stable/c/ff3743d00f41d803e6ab9334962b674f3b7fd0cb
Modified: 2026-01-14
CVE-2022-50376
In the Linux kernel, the following vulnerability has been resolved: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init() When insert and remove the orangefs module, there are memory leaked as below: unreferenced object 0xffff88816b0cc000 (size 2048): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f [<00000000e5a0085b>] 0xffffffffa02780f9 [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Use the golbal variable as the buffer rather than dynamic allocate to slove the problem.
- https://git.kernel.org/stable/c/0cd303aad220fafa595e0ed593e99aa51b90412b
- https://git.kernel.org/stable/c/31720a2b109b3080eb77e97b8f6f50a27b4ae599
- https://git.kernel.org/stable/c/786e5296f9e3b045d5ff9098514ce7b8ba1d890d
- https://git.kernel.org/stable/c/a076490b0211990ec6764328c22cb744dd782bd9
- https://git.kernel.org/stable/c/bdc2d33fa2324b1f5ab5b701cda45ee0b2384409
- https://git.kernel.org/stable/c/c8853267289c55b1acbe4dc3641374887584834d
Modified: 2026-01-14
CVE-2022-50381
In the Linux kernel, the following vulnerability has been resolved:
md: fix a crash in mempool_free
There's a crash in mempool_free when running the lvm test
shell/lvchange-rebuild-raid.sh.
The reason for the crash is this:
* super_written calls atomic_dec_and_test(&mddev->pending_writes) and
wake_up(&mddev->sb_wait). Then it calls rdev_dec_pending(rdev, mddev)
and bio_put(bio).
* so, the process that waited on sb_wait and that is woken up is racing
with bio_put(bio).
* if the process wins the race, it calls bioset_exit before bio_put(bio)
is executed.
* bio_put(bio) attempts to free a bio into a destroyed bio set - causing
a crash in mempool_free.
We fix this bug by moving bio_put before atomic_dec_and_test.
We also move rdev_dec_pending before atomic_dec_and_test as suggested by
Neil Brown.
The function md_end_flush has a similar bug - we must call bio_put before
we decrement the number of in-progress bios.
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 11557f0067 P4D 11557f0067 PUD 0
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 73 Comm: kworker/0:1 Not tainted 6.1.0-rc3 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Workqueue: kdelayd flush_expired_bios [dm_delay]
RIP: 0010:mempool_free+0x47/0x80
Code: 48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 <48> 89 2c d0 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00
RSP: 0018:ffff88910036bda8 EFLAGS: 00010093
RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8
RBP: ffff8891447ba240 R08: 0000000000012908 R09: 00000000003d0900
R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000
R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05
FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0
Call Trace:
- https://git.kernel.org/stable/c/341097ee53573e06ab9fc675d96a052385b851fa
- https://git.kernel.org/stable/c/384ef33d37cefb2ac539d44597d03f06c9b8975c
- https://git.kernel.org/stable/c/732cd66ec19a17f2b9183d7d5b7bdb9c39b0776e
- https://git.kernel.org/stable/c/842f222fc42a9239831e15b1fd49a51c546902cb
- https://git.kernel.org/stable/c/91bd504128a51776472445070e11a3b0f9348c90
- https://git.kernel.org/stable/c/97ce99984be12b9acb49ddce0f5d8ebb037adbb6
- https://git.kernel.org/stable/c/ae7793027766491c5f8635b12d15a5940d3b8698
- https://git.kernel.org/stable/c/b5be563b4356b3089b3245d024cae3f248ba7090
- https://git.kernel.org/stable/c/cf06b162f5b6337b688072a1a47941280b8f7110
Modified: 2026-01-14
CVE-2022-50382
In the Linux kernel, the following vulnerability has been resolved:
padata: Always leave BHs disabled when running ->parallel()
A deadlock can happen when an overloaded system runs ->parallel() in the
context of the current task:
padata_do_parallel
->parallel()
pcrypt_aead_enc/dec
padata_do_serial
spin_lock(&reorder->lock) // BHs still enabled
- https://git.kernel.org/stable/c/17afa98bccec4f52203508b3f49b5f948c6fd6ac
- https://git.kernel.org/stable/c/34c3a47d20ae55b3600fed733bf96eafe9c500d5
- https://git.kernel.org/stable/c/6cfa9e60c0f88fdec6368e081ab968411cc706b1
- https://git.kernel.org/stable/c/7337adb20fcc0aebb50eaff2bc5a8dd9a7c6743d
- https://git.kernel.org/stable/c/8e0681dd4eee029eb1d533d06993f7cb091efb73
Modified: 2026-01-14
CVE-2022-50384
In the Linux kernel, the following vulnerability has been resolved: staging: vme_user: Fix possible UAF in tsi148_dma_list_add Smatch report warning as follows: drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn: '&entry->list' not removed from list In tsi148_dma_list_add(), the error path "goto err_dma" will not remove entry->list from list->entries, but entry will be freed, then list traversal may cause UAF. Fix by removeing it from list->entries before free().
- https://git.kernel.org/stable/c/1f5661388f43df3ac106ce93e67d8d22b16a78ff
- https://git.kernel.org/stable/c/357057ee55d3c99a5de5abe8150f7bca04f8e53b
- https://git.kernel.org/stable/c/51c0ad3b7c5b01f9314758335a13f157b05fa56d
- https://git.kernel.org/stable/c/5cc4eea715a3fcf4e516662f736dfee63979465f
- https://git.kernel.org/stable/c/5d2b286eb034af114f67d9967fc3fbc1829bb712
- https://git.kernel.org/stable/c/85db68fc901da52314ded80aace99f8b684c7815
- https://git.kernel.org/stable/c/a45ba33d398a821147d7e5f16ead7eb125e331e2
- https://git.kernel.org/stable/c/cf138759a7e92c75cfc1b7ba705e4108fe330edf
- https://git.kernel.org/stable/c/e6b0adff99edf246ba1f8d464530a0438cb1cbda
Modified: 2026-01-14
CVE-2022-50385
In the Linux kernel, the following vulnerability has been resolved: NFS: Fix an Oops in nfs_d_automount() When mounting from a NFSv4 referral, path->dentry can end up being a negative dentry, so derive the struct nfs_server from the dentry itself instead.
- https://git.kernel.org/stable/c/35e3b6ae84935d0d7ff76cbdaa83411b0ad5e471
- https://git.kernel.org/stable/c/5458bc0f9df639d83471ca384152cc62dbee0aeb
- https://git.kernel.org/stable/c/6f3d56783fbed861e483736a7001bdafd0dddd53
- https://git.kernel.org/stable/c/b6fd25d64b0de27991d6bd677f0adf69ad6ff07a
- https://git.kernel.org/stable/c/f12377abac15fb4e8698225ac386894f8ae63598
Modified: 2026-01-14
CVE-2022-50388
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix multipath crash caused by flush request when blktrace is enabled
The flush request initialized by blk_kick_flush has NULL bio,
and it may be dealt with nvme_end_req during io completion.
When blktrace is enabled, nvme_trace_bio_complete with multipath
activated trying to access NULL pointer bio from flush request
results in the following crash:
[ 2517.831677] BUG: kernel NULL pointer dereference, address: 000000000000001a
[ 2517.835213] #PF: supervisor read access in kernel mode
[ 2517.838724] #PF: error_code(0x0000) - not-present page
[ 2517.842222] PGD 7b2d51067 P4D 0
[ 2517.845684] Oops: 0000 [#1] SMP NOPTI
[ 2517.849125] CPU: 2 PID: 732 Comm: kworker/2:1H Kdump: loaded Tainted: G S 5.15.67-0.cl9.x86_64 #1
[ 2517.852723] Hardware name: XFUSION 2288H V6/BC13MBSBC, BIOS 1.13 07/27/2022
[ 2517.856358] Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp]
[ 2517.859993] RIP: 0010:blk_add_trace_bio_complete+0x6/0x30
[ 2517.863628] Code: 1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff ff 0f 1f 44 00 00 41 54 49 89 f4 55 <0f> b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba
[ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286
[ 2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCX: ff3d5b0a270f2000
[ 2517.878966] RDX: 0000000000000000 RSI: ff3d5b0b021fb9f8 RDI: 0000000000000000
[ 2517.882849] RBP: ff3d5b0b96a6fa00 R08: 0000000000000001 R09: 0000000000000000
[ 2517.886718] R10: 000000000000000c R11: 000000000000000c R12: ff3d5b0b021fb9f8
[ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018
[ 2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000
[ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2517.902157] CR2: 000000000000001a CR3: 00000004f023e005 CR4: 0000000000771ee0
[ 2517.906053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2517.913761] PKRU: 55555554
[ 2517.917558] Call Trace:
[ 2517.921294]
- https://git.kernel.org/stable/c/183c2aaef40a91acbaae45c3824d6cde7bb62b10
- https://git.kernel.org/stable/c/3659fb5ac29a5e6102bebe494ac789fd47fb78f4
- https://git.kernel.org/stable/c/4df413d46960f11c8c105238cfc3f5ff4c95c003
- https://git.kernel.org/stable/c/f13301a69ababa6c2236fb4f0393b7e914e7e1e0
- https://git.kernel.org/stable/c/fcd2d199486033223e9b2a6a7f9a01dd0327eac3
Modified: 2026-01-14
CVE-2022-50389
In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak In crb_acpi_add(), we get the TPM2 table to retrieve information like start method, and then assign them to the priv data, so the TPM2 table is not used after the init, should be freed, call acpi_put_table() to fix the memory leak.
- https://git.kernel.org/stable/c/08fd965521d0e172d540cf945517810895fcb199
- https://git.kernel.org/stable/c/0bd9b4be721c776f77adcaf34105dfca3007ddb9
- https://git.kernel.org/stable/c/1af2232b13837ce0f3a082b9f43735b09aafc367
- https://git.kernel.org/stable/c/2fcd3dc8b97a14f1672729c86b7041a1a89b052a
- https://git.kernel.org/stable/c/37e90c374dd11cf4919c51e847c6d6ced0abc555
- https://git.kernel.org/stable/c/927860dfa161ae8392a264197257dbdc52b26b0f
- https://git.kernel.org/stable/c/986cd9a9b95423e35a2cbb8e9105aec0e0d7f337
- https://git.kernel.org/stable/c/b0785edaf649e5f04dc7f75533e810f4c00e4106
Modified: 2026-01-14
CVE-2022-50394
In the Linux kernel, the following vulnerability has been resolved: i2c: ismt: Fix an out-of-bounds bug in ismt_access() When the driver does not check the data from the user, the variable 'data->block[0]' may be very large to cause an out-of-bounds bug. The following log can reveal it: [ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20 [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE [ 33.996475] ================================================================== [ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485 [ 33.999450] Call Trace: [ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismt_access.cold+0x374/0x214b [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0 [ 34.004007] i2c_smbus_xfer+0x10a/0x390 [ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710 [ 34.005196] i2cdev_ioctl+0x5ec/0x74c Fix this bug by checking the size of 'data->block[0]' first.
- https://git.kernel.org/stable/c/03b7ef7a6c5ca1ff553470166b4919db88b810f6
- https://git.kernel.org/stable/c/233348a04becf133283f0076e20b317302de21d9
- https://git.kernel.org/stable/c/39244cc754829bf707dccd12e2ce37510f5b1f8d
- https://git.kernel.org/stable/c/4a7bb1d93addb2f67e36fed00a53cb7f270d7b7a
- https://git.kernel.org/stable/c/96c12fd0ec74641295e1c3c34dea3dce1b6c3422
- https://git.kernel.org/stable/c/9ac541a0898e8ec187a3fa7024b9701cffae6bf2
- https://git.kernel.org/stable/c/a642469d464b2780a25a49b51ae56623c65eac34
- https://git.kernel.org/stable/c/bfe41d966c860a8ad4c735639d616da270c92735
- https://git.kernel.org/stable/c/cdcbae2c5003747ddfd14e29db9c1d5d7e7c44dd
Modified: 2026-01-14
CVE-2022-50395
In the Linux kernel, the following vulnerability has been resolved: integrity: Fix memory leakage in keyring allocation error path Key restriction is allocated in integrity_init_keyring(). However, if keyring allocation failed, it is not freed, causing memory leaks.
- https://git.kernel.org/stable/c/29d6c69ba4b96a1de0376e44e5f8b38b13ec8803
- https://git.kernel.org/stable/c/39419ef7af0916cc3620ecf1ed42d29659109bf3
- https://git.kernel.org/stable/c/3bd737289c26be3cee4b9afaf61ef784a2af9d6e
- https://git.kernel.org/stable/c/57e49ad12f8f5df0c48e1710c54b147a05a10c32
- https://git.kernel.org/stable/c/9b7c44885a07c5ee7f9bf3aa3c9c72fb110c8d22
- https://git.kernel.org/stable/c/c591c48842f08d30ec6b8416757831985ed9a315
Modified: 2026-01-14
CVE-2022-50401
In the Linux kernel, the following vulnerability has been resolved:
nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure
On error situation `clp->cl_cb_conn.cb_xprt` should not be given
a reference to the xprt otherwise both client cleanup and the
error handling path of the caller call to put it. Better to
delay handing over the reference to a later branch.
[ 72.530665] refcount_t: underflow; use-after-free.
[ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120
[ 72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc]
[ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1
[ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014
[ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd]
[ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120
[ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48
[ 72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286
[ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000
[ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0
[ 72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff
[ 72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180
[ 72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0
[ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000
[ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0
[ 72.554874] Call Trace:
[ 72.555278]
- https://git.kernel.org/stable/c/15fc60aa5bdcf6d5f93000d3d00579fc67632ee0
- https://git.kernel.org/stable/c/3bc8edc98bd43540dbe648e4ef91f443d6d20a24
- https://git.kernel.org/stable/c/707bcca9616002d204091ca7c4d1d91151104332
- https://git.kernel.org/stable/c/9b4ae8c42d2ff09ed7c5832ccce5684c55e5ed23
- https://git.kernel.org/stable/c/a472f069ced8601979f53c13c0cf20236074ed46
- https://git.kernel.org/stable/c/c1207219a4bfa50121c9345d5d165470d0a82531
- https://git.kernel.org/stable/c/d843ebd860c58a38e45527e8ec6516059f4c97f3
- https://git.kernel.org/stable/c/e2f9f03e4537f3fcc8fd2bdd3248530c3477a371
- https://git.kernel.org/stable/c/fddac3b4578d302ac9e51e7f03a9aae6254ae2a3
Modified: 2026-01-14
CVE-2022-50402
In the Linux kernel, the following vulnerability has been resolved: drivers/md/md-bitmap: check the return value of md_bitmap_get_counter() Check the return value of md_bitmap_get_counter() in case it returns NULL pointer, which will result in a null pointer dereference. v2: update the check to include other dereference
- https://git.kernel.org/stable/c/100caacfa0ed26e061954c90cdc835d42f709536
- https://git.kernel.org/stable/c/21e9aac9a74d30907d44bae0d24c036cb3819406
- https://git.kernel.org/stable/c/3bd548e5b819b8c0f2c9085de775c5c7bff9052f
- https://git.kernel.org/stable/c/5d8d046f3dba939e74e2414f009df426700430ed
- https://git.kernel.org/stable/c/99bef41f8e8d1d52b5cb34f2f193f1346192752b
- https://git.kernel.org/stable/c/b621d17fe8b079574c773800148fb86907f3445d
- https://git.kernel.org/stable/c/ff3b7e12bc9f50de05c9d82b5b79e23e5be888f1
Modified: 2026-01-14
CVE-2022-50405
In the Linux kernel, the following vulnerability has been resolved: net/tunnel: wait until all sk_user_data reader finish before releasing the sock There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock.
- https://git.kernel.org/stable/c/303000c793f705d07b551eb7c1c27001c5b33c8d
- https://git.kernel.org/stable/c/3cf7203ca620682165706f70a1b12b5194607dce
- https://git.kernel.org/stable/c/588d0b8462f5ffed3e677e65639825b2678117ab
- https://git.kernel.org/stable/c/84e566d157cc22ad2da8bdd970495855fbf13d92
- https://git.kernel.org/stable/c/91f09a776ae335ca836ed864b8f2a9461882a280
- https://git.kernel.org/stable/c/9a6544343bba7da929d6d4a2dc44ec0f15970081
- https://git.kernel.org/stable/c/b38aa7465411795e9e744b8d94633910497fec2a
- https://git.kernel.org/stable/c/be34e79e0ae6adbf6e7e75ddaee9ad84795ab933
- https://git.kernel.org/stable/c/e8316584b0a6c61c9c407631040c22712b26e38c
Modified: 2026-01-14
CVE-2022-50411
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix error code path in acpi_ds_call_control_method() A use-after-free in acpi_ps_parse_aml() after a failing invocaion of acpi_ds_call_control_method() is reported by KASAN [1] and code inspection reveals that next_walk_state pushed to the thread by acpi_ds_create_walk_state() is freed on errors, but it is not popped from the thread beforehand. Thus acpi_ds_get_current_walk_state() called by acpi_ps_parse_aml() subsequently returns it as the new walk state which is incorrect. To address this, make acpi_ds_call_control_method() call acpi_ds_pop_walk_state() to pop next_walk_state from the thread before returning an error.
- https://git.kernel.org/stable/c/0462fec709d51762ba486245bc344f44cc6cfa97
- https://git.kernel.org/stable/c/2deb42c4f9776e59bee247c14af9c5e8c05ca9a6
- https://git.kernel.org/stable/c/38e251d356a01b61a86cb35213cafd7e8fe7090c
- https://git.kernel.org/stable/c/404ec60438add1afadaffaed34bb5fe4ddcadd40
- https://git.kernel.org/stable/c/5777432ebaaf797e24f059979b42df3139967163
- https://git.kernel.org/stable/c/799881db3e03b5e98fe6a900d9d7de8c7d61e7ee
- https://git.kernel.org/stable/c/9ef353c92f9d04c88de3af1a46859c1fb76db0f8
- https://git.kernel.org/stable/c/b0b83d3f3ffa96e8395c56b83d6197e184902a34
- https://git.kernel.org/stable/c/f520d181477ec29a496c0b3bbfbdb7e2606c2713
Modified: 2026-01-14
CVE-2022-50414
In the Linux kernel, the following vulnerability has been resolved:
scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails
fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when
fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed
&fcoe_sw_transport on fcoe_transports list. This causes panic when
reinserting module.
BUG: unable to handle page fault for address: fffffbfff82e2213
RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe]
Call Trace:
- https://git.kernel.org/stable/c/09a60f908d8b6497f618113b7c3c31267dc90911
- https://git.kernel.org/stable/c/1dc499c615aa87dc46a3f2d1f91d2d358e55f3e3
- https://git.kernel.org/stable/c/22e8c7a56bb1cd2ed0beaaccb34282ac9cbbe27e
- https://git.kernel.org/stable/c/4155658cee394b22b24c6d64e49247bf26d95b92
- https://git.kernel.org/stable/c/aef82d16be5a353d913163f26fc4385e296be2b8
- https://git.kernel.org/stable/c/b5cc59470df64f26ad397dbb71cbf130cf489edf
- https://git.kernel.org/stable/c/be5f1a82ad6056db22c86005dc4cac22a20deeef
- https://git.kernel.org/stable/c/cf74d1197c0e3d2f353faa333e9e2847c73713f1
- https://git.kernel.org/stable/c/d581303d6f8d4139513105d73dd65f26c6707160
Modified: 2026-01-14
CVE-2022-50415
In the Linux kernel, the following vulnerability has been resolved: parisc: led: Fix potential null-ptr-deref in start_task() start_task() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: start_task() create_singlethread_workqueue() # failed, led_wq 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.
- https://git.kernel.org/stable/c/3505c187b86136250b39e62c72a3a70435277af6
- https://git.kernel.org/stable/c/41f563ab3c33698bdfc3403c7c2e6c94e73681e4
- https://git.kernel.org/stable/c/5e4500454d75dd249be4695d83afa3ba0724c37e
- https://git.kernel.org/stable/c/67c98fec87ed76b1feb2ae810051afd88dfa9df6
- https://git.kernel.org/stable/c/77f8b628affaec692d83ad8bfa3520db8a0cc493
- https://git.kernel.org/stable/c/ac838c663ba1fd6bff35a817fd89a47ab55e88e0
- https://git.kernel.org/stable/c/c6db0c32f39684c89c97bc1ba1c9c4249ca09e48
- https://git.kernel.org/stable/c/fc307b2905a3dd75c50a53b4d87ac9c912fb7c4e
- https://git.kernel.org/stable/c/fc6d0f65f22040c6cc8a5ce032bf90252629de50
Modified: 2026-01-14
CVE-2022-50417
In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix GEM handle creation ref-counting panfrost_gem_create_with_handle() previously returned a BO but with the only reference being from the handle, which user space could in theory guess and release, causing a use-after-free. Additionally if the call to panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then a(nother) reference on the BO was dropped. The _create_with_handle() is a problematic pattern, so ditch it and instead create the handle in panfrost_ioctl_create_bo(). If the call to panfrost_gem_mapping_get() fails then this means that user space has indeed gone behind our back and freed the handle. In which case just return an error code.
- https://git.kernel.org/stable/c/0b70f6ea4d4f2b4d4b291d86ab76b4d07394932c
- https://git.kernel.org/stable/c/3f9feffa8a5ab08b4e298a27b1aa7204a7d42ca2
- https://git.kernel.org/stable/c/4217c6ac817451d5116687f3cc6286220dc43d49
- https://git.kernel.org/stable/c/4f1105ee72d8c7c35d90e3491b31b2d9d6b7e33a
- https://git.kernel.org/stable/c/ba3d2c2380e7129b525a787489c0b7e819a3b898
Modified: 2026-01-14
CVE-2022-50423
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()
There is an use-after-free reported by KASAN:
BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82
Read of size 1 at addr ffff888112afc460 by task modprobe/2111
CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
Call Trace:
- https://git.kernel.org/stable/c/01f2c2052ea50fb9a8ce12e4e83aed0267934ef0
- https://git.kernel.org/stable/c/02617006b5a46f2ea55ac61f5693c7afd7bf9276
- https://git.kernel.org/stable/c/02f237423c9c6a18e062de2d474f85d5659e4eb9
- https://git.kernel.org/stable/c/133462d35dae95edb944af86b986d4c9dec59bd1
- https://git.kernel.org/stable/c/470188b09e92d83c5a997f25f0e8fb8cd2bc3469
- https://git.kernel.org/stable/c/6fde666278f91b85d71545a0ebbf41d8d7af8074
- https://git.kernel.org/stable/c/c9125b643fc51b8e662f2f614096ceb45a0adbc3
- https://git.kernel.org/stable/c/dfdde4d5138bc023897033a5ac653a84e94805be
- https://git.kernel.org/stable/c/f51b2235e4f320edc839c3e5cb0d1f8a6e8657c6
Modified: 2026-01-21
CVE-2022-50430
In the Linux kernel, the following vulnerability has been resolved:
mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING
vub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here.
Ensure that we mark current as TASK_RUNNING for sleepable context.
[ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [
- https://git.kernel.org/stable/c/32d5af247d4de6a35769ca1d027480a37c28fd0c
- https://git.kernel.org/stable/c/48e91ae755f027d817ed7e51db9963ddb7081946
- https://git.kernel.org/stable/c/4a44cd249604e29e7b90ae796d7692f5773dd348
- https://git.kernel.org/stable/c/6f7258c6f66692b3760c37ddd4bc9e02bb290da7
- https://git.kernel.org/stable/c/b51d5fed9f53e07ce9fc65efb4ff1abe021a4c16
- https://git.kernel.org/stable/c/ba2e7d07dd06e646a72ba906a89fdc1cca7ea560
- https://git.kernel.org/stable/c/d15946ef98f4ccdca961b76f90d9b53c454d590e
- https://git.kernel.org/stable/c/d58289fc77f8c1f879c818bddaf7ef524c73658b
- https://git.kernel.org/stable/c/f1c08947ab0538b07a0bd9d6edadfb5185f56344
Modified: 2026-01-23
CVE-2022-50434
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix possible memleak when register 'hctx' failed There's issue as follows when do fault injection test: unreferenced object 0xffff888132a9f400 (size 512): comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2.... 08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............ backtrace: [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0 [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0 [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230 [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910 [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0 [<00000000a2a34657>] 0xffffffffa2ad310f [<00000000b173f718>] 0xffffffffa2af824a [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0 [<00000000f32fdf93>] do_init_module+0xdf/0x320 [<00000000cbe8541e>] load_module+0x3006/0x3390 [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0 [<00000000a1a29ae8>] do_syscall_64+0x35/0x80 [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fault injection context as follows: kobject_add blk_mq_register_hctx blk_mq_sysfs_register blk_register_queue device_add_disk null_add_dev.part.0 [null_blk] As 'blk_mq_register_hctx' may already add some objects when failed halfway, but there isn't do fallback, caller don't know which objects add failed. To solve above issue just do fallback when add objects failed halfway in 'blk_mq_register_hctx'.
- https://git.kernel.org/stable/c/02bc8bc6eab03c84373281b85cb6e98747172ff7
- https://git.kernel.org/stable/c/33e8a3f61814ea30615d0fafaf50477975d6c1ca
- https://git.kernel.org/stable/c/4b7a21c57b14fbcd0e1729150189e5933f5088e9
- https://git.kernel.org/stable/c/4b7fafa5f39b15c3a6ca3b95e534d05d6904cc95
- https://git.kernel.org/stable/c/654870789c3c1b9763316ef1c71d7a449127b175
- https://git.kernel.org/stable/c/87fd18016a47ea8ae12641377a390172c4aa97a7
- https://git.kernel.org/stable/c/cb186eb47fb9dd327bdefa15f0c5fc55c53a40dd
- https://git.kernel.org/stable/c/e8022da1fa2fdf2fa204b445dd3354e7a66d085a
- https://git.kernel.org/stable/c/eff45bfbc25a2509a6362dea6e699e14083c693c
Modified: 2026-01-21
CVE-2022-50436
In the Linux kernel, the following vulnerability has been resolved: ext4: don't set up encryption key during jbd2 transaction Commit a80f7fcf1867 ("ext4: fixup ext4_fc_track_* functions' signature") extended the scope of the transaction in ext4_unlink() too far, making it include the call to ext4_find_entry(). However, ext4_find_entry() can deadlock when called from within a transaction because it may need to set up the directory's encryption key. Fix this by restoring the transaction to its original scope.
- https://git.kernel.org/stable/c/1ba993208bcfd691e241483420a2a761d3f15750
- https://git.kernel.org/stable/c/206dd3acfb9bca54a25b228c7c7c2257eedde09b
- https://git.kernel.org/stable/c/23ad034760dd38e12b0e0e1b28b9629f330810a1
- https://git.kernel.org/stable/c/4c0d5778385cb3618ff26a561ce41de2b7d9de70
- https://git.kernel.org/stable/c/6220ec405571ded17efedc56587190b542adf246
Modified: 2026-01-21
CVE-2022-50439
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8173: Enable IRQ when pdata is ready If the device does not come straight from reset, we might receive an IRQ before we are ready to handle it. [ 2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4 [ 2.522601] Call trace: [ 2.525040] regmap_read+0x1c/0x80 [ 2.528434] mt8173_afe_irq_handler+0x40/0xf0 ... [ 2.598921] start_kernel+0x338/0x42c
- https://git.kernel.org/stable/c/190685ff4ee03eef8f12c71d8f626e414fa078a9
- https://git.kernel.org/stable/c/27e7cf595d4a9fea9d3906b47d0faa87896beeb3
- https://git.kernel.org/stable/c/4cbb264d4e9136acab2c8fd39e39ab1b1402b84b
- https://git.kernel.org/stable/c/57491967ad8f865a9a81d08c36b26facd14d84e5
- https://git.kernel.org/stable/c/77c6b6be7e80ca4a4d4b66b63fd5bb48ccefdd5a
- https://git.kernel.org/stable/c/9ce9c78a2bdbc9a014e7102a35834310c28528b9
Modified: 2026-01-21
CVE-2022-50440
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate the box size for the snooped cursor Invalid userspace dma surface copies could potentially overflow the memcpy from the surface to the snooped image leading to crashes. To fix it the dimensions of the copybox have to be validated against the expected size of the snooped cursor.
- https://git.kernel.org/stable/c/439cbbc1519547f9a7b483f0de33b556ebfec901
- https://git.kernel.org/stable/c/4cf949c7fafe21e085a4ee386bb2dade9067316e
- https://git.kernel.org/stable/c/4d54d11b49860686331c58a00f733b16a93edfc4
- https://git.kernel.org/stable/c/50d177f90b63ea4138560e500d92be5e4c928186
- https://git.kernel.org/stable/c/622d527decaac0eb65512acada935a0fdc1d0202
- https://git.kernel.org/stable/c/6948e570f54f2044dd4da444b10471373a047eeb
- https://git.kernel.org/stable/c/6b4e70a428b5a11f56db94047b68e144529fe512
- https://git.kernel.org/stable/c/94b283341f9f3f0ed56a360533766377a01540e0
- https://git.kernel.org/stable/c/ee8d31836cbe7c26e207bfa0a4a726f0a25cfcf6
Modified: 2026-01-16
CVE-2022-50443
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: lvds: fix PM usage counter unbalance in poweron pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with the newest pm_runtime_resume_and_get to keep usage counter balanced.
- https://git.kernel.org/stable/c/110bf15825edf4f20bc4e56aba624297861b06ab
- https://git.kernel.org/stable/c/12a9b4c4ebd9a0ba856370e088564af83cffd565
- https://git.kernel.org/stable/c/4dba27f1a14592ac4cf71c3bc1cc1fd05dea8015
- https://git.kernel.org/stable/c/589a911980b730feadb9c430bc0747a118b04dd8
- https://git.kernel.org/stable/c/f6ed73db390319b248b91a6325da1a48ad85e0d1
Modified: 2026-01-16
CVE-2022-50449
In the Linux kernel, the following vulnerability has been resolved: clk: samsung: Fix memory leak in _samsung_clk_register_pll() If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.
- https://git.kernel.org/stable/c/2e8dc0626fe86ae08914478dec1419618c557bc0
- https://git.kernel.org/stable/c/4887ec922e407b4feaf060c7b099482a5c52dee3
- https://git.kernel.org/stable/c/4e501a31af8efa593a2f003637b56d00b75dca23
- https://git.kernel.org/stable/c/5174e5b0d1b669a489524192b6adcbb3c54ebc72
- https://git.kernel.org/stable/c/7b738276a596fa101d320591e9fa84ea0fc3f713
- https://git.kernel.org/stable/c/a00b4e0fa27317957536abf8f5d6a96d6cb9d9be
- https://git.kernel.org/stable/c/a35323218ff32782d051d2643912311a22e07b6a
- https://git.kernel.org/stable/c/da13355bb9961316d124f94dfc7a1385d0fb035a
Modified: 2026-01-16
CVE-2022-50453
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix NULL-pointer dereferences There are several places where we can crash the kernel by requesting lines, unbinding the GPIO device, then calling any of the system calls relevant to the GPIO character device's annonymous file descriptors: ioctl(), read(), poll(). While I observed it with the GPIO simulator, it will also happen for any of the GPIO devices that can be hot-unplugged - for instance any HID GPIO expander (e.g. CP2112). This affects both v1 and v2 uAPI. This fixes it partially by checking if gdev->chip is not NULL but it doesn't entirely remedy the situation as we still have a race condition in which another thread can remove the device after the check.
- https://git.kernel.org/stable/c/533aae7c94dbc2b14301cfd68ae7e0e90f0c8438
- https://git.kernel.org/stable/c/6d79546622baab843172b52c3af035f83c1b21df
- https://git.kernel.org/stable/c/7c755a2d6df511eeb5afba966ac28140f9ea5063
- https://git.kernel.org/stable/c/ac6ce3cd7a3e10a2e37b8970bab81b4d33d5cfc3
- https://git.kernel.org/stable/c/d66f68ac9e7ba46b6b90fbe25155723f2126088a
Modified: 2026-01-16
CVE-2022-50456
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix resolving backrefs for inline extent followed by prealloc If a file consists of an inline extent followed by a regular or prealloc extent, then a legitimate attempt to resolve a logical address in the non-inline region will result in add_all_parents reading the invalid offset field of the inline extent. If the inline extent item is placed in the leaf eb s.t. it is the first item, attempting to access the offset field will not only be meaningless, it will go past the end of the eb and cause this panic: [17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8 [17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI [17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty #199 [17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110 [17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202 [17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000 [17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001 [17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff [17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918 [17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd [17.663617] FS: 00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000 [17.666525] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0 [17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [17.676034] PKRU: 55555554 [17.677004] Call Trace: [17.677877] add_all_parents+0x276/0x480 [17.679325] find_parent_nodes+0xfae/0x1590 [17.680771] btrfs_find_all_leafs+0x5e/0xa0 [17.682217] iterate_extent_inodes+0xce/0x260 [17.683809] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.685597] ? iterate_inodes_from_logical+0xa1/0xd0 [17.687404] iterate_inodes_from_logical+0xa1/0xd0 [17.689121] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.691010] btrfs_ioctl_logical_to_ino+0x131/0x190 [17.692946] btrfs_ioctl+0x104a/0x2f60 [17.694384] ? selinux_file_ioctl+0x182/0x220 [17.695995] ? __x64_sys_ioctl+0x84/0xc0 [17.697394] __x64_sys_ioctl+0x84/0xc0 [17.698697] do_syscall_64+0x33/0x40 [17.700017] entry_SYSCALL_64_after_hwframe+0x44/0xae [17.701753] RIP: 0033:0x7f64e72761b7 [17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7 [17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003 [17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60 [17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001 [17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0 [17.724839] Modules linked in: Fix the bug by detecting the inline extent item in add_all_parents and skipping to the next extent item.
- https://git.kernel.org/stable/c/0061ab5153fb8bc574b44fbb773680d0ede48c9c
- https://git.kernel.org/stable/c/560840afc3e63bbe5d9c5ef6b2ecf8f3589adff6
- https://git.kernel.org/stable/c/645e2dac6e97f756f28a2f82b2e7bf7f29a68827
- https://git.kernel.org/stable/c/99590f29b2b7567fda2b503aa3d81a0d3e09dce5
- https://git.kernel.org/stable/c/a94b90ac1f251d1007c0c43ee289a61b50f2505f
- https://git.kernel.org/stable/c/c59ee1528b3432ec9dca220567f7eb507820917a
Modified: 2026-01-16
CVE-2022-50462
In the Linux kernel, the following vulnerability has been resolved: MIPS: vpe-mt: fix possible memory leak while module exiting Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, it need be freed when module exiting, call put_device() to give up reference, so that it can be freed in kobject_cleanup() when the refcount hit to 0. The vpe_device is static, so remove kfree() from vpe_device_release().
- https://git.kernel.org/stable/c/170e9913c2ed5cfc37c0adf0fdbd368d2d8d8168
- https://git.kernel.org/stable/c/48d42f4464d713fbdd79f334fdcd6e5be534cc67
- https://git.kernel.org/stable/c/5822e8cc84ee37338ab0bdc3124f6eec04dc232d
- https://git.kernel.org/stable/c/851ae5640875f06494e40002cd503b11a634c6fb
- https://git.kernel.org/stable/c/9d180e0bb21c57bd6cca2adeb672d3b522e910b5
- https://git.kernel.org/stable/c/ab3d47c1fd0202821abd473ca87580faafd47847
- https://git.kernel.org/stable/c/b191dde84e40624d5577f64db0ec922c5c0ec57c
- https://git.kernel.org/stable/c/b3325a443525e3b89151879b834519b21c5e3011
- https://git.kernel.org/stable/c/e820a8192ff68570100347855b567512aec43819
Modified: 2026-01-16
CVE-2022-50463
In the Linux kernel, the following vulnerability has been resolved: powerpc/52xx: Fix a resource leak in an error handling path The error handling path of mpc52xx_lpbfifo_probe() has a request_irq() that is not balanced by a corresponding free_irq(). Add the missing call, as already done in the remove function.
- https://git.kernel.org/stable/c/0accd460dc7bbe5f55e41a8867c63db9d07b3ec8
- https://git.kernel.org/stable/c/40b4be399e0db7073dec5a0de5ca9994f7e31e58
- https://git.kernel.org/stable/c/5836947613ef33d311b4eff6a32d019580a214f5
- https://git.kernel.org/stable/c/9bf842ffdd216b9f94d5b051b5d8b815f2426538
- https://git.kernel.org/stable/c/be9caf2c936f15a9c3f9111e62bdde6357312f90
- https://git.kernel.org/stable/c/cbda93665a3857324f5c79e45769a83c78183199
- https://git.kernel.org/stable/c/e4002f293e5b44e57d2930513cca0dff32249812
- https://git.kernel.org/stable/c/f4ad0a7f0e78d65d38921ab2bef234e49be78b10
- https://git.kernel.org/stable/c/fb3ef6a5af4b003502c940ea50c0f55b06ebbfc9
Modified: 2026-01-16
CVE-2022-50465
In the Linux kernel, the following vulnerability has been resolved: ext4: fix leaking uninitialized memory in fast-commit journal When space at the end of fast-commit journal blocks is unused, make sure to zero it out so that uninitialized memory is not leaked to disk.
- https://git.kernel.org/stable/c/594bc43b410316d70bb42aeff168837888d96810
- https://git.kernel.org/stable/c/7c1fb65e8ce85c281d2cba9c236f9edbbc4eaca6
- https://git.kernel.org/stable/c/871800770d7f2f952c7249ad52485c3564dab44e
- https://git.kernel.org/stable/c/b8b7922374b00a44137e5bcdd46ef86c8b065f27
- https://git.kernel.org/stable/c/d9ba03eb03dc2dccb5450de388ea46bdcaaf8348
Modified: 2026-01-16
CVE-2022-50468
In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()
The following WARNING message was given when rmmod cros_usbpd_notify:
Unexpected driver unregister!
WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0
Modules linked in: cros_usbpd_notify(-)
CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24
...
Call Trace:
- https://git.kernel.org/stable/c/5a2d96623670155d94aca72c320c0ac27bdc6bd2
- https://git.kernel.org/stable/c/5c0cacdd354987f8f5348d16908716f154047890
- https://git.kernel.org/stable/c/751f12696d797e785d2611099fe9f0569d47556e
- https://git.kernel.org/stable/c/7b6ee54995739202b4a0cc01b7e9269f761c573d
- https://git.kernel.org/stable/c/cab345f9d51943898e406275f9607c145adb1877
Modified: 2026-01-23
CVE-2022-50473
In the Linux kernel, the following vulnerability has been resolved: cpufreq: Init completion before kobject_init_and_add() In cpufreq_policy_alloc(), it will call uninitialed completion in cpufreq_sysfs_release() when kobject_init_and_add() fails. And that will cause a crash such as the following page fault in complete: BUG: unable to handle page fault for address: fffffffffffffff8 [..] RIP: 0010:complete+0x98/0x1f0 [..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
- https://git.kernel.org/stable/c/3cdd91a9163248935720927531066b74f57aa43b
- https://git.kernel.org/stable/c/5c51054896bcce1d33d39fead2af73fec24f40b6
- https://git.kernel.org/stable/c/8fb4c98f20dfca1237de2e3dfdbe78d156784fd3
- https://git.kernel.org/stable/c/d88540acfc7a17079021d866de914112c396edb1
- https://git.kernel.org/stable/c/e379b88a8f8cffc99b318e028705ed9e3da0e1e0
- https://git.kernel.org/stable/c/e7c0c943ed675b66d4bbb16c51c6a3bb58da047e
Modified: 2026-01-23
CVE-2022-50474
In the Linux kernel, the following vulnerability has been resolved: macintosh: fix possible memory leak in macio_add_one_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically. It needs to be freed when of_device_register() fails. Call put_device() to give up the reference that's taken in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hits 0. macio device is freed in macio_release_dev(), so the kfree() can be removed.
- https://git.kernel.org/stable/c/19ded60b40e86b0903c8d5bd0161437ed5107a8b
- https://git.kernel.org/stable/c/2ac0a7059b7bcbed35bfffa34a82c9a9e99638ef
- https://git.kernel.org/stable/c/35858b87a943917fa30172aa4bf01ce7adbcb42c
- https://git.kernel.org/stable/c/3a866ff6fc2232c8e393cdb55ffb8ce947349e03
- https://git.kernel.org/stable/c/5ca86eae55a2f006e6c1edd2029b2cacb6979515
- https://git.kernel.org/stable/c/76837e7f6b30da72ad59f56291e22804a219e015
- https://git.kernel.org/stable/c/aa9054267366ff0a382d403d17728e21951ddbb9
- https://git.kernel.org/stable/c/b29a2f1dd33ae9b94821ab2f4d398b9081786748
- https://git.kernel.org/stable/c/ca765257feb89dacf604ced9cd233db5f865dee0
Modified: 2026-01-23
CVE-2022-50476
In the Linux kernel, the following vulnerability has been resolved: ntb_netdev: Use dev_kfree_skb_any() in interrupt context TX/RX callback handlers (ntb_netdev_tx_handler(), ntb_netdev_rx_handler()) can be called in interrupt context via the DMA framework when the respective DMA operations have completed. As such, any calls by these routines to free skb's, should use the interrupt context safe dev_kfree_skb_any() function. Previously, these callback handlers would call the interrupt unsafe version of dev_kfree_skb(). This has not presented an issue on Intel IOAT DMA engines as that driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD systems, a kernel WARNING message is encountered, which is being issued from skb_release_head_state() due to in_hardirq() being true. Besides the user visible WARNING from the kernel, the other symptom of this bug was that TCP/IP performance across the ntb_netdev interface was very poor, i.e. approximately an order of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from skb_release_head_state() ceased and TCP/IP performance, as measured by iperf, was on par with expected results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with Intel based servers.
- https://git.kernel.org/stable/c/07e28a8f450217db679802ebd4de0915556ce846
- https://git.kernel.org/stable/c/13286ad1c7c49c606fdcba4cf66f953a1a16c1ca
- https://git.kernel.org/stable/c/14d245da57a11e80277ab455aa9b6dcc5ed38a19
- https://git.kernel.org/stable/c/21296a52caa6a6bad6debdfe40ad81d4f1a27e69
- https://git.kernel.org/stable/c/5f7d78b2b12a9d561f48fa00bab29b40f4616dad
- https://git.kernel.org/stable/c/8b78493968ed3cef0326183ed059c55e42f24d5b
- https://git.kernel.org/stable/c/a6b9e09403102bdf8402dae734800e4916c7ea58
- https://git.kernel.org/stable/c/d4460c82177899751975180c268f352893302221
- https://git.kernel.org/stable/c/dd860b39aa7c7b82e6c99b6fdb99d4610ce49d67
Modified: 2026-01-23
CVE-2022-50478
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()
Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount
time".
The first patch fixes a bug reported by syzbot, and the second one fixes
the remaining bug of the same kind. Although they are triggered by the
same super block data anomaly, I divided it into the above two because the
details of the issues and how to fix it are different.
Both are required to eliminate the shift-out-of-bounds issues at mount
time.
This patch (of 2):
If the block size exponent information written in an on-disk superblock is
corrupted, nilfs_sb2_bad_offset helper function can trigger
shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn
is set):
shift exponent 38983 is too large for 64-bit type 'unsigned long long'
Call Trace:
- https://git.kernel.org/stable/c/1012ff77284e3bec0ec0a35a820b03ec43dec2cc
- https://git.kernel.org/stable/c/610a2a3d7d8be3537458a378ec69396a76c385b6
- https://git.kernel.org/stable/c/62d11ec205ef14d8acf172cfc9904fdbf200025a
- https://git.kernel.org/stable/c/6b0ea3df56cccd53398d0289f399f19d43136b2e
- https://git.kernel.org/stable/c/9b3ba54025357440d6c4414c670984f628c6f6bf
- https://git.kernel.org/stable/c/a6f89b10042baca218c8598d6db5a44c7e32625f
- https://git.kernel.org/stable/c/b47f5c579c8186f7f5ab5e4254e0734ea5b7bf7a
- https://git.kernel.org/stable/c/d464b035c0613856d012cf1704879d3ff3f057fb
- https://git.kernel.org/stable/c/d706485dffbbbf848e681edda29c7a46ac55698c
Modified: 2026-01-23
CVE-2022-50481
In the Linux kernel, the following vulnerability has been resolved: cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter() If device_register() fails in cxl_register_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails.
- https://git.kernel.org/stable/c/170e8c2d2b61e15e7f7cfeded81bc1e959a15ed8
- https://git.kernel.org/stable/c/1ae581696b7a799afa39a664c4b721569643f58a
- https://git.kernel.org/stable/c/60b2ed21a65f3f5318666ccd765c3507991370cf
- https://git.kernel.org/stable/c/61c80d1c3833e196256fb060382db94f24d3d9a7
- https://git.kernel.org/stable/c/96fba6fb95bdede80583c262ac185da09661f264
- https://git.kernel.org/stable/c/ab44c182353be101c3be9465e1d15d42130c53c4
- https://git.kernel.org/stable/c/b32559ee4e6667c5c3daf4ec5454c277d1f255d2
- https://git.kernel.org/stable/c/d775a1da5a52b4f4bb02f2707ba420d1bec48dbb
- https://git.kernel.org/stable/c/e5021bbf11b024cc65ea1e84c377df484183be4b
Modified: 2026-03-25
CVE-2022-50485
In the Linux kernel, the following vulnerability has been resolved: ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode There are many places that will get unhappy (and crash) when ext4_iget() returns a bad inode. However, if iget the boot loader inode, allows a bad inode to be returned, because the inode may not be initialized. This mechanism can be used to bypass some checks and cause panic. To solve this problem, we add a special iget flag EXT4_IGET_BAD. Only with this flag we'd be returning bad inode from ext4_iget(), otherwise we always return the error code if the inode is bad inode.(suggested by Jan Kara)
- https://git.kernel.org/stable/c/2142dfa1de61e25b83198af0308ec7689cca25d3
- https://git.kernel.org/stable/c/488a5c2bf7543c3cd3f07a025f2e62be91599430
- https://git.kernel.org/stable/c/63b1e9bccb71fe7d7e3ddc9877dbdc85e5d2d023
- https://git.kernel.org/stable/c/c0a738875c2e9c8c3366d792f8bf7fe508d5e5a5
- https://git.kernel.org/stable/c/f725b290ed79ad61e4f721fee95a287892d8b1ad
- https://git.kernel.org/stable/c/f7e6b5548f915d7aa435d0764d41eacfb49c6e09
Modified: 2026-03-25
CVE-2022-50486
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: Fix return type of netcp_ndo_start_xmit() 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. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netcp_ndo_start_xmit, ^~~~~~~~~~~~~~~~~~~~ 1 error generated. ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of netcp_ndo_start_xmit() to match the prototype's to resolve the warning and CFI failure.
- https://git.kernel.org/stable/c/17bb9bdf701f3e811a9f4820b08b9538ade2641c
- https://git.kernel.org/stable/c/1e4953b826e12b31995564a459dbd4e9e4604a35
- https://git.kernel.org/stable/c/5b0b6553bf4ad3a435a57e02c68d6075f384e1be
- https://git.kernel.org/stable/c/63fe6ff674a96cfcfc0fa8df1051a27aa31c70b4
- https://git.kernel.org/stable/c/765636e58ba505cfe4927eda7ee83791b1c6402a
- https://git.kernel.org/stable/c/a413ebb6049edd881c6427cfa25a7efddd6a4f74
- https://git.kernel.org/stable/c/a447479ea2cf35603b5739ea947885024b901222
- https://git.kernel.org/stable/c/d837d74eae077cc3ef9e191ba8535b5f602d4673
- https://git.kernel.org/stable/c/dbe1a6b930ae9647e8ce0b684c903ac67d4398eb
Modified: 2026-01-22
CVE-2022-50496
In the Linux kernel, the following vulnerability has been resolved: dm cache: Fix UAF in destroy() Dm_cache also has the same UAF problem when dm_resume() and dm_destroy() are concurrent. Therefore, cancelling timer again in destroy().
- https://git.kernel.org/stable/c/034cbc8d3b47a56acd89453c29632a9c117de09d
- https://git.kernel.org/stable/c/2b17026685a270b2beaf1cdd9857fcedd3505c7e
- https://git.kernel.org/stable/c/2f097dfac7579fd84ff98eb1d3acd41d53a485f3
- https://git.kernel.org/stable/c/4d20032dd90664de09f2902a7ea49ae2f7771746
- https://git.kernel.org/stable/c/6a3e412c2ab131c54945327a7676b006f000a209
- https://git.kernel.org/stable/c/6a459d8edbdbe7b24db42a5a9f21e6aa9e00c2aa
- https://git.kernel.org/stable/c/6ac4f36910764cb510bafc4c3768544f86ca48ca
- https://git.kernel.org/stable/c/993406104d2b28fe470126a062ad37a1e21e792e
- https://git.kernel.org/stable/c/d2a0b298ebf83ab6236f66788a3541e91ce75a70
Modified: 2026-01-22
CVE-2022-50497
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: fix shift-out-of-bounds in check_special_flags
UBSAN reported a shift-out-of-bounds warning:
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/0f1a48994b3e516d5c7fd5d12204fdba7a604771
- https://git.kernel.org/stable/c/419b808504c26b3e3342365f34ccd0843e09a7f8
- https://git.kernel.org/stable/c/6a46bf558803dd2b959ca7435a5c143efe837217
- https://git.kernel.org/stable/c/88cea1676a09f7c45a1438153a126610c33b1590
- https://git.kernel.org/stable/c/97382a2639b1cd9631f6069061e9d7062cd2b098
- https://git.kernel.org/stable/c/a651bb5ff997b9f02662bcdef3d8b4e6f0d79656
- https://git.kernel.org/stable/c/a91123d4bda463469f68f0427adabf8108001f94
- https://git.kernel.org/stable/c/dcbc51d31d0afbd45e830e3cf565a7b3ca7bf0d8
- https://git.kernel.org/stable/c/ea6145370be8016755c43aca799815fc4b8c88b1
Modified: 2026-01-22
CVE-2022-50499
In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: Fix double free in dvb_register_device() In function dvb_register_device() -> dvb_register_media_device() -> dvb_create_media_entity(), dvb->entity is allocated and initialized. If the initialization fails, it frees the dvb->entity, and return an error code. The caller takes the error code and handles the error by calling dvb_media_device_free(), which unregisters the entity and frees the field again if it is not NULL. As dvb->entity may not NULLed in dvb_create_media_entity() when the allocation of dvbdev->pad fails, a double free may occur. This may also cause an Use After free in media_device_unregister_entity(). Fix this by storing NULL to dvb->entity when it is freed.
- https://git.kernel.org/stable/c/0588b12c418c3e4f927ced11f27b02ef4a5bfb07
- https://git.kernel.org/stable/c/123eddf92a114e03919942641d2c2b1f4ca56ea6
- https://git.kernel.org/stable/c/6b0d0477fce747d4137aa65856318b55fba72198
- https://git.kernel.org/stable/c/70bc51303871159796b55ba1a8f16637b46c2511
- https://git.kernel.org/stable/c/772892b29ac50c2c5e918fc80104aa6ede81d837
- https://git.kernel.org/stable/c/7dd5a68cdbbbe7fc67ba701cb52ba10d8ba149f8
- https://git.kernel.org/stable/c/acf984a3718c2458eb9e08b6714490a04f213c58
- https://git.kernel.org/stable/c/b21f62b49ee9c3e0216d685d9cfd6003e5727271
- https://git.kernel.org/stable/c/e9a78485b658361fab6a5547377be6c1af6f1b3d
Modified: 2026-01-22
CVE-2022-50501
In the Linux kernel, the following vulnerability has been resolved: media: coda: Add check for dcoda_iram_alloc As the coda_iram_alloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others.
- https://git.kernel.org/stable/c/05f165ded4a7baec31b65aba88e2cd1fb9b91db2
- https://git.kernel.org/stable/c/2b436f1410245412ea5e4c356a175a928d73eed3
- https://git.kernel.org/stable/c/2c6887d5a29024bada6928d1d0959c9990401384
- https://git.kernel.org/stable/c/35ddd00b36589cf948875b825eedaab1aefd5ad5
- https://git.kernel.org/stable/c/45f57abaee136a1e39d2b04443a1bd5311ba7d94
- https://git.kernel.org/stable/c/532417dc98cb9c1185ada4ea4e7ccf965c06bcb5
- https://git.kernel.org/stable/c/5688d33aa293dfa122d66bef9c0258ddf7ef11e7
- https://git.kernel.org/stable/c/6b8082238fb8bb20f67e46388123e67a5bbc558d
- https://git.kernel.org/stable/c/b99872178e7473f21904fdeea38109275aad8ae8
Modified: 2026-01-22
CVE-2022-50503
In the Linux kernel, the following vulnerability has been resolved: mtd: lpddr2_nvm: Fix possible null-ptr-deref It will cause null-ptr-deref when resource_size(add_range) invoked, if platform_get_resource() returns NULL.
- https://git.kernel.org/stable/c/0919982a1744346269320615615c7deb14106661
- https://git.kernel.org/stable/c/4d10bd7416e8383340b5524b8d616b8ad01ef1e1
- https://git.kernel.org/stable/c/6bdd45d795adf9e73b38ced5e7f750cd199499ff
- https://git.kernel.org/stable/c/8eb64dc5a790a529ef49ec94b3337af09dac15d3
- https://git.kernel.org/stable/c/bb9ccb6121ec4140d366147aa866ceb5a21a8d3d
- https://git.kernel.org/stable/c/c4cc41e94d8357f5f02b8ef40257bb23931d8438
- https://git.kernel.org/stable/c/e0d3e46ac6669cdf1b99bc7b7d92f1221b9a1ff2
- https://git.kernel.org/stable/c/e6aafb57d90ff2c1e18554f3a3c36247a59825ce
- https://git.kernel.org/stable/c/f82f63b3911f1b2da68a14d9c4babf3b55feca55
Modified: 2026-01-22
CVE-2022-50504
In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: avoid scheduling in rtas_os_term() It's unsafe to use rtas_busy_delay() to handle a busy status from the ibm,os-term RTAS function in rtas_os_term(): Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9 Call Trace: [c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable) [c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0 [c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0 [c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4 [c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68 [c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50 [c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0 [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0 [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0 [c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420 [c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200 Use rtas_busy_delay_time() instead, which signals without side effects whether to attempt the ibm,os-term RTAS call again.
- https://git.kernel.org/stable/c/4768935b8cc2d2afeb7956292df0f6e2c49ca0a5
- https://git.kernel.org/stable/c/482d990a5dd1027ee0b70a8a570d56749cac8103
- https://git.kernel.org/stable/c/515959eb49e6d218a46979d66f36fdef329ac7d2
- https://git.kernel.org/stable/c/6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4
- https://git.kernel.org/stable/c/6f7e2fcab73372a371ab4017cbedf7a71f4f9b40
- https://git.kernel.org/stable/c/7280fdb80bf0fe35d9b799fc7009f2cbe0a397d7
- https://git.kernel.org/stable/c/bed48651c87bef59ea1a9d6dbc381bcbc452f4ff
- https://git.kernel.org/stable/c/f413135b337c4e90c1e593c6613f8717e17bc724
- https://git.kernel.org/stable/c/ffa991a003abb4f8cb9e5004646bfe2d9a46912c
Modified: 2026-03-25
CVE-2022-50505
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix pci device refcount leak in ppr_notifier() 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 before returning from ppr_notifier() to avoid refcount leak.
- https://git.kernel.org/stable/c/03f51c72997559e73b327608f0cccfded715c9a0
- https://git.kernel.org/stable/c/6cf0981c2233f97d56938d9d61845383d6eb227c
- https://git.kernel.org/stable/c/6e501b3fd7a2e1c4372d72bc70717aaca2beb8a5
- https://git.kernel.org/stable/c/8581ec1feb895ff596fe3d326d9ba320083290aa
- https://git.kernel.org/stable/c/902cc2507091a81643502d8ceb0e2f105e902518
- https://git.kernel.org/stable/c/b0637f4bd426925f5c3a15e8f8e36190fe06bac5
- https://git.kernel.org/stable/c/bdb2113dd8f17a3cc84a2b4be4968a849f69ec72
- https://git.kernel.org/stable/c/efd50c65fd1cdef63eb58825f3fe72496443764c
Modified: 2026-03-17
CVE-2022-50509
In the Linux kernel, the following vulnerability has been resolved: media: coda: Add check for kmalloc As the kmalloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others.
- https://git.kernel.org/stable/c/0209e70ad496c1fcd85c2ec70e6736fd09f95d14
- https://git.kernel.org/stable/c/11e32126b3e56c3156fb610d793732acd2bdac4f
- https://git.kernel.org/stable/c/441c05485cf1a29eef05c1fd8281716815283315
- https://git.kernel.org/stable/c/6e5e5defdb8b0186312c2f855ace175aee6daf9b
- https://git.kernel.org/stable/c/7a2c66429b04e85fee44d6d9f455327bf23cf49c
- https://git.kernel.org/stable/c/aa17a252dbde432095e390e2092205d4debb12e1
- https://git.kernel.org/stable/c/ba9cc9e2035f7a45f5222543265daf7cd51f2530
- https://git.kernel.org/stable/c/d308c4a035b636756786af91e5f39f9d92d7d42a
- https://git.kernel.org/stable/c/d9b37ea8869e4e6da90c07a310d819a78cbd23d2
Modified: 2026-03-17
CVE-2022-50510
In the Linux kernel, the following vulnerability has been resolved: perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init() arm_smmu_pmu_init() won't remove the callback added by cpuhp_setup_state_multi() when platform_driver_register() failed. Remove the callback by cpuhp_remove_multi_state() in fail path. Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus: arm-ccn: Prevent hotplug callback leak")
- https://git.kernel.org/stable/c/359286f886feef38536eaa7e673dc3440f03b0a1
- https://git.kernel.org/stable/c/582babe17ea878ec1d76f30e03f3a6ce6e30eb91
- https://git.kernel.org/stable/c/6f2d566b46436a50a80d6445e82879686b89588c
- https://git.kernel.org/stable/c/b131304fe722853cf26e55c4fa21fc58a36e7f21
- https://git.kernel.org/stable/c/d69bdb61d577297d3851fc9f6403574bf73ef41f
- https://git.kernel.org/stable/c/f245ca9a0fe7f794a8187ad803d5e2ced5a11cb2
Modified: 2026-03-17
CVE-2022-50511
In the Linux kernel, the following vulnerability has been resolved:
lib/fonts: fix undefined behavior in bit shift for get_default_font
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 lib/fonts/fonts.c:139:20
left shift of 1 by 31 places cannot be represented in type 'int'
- https://git.kernel.org/stable/c/6fe888c4d2fb174408e4540bb2d5602b9f507f90
- https://git.kernel.org/stable/c/890d91b31f4874361e0df047f57d268a7021cb12
- https://git.kernel.org/stable/c/9c14a85e18a58c102ec223144b7edb5b345c1bea
- https://git.kernel.org/stable/c/c9a9aa02f0fa3318e0ae5774f404419a1b4759ca
- https://git.kernel.org/stable/c/e039929e36818507e90901edae87f6fa8bc81093
- https://git.kernel.org/stable/c/e83b47580a0738361772d6f24286adfdaba57e36
Modified: 2026-03-17
CVE-2022-50514
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: fix refcount leak on error path When failing to allocate report_desc, opts->refcnt has already been incremented so it needs to be decremented to avoid leaving the options structure permanently locked.
- https://git.kernel.org/stable/c/216437dd64fce36791a3b6cc8f8013df36856958
- https://git.kernel.org/stable/c/70a3288a7586526315105c699b687d78cd32559a
- https://git.kernel.org/stable/c/80dc47e751a837106c09bec73964ff8f7ea280b4
- https://git.kernel.org/stable/c/95412c932b3c9e8cc4431dac4fac8fcd80d54982
- https://git.kernel.org/stable/c/9d4a0aca8a75550d3456c8de339a341dc4536ec5
- https://git.kernel.org/stable/c/ba78f7c10606719f702c04a15fb0471507b32d7b
- https://git.kernel.org/stable/c/e88b89a096af0001bcff6bf7ad2feb1486487173
Modified: 2026-03-17
CVE-2022-50520
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios() As comment of pci_get_class() says, it returns a pci_device with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL. If we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, we need to call pci_dev_put() to decrease the refcount. Add the missing pci_dev_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1079df6acf56f99d86b0081a38c84701412cc90e
- https://git.kernel.org/stable/c/3991d98a8a07b71c02f3a39f77d6d9a7f575a5c4
- https://git.kernel.org/stable/c/470a77989037c3ab2b08bf2d026d2c0ddc35ff5b
- https://git.kernel.org/stable/c/6f28c7f67af4ef9bca580ab67ae2d4511797af56
- https://git.kernel.org/stable/c/725a521a18734f65de05b8d353b5bd0d3ca4c37a
- https://git.kernel.org/stable/c/88c6e0995c04b170563b5c894c50a3b2152e18c2
- https://git.kernel.org/stable/c/a6cffe54064a5f6c2162a85af3c16c6b453eac4e
- https://git.kernel.org/stable/c/b9decada8749b606fd8b4f04a3d6c74f7983d7bc
- https://git.kernel.org/stable/c/e738f82e5b1311e8fb3d1409491a6fcce6418fbe
Modified: 2026-03-17
CVE-2022-50521
In the Linux kernel, the following vulnerability has been resolved: platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]() The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, so it leads to memory leak. The method results in ACPI buffer is not used, so just pass NULL to wmi_evaluate_method() which fixes the memory leak.
- https://git.kernel.org/stable/c/14bb4bde3b7b2584734b13747b345caeeb41bea3
- https://git.kernel.org/stable/c/17cd8c46cbec4e6ad593fb9159928b8e7608c11a
- https://git.kernel.org/stable/c/379e7794c5e7485193d25d73614fbbd1e1387f6f
- https://git.kernel.org/stable/c/3cf81501356c9e898ad94b2369ffc805f83f7d7b
- https://git.kernel.org/stable/c/50ac517d6f5348b276f1f663799cf85dce521518
- https://git.kernel.org/stable/c/5b0f81b0808235967868e01336c976e840217108
- https://git.kernel.org/stable/c/727cc0147f5066e359aca65cc6cc5e6d64cc15d8
- https://git.kernel.org/stable/c/87426ce3bd57ad414b6e2436434ef8128986a9a5
Modified: 2026-03-17
CVE-2022-50522
In the Linux kernel, the following vulnerability has been resolved: mcb: mcb-parse: fix error handing in chameleon_parse_gdd() If mcb_device_register() returns error in chameleon_parse_gdd(), the refcount of bus and device name are leaked. Fix this by calling put_device() to give up the reference, so they can be released in mcb_release_dev() and kobject_cleanup().
- https://git.kernel.org/stable/c/110dc34c9fa33d37f55b394b1199ea6c0ad1ee84
- https://git.kernel.org/stable/c/43bfc7c2402a22d3b4eb08c040f274ba2b76461a
- https://git.kernel.org/stable/c/4a9f1a8b3af287581ffb690d0e1593c681729ddb
- https://git.kernel.org/stable/c/728ac3389296caf68638628c987aeae6c8851e2d
- https://git.kernel.org/stable/c/7b289b791a59386dc23a00d3cf17a0db984b40d3
- https://git.kernel.org/stable/c/891f606ae0765bc9ca99f5276735be4d338f0255
- https://git.kernel.org/stable/c/b948baa29394ec5f4e6ec28486e7d06a76caee91
- https://git.kernel.org/stable/c/cf6e70c0ced50b52415ac0c88eba1fb09c500a5a
- https://git.kernel.org/stable/c/fd85ece416fd7edb945203e59d4cd94952f77e7c
Modified: 2026-03-17
CVE-2022-50523
In the Linux kernel, the following vulnerability has been resolved: clk: rockchip: Fix memory leak in rockchip_clk_register_pll() If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.
- https://git.kernel.org/stable/c/20201c3a0a32f127fa4bdf379d6ac01c2978702d
- https://git.kernel.org/stable/c/26b94635f1c84d7f6cb482179125cb17e59c90a5
- https://git.kernel.org/stable/c/5b0a1f1247cd42ac5e0d369f8dbb58762692edee
- https://git.kernel.org/stable/c/739a6a6bbdb793bd57938cb24aa5a6df89983546
- https://git.kernel.org/stable/c/86e1e080ad14c5fb6c14a5f0eb530b1b38cbc968
- https://git.kernel.org/stable/c/dcd4ba068b194c6ef0071491aa3f12bec8c14d5b
- https://git.kernel.org/stable/c/f02c1d8dc8d880cbaaf9094b4f396fe868ee23ff
- https://git.kernel.org/stable/c/f2ffb8653ea85ae39ce44347751fcc4c3e41f6bb
- https://git.kernel.org/stable/c/f4d70c139d313948e02360304a6cbcd3a4f5deb5
Modified: 2026-03-17
CVE-2022-50525
In the Linux kernel, the following vulnerability has been resolved: iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe() The fsl_pamu_probe() returns directly when create_csd() failed, leaving irq and memories unreleased. Fix by jumping to error if create_csd() returns error.
- https://git.kernel.org/stable/c/0d240ac0e4c35d3f64fc782c11433138c1bd016e
- https://git.kernel.org/stable/c/17fd440594961c5e2ea0f58591bc1bdba0629c75
- https://git.kernel.org/stable/c/73f5fc5f884ad0c5f7d57f66303af64f9f002526
- https://git.kernel.org/stable/c/9238b687fd62cde14c6e2e8576a40e4246de7ebe
- https://git.kernel.org/stable/c/9fbccdf2fefa3944dd8ba8c6a808b387787f3917
- https://git.kernel.org/stable/c/a305d0e4d0ce3166e31d7dbcb4c98b09cad6d49a
- https://git.kernel.org/stable/c/c93983230562883e0b5f122040efbb3d478c36d4
- https://git.kernel.org/stable/c/de7eb55009796687fc0a1670e0b944fa8ed54e9b
- https://git.kernel.org/stable/c/e42b543d08052c3b223bcfb48f05cbaf0b767f86
Modified: 2026-03-17
CVE-2022-50529
In the Linux kernel, the following vulnerability has been resolved:
test_firmware: fix memory leak in test_firmware_init()
When misc_register() failed in test_firmware_init(), the memory pointed
by test_fw_config->name is not released. The memory leak information is
as follows:
unreferenced object 0xffff88810a34cb00 (size 32):
comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s)
hex dump (first 32 bytes):
74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi
6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n...............
backtrace:
[
- https://git.kernel.org/stable/c/04dd47a2e169f2d4489636afa07ff0469aab49ab
- https://git.kernel.org/stable/c/0b5a89e8bce1ea43687742b4de8e216189ff94ac
- https://git.kernel.org/stable/c/357379d504c0c8b0834e206ad8c49e4b3c98ed4d
- https://git.kernel.org/stable/c/628de998a3abfffb3f9677d2fb39a1d5dcb32fdb
- https://git.kernel.org/stable/c/6dd5fbd243f19f087dc79481acb7d69fb57fea2c
- https://git.kernel.org/stable/c/7610615e8cdb3f6f5bbd9d8e7a5d8a63e3cabf2e
- https://git.kernel.org/stable/c/8d8c1d6a430f0aadb80036e2b1bc0a05f9fad247
- https://git.kernel.org/stable/c/ed5cbafaf7ce8b86f19998c00eb020c8d49b017f
Modified: 2026-03-17
CVE-2022-50532
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add() In mpt3sas_transport_port_add(), if sas_rphy_add() returns error, sas_rphy_free() needs be called to free the resource allocated in sas_end_device_alloc(). Otherwise a kernel crash will happen: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189 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_rphy_remove+0x50/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_rphy_remove+0x38/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] scsih_remove+0xd8/0x420 [mpt3sas] Because transport_add_device() is not called when sas_rphy_add() fails, the device is not added. When sas_rphy_remove() is subsequently called to remove the device in the remove() path, a NULL pointer dereference happens.
- https://git.kernel.org/stable/c/6a92129c8f999ff5b122c100ce7f625eb3e98c4b
- https://git.kernel.org/stable/c/6f6768e2fc8638fabdd8802c2ef693d7aef01db1
- https://git.kernel.org/stable/c/78316e9dfc24906dd474630928ed1d3c562b568e
- https://git.kernel.org/stable/c/ce1a69cc85006b494353911b35171da195d79e25
- https://git.kernel.org/stable/c/d17bca3ddfe507874cb826d32721552da12e741f
- https://git.kernel.org/stable/c/d60000cb1195a464080b0efb4949daf7594e0020
Modified: 2026-03-17
CVE-2022-50534
In the Linux kernel, the following vulnerability has been resolved:
dm thin: Use last transaction's pmd->root when commit failed
Recently we found a softlock up problem in dm thin pool btree lookup
code due to corrupted metadata:
Kernel panic - not syncing: softlockup: hung tasks
CPU: 7 PID: 2669225 Comm: kworker/u16:3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: dm-thin do_worker [dm_thin_pool]
Call Trace:
- https://git.kernel.org/stable/c/3db757ffdd87ed8d7118b2250236a496502a660f
- https://git.kernel.org/stable/c/4b710e8481ade7c9200e94d3018e99dc42a0a0e8
- https://git.kernel.org/stable/c/7991dbff6849f67e823b7cc0c15e5a90b0549b9f
- https://git.kernel.org/stable/c/87d69b8824ca9b090f5a8ed47f758e8f6eecb871
- https://git.kernel.org/stable/c/94f01ecc2aa0be992865acc80ebb6701f731f955
- https://git.kernel.org/stable/c/a63ce4eca86fd207e3db07c00fb7ccf4adf1b230
- https://git.kernel.org/stable/c/b35a22760aa5008d82533e59b0f0b5eb1b02d4e5
- https://git.kernel.org/stable/c/b91f481300e3a10eaf66b94fc39b740928762aaf
- https://git.kernel.org/stable/c/f758987ff0af3a4b5ee69e95cab6a5294e4367b0
Modified: 2026-02-26
CVE-2022-50536
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data
In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,
sock_put() will be called multiple times.
We should reset the eval variable to __SK_NONE every time more_data
starts.
This causes:
IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110
Modules linked in:
CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1
Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/113236e8f49f262f318c00ebb14b15f4834e87c1
- https://git.kernel.org/stable/c/28e4a763cd4a2b1a78852216ef4bd7df3a05cec6
- https://git.kernel.org/stable/c/578a7628b838a3ac8ad61deaab5a816ff032ac13
- https://git.kernel.org/stable/c/7508b9f4daac4ec7dfe0b6fb2d688b1c1c105e10
- https://git.kernel.org/stable/c/7a9841ca025275b5b0edfb0b618934abb6ceec15
- https://git.kernel.org/stable/c/8786bde11a4f31b63b3036731df0b47337a7a245
Modified: 2026-02-26
CVE-2022-50537
In the Linux kernel, the following vulnerability has been resolved: firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe() In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will not be freed through rpi_firmware_delete(), fix this leak by calling kfree() in the error path.
- https://git.kernel.org/stable/c/62ac943eb2a9d655e431b9bc98ff6d7bd51a0e49
- https://git.kernel.org/stable/c/6757dd2193fe18c5c5fe3050e7f2ff9dcbd1ff34
- https://git.kernel.org/stable/c/71d2abab374f707ab8ac8dcef191fd2b3b67b8bd
- https://git.kernel.org/stable/c/7b51161696e803fd5f9ad55b20a64c2df313f95c
- https://git.kernel.org/stable/c/b308fdedef095aac14569f810d46edf773ea7d1e
- https://git.kernel.org/stable/c/d34742245e4366579f9a80f8cfe4a63248e838e0
Modified: 2026-02-26
CVE-2022-50538
In the Linux kernel, the following vulnerability has been resolved:
vme: Fix error not catched in fake_init()
In fake_init(), __root_device_register() is possible to fail but it's
ignored, which can cause unregistering vme_root fail when exit.
general protection fault,
probably for non-canonical address 0xdffffc000000008c
KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467]
RIP: 0010:root_device_unregister+0x26/0x60
Call Trace:
- https://git.kernel.org/stable/c/09be0e7ac5f9374b6f8de72c89ed67129af71f65
- https://git.kernel.org/stable/c/37d3de40c1ffb6a5e626bf46ff5ef5766c824e2c
- https://git.kernel.org/stable/c/4bc217b25ea81034fad8e33fd33e4659f086421d
- https://git.kernel.org/stable/c/60ff9bd4ffc87bace581e235a6728f5ac8e5071f
- https://git.kernel.org/stable/c/69b43937f14bdc3594f57f1a507a14f3d1187136
- https://git.kernel.org/stable/c/7bef797d707f1744f71156b21d41e3b8c946631f
- https://git.kernel.org/stable/c/a2a93546d414c7fe4862b87183fb737d1300d9d2
- https://git.kernel.org/stable/c/e831fdd60e5863ee03173baf5a0f7c5450b44381
- https://git.kernel.org/stable/c/f3f65c4177846c483bf009f8c512ab04b3c62466
Modified: 2026-02-26
CVE-2022-50542
In the Linux kernel, the following vulnerability has been resolved: media: si470x: Fix use-after-free in si470x_int_in_callback() syzbot reported use-after-free in si470x_int_in_callback() [1]. This indicates that urb->context, which contains struct si470x_device object, is freed when si470x_int_in_callback() is called. The cause of this issue is that si470x_int_in_callback() is called for freed urb. si470x_usb_driver_probe() calls si470x_start_usb(), which then calls usb_submit_urb() and si470x_start(). If si470x_start_usb() fails, si470x_usb_driver_probe() doesn't kill urb, but it just frees struct si470x_device object, as depicted below: si470x_usb_driver_probe() ... si470x_start_usb() ... usb_submit_urb() retval = si470x_start() return retval if (retval < 0) free struct si470x_device object, but don't kill urb This patch fixes this issue by killing urb when si470x_start_usb() fails and urb is submitted. If si470x_start_usb() fails and urb is not submitted, i.e. submitting usb fails, it just frees struct si470x_device object.
- https://git.kernel.org/stable/c/0ca298d548461d29615f9a2b1309e8dcf4a352c6
- https://git.kernel.org/stable/c/146bd005ebb01ae190c22af050cb98623958c373
- https://git.kernel.org/stable/c/1c6447d0fc68650e51586dde79b5090d9d77f13a
- https://git.kernel.org/stable/c/52f54fe78cca24850a30865037250f63eb3d5bf7
- https://git.kernel.org/stable/c/63648a7bd1a7599bcc2040a6d1792363ae4c2e1b
- https://git.kernel.org/stable/c/6c8aee0c8fcc6dda94315f7908e8fa9bc75abe75
- https://git.kernel.org/stable/c/7d21e0b1b41b21d628bf2afce777727bd4479aa5
- https://git.kernel.org/stable/c/8c6151b8e8dd2d98ad2cd725d26d1e103d989891
- https://git.kernel.org/stable/c/92b0888398e4ba51d93b618a6506781f4e3879c9
Modified: 2026-02-26
CVE-2022-50545
In the Linux kernel, the following vulnerability has been resolved:
r6040: Fix kmemleak in probe and remove
There is a memory leaks reported by kmemleak:
unreferenced object 0xffff888116111000 (size 2048):
comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)
hex dump (first 32 bytes):
00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................
08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d
- https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269
- https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44
- https://git.kernel.org/stable/c/7e43039a49c2da45edc1d9d7c9ede4003ab45a5f
- https://git.kernel.org/stable/c/9b5b50329e2e966831a7237dd6949e7b5362a49a
- https://git.kernel.org/stable/c/a04707f4596952049da05756c27398c34d9a1d36
- https://git.kernel.org/stable/c/ad2c8f25457ca9a81e7e958148cbc26600ce3071
- https://git.kernel.org/stable/c/b0a61359026b57a287a48fbb4ba1d097023eca3e
- https://git.kernel.org/stable/c/b4448816e6a565e08236a6009c6bf48c6836cdfd
Modified: 2026-02-26
CVE-2022-50547
In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: fix possible memory leak in solo_sysfs_init() If device_register() returns error in solo_sysfs_init(), 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().
- https://git.kernel.org/stable/c/49060c0da57a381563e482e331dc9d4c3725b41b
- https://git.kernel.org/stable/c/7b02c50d3978840781808e13bc13137fb81286b5
- https://git.kernel.org/stable/c/7cf71bbe5d2ee12613f6e278888f5fc9c5c0cc2b
- https://git.kernel.org/stable/c/7f5866dd96d95b74e439f6ee17b8abd8195179fb
- https://git.kernel.org/stable/c/83d4b1ae98a47a739fa5241300b86eb1110d5d63
- https://git.kernel.org/stable/c/9416861170ba0da8ddb0f4fd2d28334f0ed3b9c2
- https://git.kernel.org/stable/c/963729538674be4cb8fa292529ecf32de0d6c6dd
- https://git.kernel.org/stable/c/b61509093e1af69e336a094d439b8e1137cb40d8
- https://git.kernel.org/stable/c/d6db105bcfbdbbbd484e788a0ddf8140a4a8c486
Modified: 2026-02-26
CVE-2022-50549
In the Linux kernel, the following vulnerability has been resolved: dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata Following concurrent processes: P1(drop cache) P2(kworker) drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_read_bh_nowait submit_bh dm_submit_bio do_worker process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata down_write(&pmd->root_lock) - LOCK B __destroy_persistent_data_objects dm_block_manager_destroy dm_bufio_client_destroy unregister_shrinker down_write(&shrinker_rwsem) thin_map | dm_thin_find_block ↓ down_read(&pmd->root_lock) --> ABBA deadlock , which triggers hung task: [ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds. [ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2 [ 76.978534] Workqueue: dm-thin do_worker [ 76.978552] Call Trace: [ 76.978564] __schedule+0x6ba/0x10f0 [ 76.978582] schedule+0x9d/0x1e0 [ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0 [ 76.978600] down_write+0xec/0x110 [ 76.978607] unregister_shrinker+0x2c/0xf0 [ 76.978616] dm_bufio_client_destroy+0x116/0x3d0 [ 76.978625] dm_block_manager_destroy+0x19/0x40 [ 76.978629] __destroy_persistent_data_objects+0x5e/0x70 [ 76.978636] dm_pool_abort_metadata+0x8e/0x100 [ 76.978643] metadata_operation_failed+0x86/0x110 [ 76.978649] commit+0x6a/0x230 [ 76.978655] do_worker+0xc6e/0xd90 [ 76.978702] process_one_work+0x269/0x630 [ 76.978714] worker_thread+0x266/0x630 [ 76.978730] kthread+0x151/0x1b0 [ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds. [ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459 [ 76.982128] Call Trace: [ 76.982139] __schedule+0x6ba/0x10f0 [ 76.982155] schedule+0x9d/0x1e0 [ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910 [ 76.982173] down_read+0x84/0x170 [ 76.982177] dm_thin_find_block+0x4c/0xd0 [ 76.982183] thin_map+0x201/0x3d0 [ 76.982188] __map_bio+0x5b/0x350 [ 76.982195] dm_submit_bio+0x2b6/0x930 [ 76.982202] __submit_bio+0x123/0x2d0 [ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0 [ 76.982222] submit_bio_noacct+0x389/0x770 [ 76.982227] submit_bio+0x50/0xc0 [ 76.982232] submit_bh_wbc+0x15e/0x230 [ 76.982238] submit_bh+0x14/0x20 [ 76.982241] ext4_read_bh_nowait+0xc5/0x130 [ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60 [ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0 [ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0 [ 76.982263] ext4_discard_preallocations+0x45d/0x830 [ 76.982274] ext4_clear_inode+0x48/0xf0 [ 76.982280] ext4_evict_inode+0xcf/0xc70 [ 76.982285] evict+0x119/0x2b0 [ 76.982290] dispose_list+0x43/0xa0 [ 76.982294] prune_icache_sb+0x64/0x90 [ 76.982298] super_cache_scan+0x155/0x210 [ 76.982303] do_shrink_slab+0x19e/0x4e0 [ 76.982310] shrink_slab+0x2bd/0x450 [ 76.982317] drop_slab+0xcc/0x1a0 [ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0 [ 76.982327] proc_sys_call_handler+0x1bc/0x300 [ 76.982331] proc_sys_write+0x17/0x20 [ 76.982334] vfs_write+0x3d3/0x570 [ 76.982342] ksys_write+0x73/0x160 [ 76.982347] __x64_sys_write+0x1e/0x30 [ 76.982352] do_syscall_64+0x35/0x80 [ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcd Funct ---truncated---
- https://git.kernel.org/stable/c/200aa33b5d781e7c0fa6c0c7db9dbcc3f574ce8f
- https://git.kernel.org/stable/c/2d891cc5a1706b6908bceb56af7176a463ee6d62
- https://git.kernel.org/stable/c/7e37578069737b04955c71dd85db8a3bc2709eff
- https://git.kernel.org/stable/c/8111964f1b8524c4bb56b02cd9c7a37725ea21fd
- https://git.kernel.org/stable/c/cdf7a39bcc427febbfe3c3b9fe829825ead96c27
- https://git.kernel.org/stable/c/f8c26c33fef588ee54852cffa7cbb9f9d9869405
Modified: 2026-02-26
CVE-2022-50551
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request() This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITS_PER_TYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example. Found by a modified version of syzkaller. UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? pr ---truncated---
- https://git.kernel.org/stable/c/0b12d2aa264bac35bff9b5399bb162262b2b8949
- https://git.kernel.org/stable/c/1db036d13e10809943c2dce553e2fa7fc9c6cd80
- https://git.kernel.org/stable/c/4c8fc44c44b97854623c56363c359f711fc0b887
- https://git.kernel.org/stable/c/579c9b9838e8a73f6e93ddece07972c241514dcc
- https://git.kernel.org/stable/c/5b06a8a25eba07628313aa3c5496522eff97be53
- https://git.kernel.org/stable/c/81d17f6f3331f03c8eafdacea68ab773426c1e3c
- https://git.kernel.org/stable/c/87792567d9ed93fd336d2c3b8d7870f44e141e6d
- https://git.kernel.org/stable/c/9d2f70fa2c7cc6c73a420ff15682454782d3d6f6
- https://git.kernel.org/stable/c/bc45aa1911bf699b9905f12414e3c1879d6b784f
- https://git.kernel.org/stable/c/ffb589963df103caaf062081a32db0b9e1798660
Modified: 2026-02-04
CVE-2022-50553
In the Linux kernel, the following vulnerability has been resolved:
tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
When generate a synthetic event with many params and then create a trace
action for it [1], kernel panic happened [2].
It is because that in trace_action_create() 'data->n_params' is up to
SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'
keeps indices into array 'hist_data->var_refs' for each synthetic event
param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX
(current value is 16), so out-of-bound write happened when 'data->n_params'
more than 16. In this case, 'data->match_data.event' is overwritten and
eventually cause the panic.
To solve the issue, adjust the length of 'data->var_ref_idx' to be
SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.
[1]
# cd /sys/kernel/tracing/
# echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\
int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\
int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\
int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\
int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\
int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\
int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\
int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\
int v63" >> synthetic_events
# echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"' >> \
events/sched/sched_waking/trigger
# echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\
pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
pid,pid,pid,pid,pid,pid,pid,pid,pid)" >> events/sched/sched_switch/trigger
[2]
BUG: unable to handle page fault for address: ffff91c900000000
PGD 61001067 P4D 61001067 PUD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:strcmp+0xc/0x30
Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee
c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14
07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3
RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000
RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000
RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000
R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580
R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538
FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0
Call Trace:
- https://git.kernel.org/stable/c/04241956ce8825ff06e06e4083e7b692e9d5f712
- https://git.kernel.org/stable/c/0cb31bd88361edb96cfc622648717ba348f0f4dc
- https://git.kernel.org/stable/c/15697f653399253f9be4ed2a1e03d795f3cfee94
- https://git.kernel.org/stable/c/82470f7d9044842618c847a7166de2b7458157a7
- https://git.kernel.org/stable/c/b4efdc219fb8cfa066c7042e636ab8ad6d7e7494
- https://git.kernel.org/stable/c/cf79d5410a569dad1d4112b5c3c02383cca8213a
Modified: 2025-02-13
CVE-2023-0045
The current implementation of the prctl syscall does not issue an IBPB immediately during the syscall. The ib_prctl_set function updates the Thread Information Flags (TIFs) for the task and updates the SPEC_CTRL MSR on the function __speculation_ctrl_update, but the IBPB is only issued on the next schedule, when the TIF bits are checked. This leaves the victim vulnerable to values already injected on the BTB, prior to the prctl syscall. The patch that added the support for the conditional mitigation via prctl (ib_prctl_set) dates back to the kernel 4.9.176. We recommend upgrading past commit a664ec9158eeddd75121d39c9a0758016097fa96
- https://git.kernel.org/tip/a664ec9158eeddd75121d39c9a0758016097fa96
- https://github.com/google/security-research/security/advisories/GHSA-9x5g-vmxf-4qj8
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230714-0001/
- https://git.kernel.org/tip/a664ec9158eeddd75121d39c9a0758016097fa96
- https://github.com/google/security-research/security/advisories/GHSA-9x5g-vmxf-4qj8
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230714-0001/
Modified: 2024-11-21
CVE-2023-0179
A buffer overflow vulnerability was found in the Netfilter subsystem in the Linux Kernel. This issue could allow the leakage of both stack and heap addresses, and potentially allow Local Privilege Escalation to the root user via arbitrary code execution.
- http://packetstormsecurity.com/files/171601/Kernel-Live-Patch-Security-Notice-LNS-0093-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2161713
- https://seclists.org/oss-sec/2023/q1/20
- https://security.netapp.com/advisory/ntap-20230511-0003/
- http://packetstormsecurity.com/files/171601/Kernel-Live-Patch-Security-Notice-LNS-0093-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2161713
- https://seclists.org/oss-sec/2023/q1/20
- https://security.netapp.com/advisory/ntap-20230511-0003/
Modified: 2025-10-24
CVE-2023-0266
A use after free vulnerability exists in the ALSA PCM package in the Linux Kernel. SNDRV_CTL_IOCTL_ELEM_{READ|WRITE}32 is missing locks that can be used in a use-after-free that can result in a priviledge escalation to gain ring0 access from the system user. We recommend upgrading past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/alsa-pcm-move-rwsem-lock-inside-snd_ctl_elem_read-to-prevent-uaf.patch?id=72783cf35e6c55bca84c4bb7b776c58152856fd4
- https://github.com/torvalds/linux/commit/56b88b50565cd8b946a2d00b0c83927b7ebb055e
- https://github.com/torvalds/linux/commit/becf9e5d553c2389d857a3c178ce80fdb34a02e1
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/alsa-pcm-move-rwsem-lock-inside-snd_ctl_elem_read-to-prevent-uaf.patch?id=72783cf35e6c55bca84c4bb7b776c58152856fd4
- https://github.com/torvalds/linux/commit/56b88b50565cd8b946a2d00b0c83927b7ebb055e
- https://github.com/torvalds/linux/commit/becf9e5d553c2389d857a3c178ce80fdb34a02e1
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-0266
Modified: 2024-11-21
CVE-2023-0459
Copy_from_user on 64-bit versions of the Linux kernel does not implement the __uaccess_begin_nospec allowing a user to bypass the "access_ok" check and pass a kernel pointer to copy_from_user(). This would allow an attacker to leak information. We recommend upgrading beyond commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47
- https://github.com/torvalds/linux/commit/4b842e4e25b12951fa10dedb4bc16bc47e3b850c
- https://github.com/torvalds/linux/commit/74e19ef0ff8061ef55957c3abd71614ef0f42f47
- https://github.com/torvalds/linux/commit/4b842e4e25b12951fa10dedb4bc16bc47e3b850c
- https://github.com/torvalds/linux/commit/74e19ef0ff8061ef55957c3abd71614ef0f42f47
Modified: 2024-11-21
CVE-2023-0461
There is a use-after-free vulnerability in the Linux Kernel which can be exploited to achieve local privilege escalation. To reach the vulnerability kernel configuration flag CONFIG_TLS or CONFIG_XFRM_ESPINTCP has to be configured, but the operation does not require any privilege. There is a use-after-free bug of icsk_ulp_data of a struct inet_connection_sock. When CONFIG_TLS is enabled, user can install a tls context (struct tls_context) on a connected tcp socket. The context is not cleared if this socket is disconnected and reused as a listener. If a new socket is created from the listener, the context is inherited and vulnerable. The setsockopt TCP_ULP operation does not require any privilege. We recommend upgrading past commit 2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://kernel.dance/#2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://kernel.dance/#2c02d41d71f90a5168391b6a5f2954112ba2307c
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230331-0006/
Modified: 2025-05-05
CVE-2023-1078
A flaw was found in the Linux Kernel in RDS (Reliable Datagram Sockets) protocol. The rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Local user can trigger this with rds_message_put(). Type confusion leads to `struct rds_msg_zcopy_info *info` actually points to something else that is potentially controlled by local user. It is known how to trigger this, which causes an out of bounds access, and a lock corruption.
- http://www.openwall.com/lists/oss-security/2023/11/05/1
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f753a68980cf4b59a80fe677619da2b1804f526d
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230505-0004/
- http://www.openwall.com/lists/oss-security/2023/11/05/1
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f753a68980cf4b59a80fe677619da2b1804f526d
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230505-0004/
Modified: 2025-02-13
CVE-2023-1281
Use After Free vulnerability in Linux kernel traffic control index filter (tcindex) allows Privilege Escalation. The imperfect hash area can be updated while packets are traversing, which will cause a use-after-free when 'tcf_exts_exec()' is called with the destroyed tcf_ext. A local attacker user can use this vulnerability to elevate its privileges to root. This issue affects Linux Kernel: from 4.14 before git commit ee059170b1f7e94e55fa6cadee544e176a6e59c2.
- http://www.openwall.com/lists/oss-security/2023/04/11/3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee059170b1f7e94e55fa6cadee544e176a6e59c2
- https://kernel.dance/#ee059170b1f7e94e55fa6cadee544e176a6e59c2
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230427-0004/
- http://www.openwall.com/lists/oss-security/2023/04/11/3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee059170b1f7e94e55fa6cadee544e176a6e59c2
- https://kernel.dance/#ee059170b1f7e94e55fa6cadee544e176a6e59c2
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230427-0004/
Modified: 2024-11-21
CVE-2023-1295
A time-of-check to time-of-use issue exists in io_uring subsystem's IORING_OP_CLOSE operation in the Linux kernel's versions 5.6 - 5.11 (inclusive), which allows a local user to elevate their privileges to root. Introduced in b5dba59e0cf7e2cc4d3b3b1ac5fe81ddf21959eb, patched in 9eac1904d3364254d622bf2c771c4f85cd435fc2, backported to stable in 788d0824269bef539fe31a785b1517882eafed93.
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=788d0824269bef539fe31a785b1517882eafed93
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9eac1904d3364254d622bf2c771c4f85cd435fc2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5dba59e0cf7e2cc4d3b3b1ac5fe81ddf21959eb
- https://kernel.dance/788d0824269bef539fe31a785b1517882eafed93
- https://kernel.dance/9eac1904d3364254d622bf2c771c4f85cd435fc2
- https://security.netapp.com/advisory/ntap-20230731-0006/
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=788d0824269bef539fe31a785b1517882eafed93
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9eac1904d3364254d622bf2c771c4f85cd435fc2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5dba59e0cf7e2cc4d3b3b1ac5fe81ddf21959eb
- https://kernel.dance/788d0824269bef539fe31a785b1517882eafed93
- https://kernel.dance/9eac1904d3364254d622bf2c771c4f85cd435fc2
- https://security.netapp.com/advisory/ntap-20230731-0006/
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-05-05
CVE-2023-23559
In rndis_query_oid in drivers/net/wireless/rndis_wlan.c in the Linux kernel through 6.1.5, there is an integer overflow in an addition.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b870e73a56c4cccbec33224233eaf295839f228c
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://patchwork.kernel.org/project/linux-wireless/patch/20230110173007.57110-1-szymon.heidrich%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230302-0003/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b870e73a56c4cccbec33224233eaf295839f228c
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://patchwork.kernel.org/project/linux-wireless/patch/20230110173007.57110-1-szymon.heidrich%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230302-0003/
Modified: 2024-11-21
CVE-2023-23586
Due to a vulnerability in the io_uring subsystem, it is possible to leak kernel memory information to the user process. timens_install calls current_is_single_threaded to determine if the current process is single-threaded, but this call does not consider io_uring's io_worker threads, thus it is possible to insert a time namespace's vvar page to process's memory space via a page fault. When this time namespace is destroyed, the vvar page is also freed, but not removed from the process' memory, and a next page allocated by the kernel will be still available from the user-space process and can leak memory contents via this (read-only) use-after-free vulnerability. We recommend upgrading past version 5.10.161 or commit 788d0824269bef539fe31a785b1517882eafed93 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/io_uring
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/io_uring?h=linux-5.10.y&id=788d0824269bef539fe31a785b1517882eafed93
- https://kernel.dance/#788d0824269bef539fe31a785b1517882eafed93
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/io_uring?h=linux-5.10.y&id=788d0824269bef539fe31a785b1517882eafed93
- https://kernel.dance/#788d0824269bef539fe31a785b1517882eafed93
Modified: 2025-01-27
CVE-2023-52646
In the Linux kernel, the following vulnerability has been resolved: aio: fix mremap after fork null-deref Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced a null-deref if mremap is called on an old aio mapping after fork as mm->ioctx_table will be set to NULL. [jmoyer@redhat.com: fix 80 column issue]
- https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1
- https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2
- https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95
- https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e29970e834d1
- https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d
- https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f
- https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22
- https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1
- https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2
- https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95
- https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e29970e834d1
- https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d
- https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f
- https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22
Modified: 2024-12-31
CVE-2023-52702
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible memory leak in ovs_meter_cmd_set() old_meter needs to be free after it is detached regardless of whether the new meter is successfully attached.
- https://git.kernel.org/stable/c/1563e998a938f095548054ef09e277b562b79536
- https://git.kernel.org/stable/c/2fa28f5c6fcbfc794340684f36d2581b4f2d20b5
- https://git.kernel.org/stable/c/c0f65ee0a3329eb4b94beaef0268633696e2d0c6
- https://git.kernel.org/stable/c/e336a9e08618203a456fb5367f1387b14554f55e
- https://git.kernel.org/stable/c/1563e998a938f095548054ef09e277b562b79536
- https://git.kernel.org/stable/c/2fa28f5c6fcbfc794340684f36d2581b4f2d20b5
- https://git.kernel.org/stable/c/c0f65ee0a3329eb4b94beaef0268633696e2d0c6
- https://git.kernel.org/stable/c/e336a9e08618203a456fb5367f1387b14554f55e
Modified: 2025-09-23
CVE-2023-52703
In the Linux kernel, the following vulnerability has been resolved: net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1] With this in mind, let's just not pass act_len to the usb_bulk_msg error paths. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/
- https://git.kernel.org/stable/c/02df3170c04a8356cd571ab9155a42f030190abc
- https://git.kernel.org/stable/c/1b5de7d44890b78519acbcc80d8d1f23ff2872e5
- https://git.kernel.org/stable/c/338f826d3afead6e4df521f7972a4bef04a72efb
- https://git.kernel.org/stable/c/525bdcb0838d19d918c7786151ee14661967a030
- https://git.kernel.org/stable/c/723ef7b66f37c0841f5a451ccbce47ee1641e081
- https://git.kernel.org/stable/c/a753352622b4f3c0219e0e9c73114b2848ae6042
- https://git.kernel.org/stable/c/c68f345b7c425b38656e1791a0486769a8797016
- https://git.kernel.org/stable/c/02df3170c04a8356cd571ab9155a42f030190abc
- https://git.kernel.org/stable/c/1b5de7d44890b78519acbcc80d8d1f23ff2872e5
- https://git.kernel.org/stable/c/338f826d3afead6e4df521f7972a4bef04a72efb
- https://git.kernel.org/stable/c/525bdcb0838d19d918c7786151ee14661967a030
- https://git.kernel.org/stable/c/723ef7b66f37c0841f5a451ccbce47ee1641e081
- https://git.kernel.org/stable/c/a753352622b4f3c0219e0e9c73114b2848ae6042
- https://git.kernel.org/stable/c/c68f345b7c425b38656e1791a0486769a8797016
Modified: 2024-12-31
CVE-2023-52705
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix underflow in second superblock position calculations
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second
superblock, underflows when the argument device size is less than 4096
bytes. Therefore, when using this macro, it is necessary to check in
advance that the device size is not less than a lower limit, or at least
that underflow does not occur.
The current nilfs2 implementation lacks this check, causing out-of-bound
block access when mounting devices smaller than 4096 bytes:
I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
phys_seg 1 prio class 2
NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
In addition, when trying to resize the filesystem to a size below 4096
bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number
of segments to nilfs_sufile_resize(), corrupting parameters such as the
number of segments in superblocks. This causes excessive loop iterations
in nilfs_sufile_resize() during a subsequent resize ioctl, causing
semaphore ns_segctor_sem to block for a long time and hang the writer
thread:
INFO: task segctord:5067 blocked for more than 143 seconds.
Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:segctord state:D stack:23456 pid:5067 ppid:2
flags:0x00004000
Call Trace:
- https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5
- https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b
- https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f
- https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d
- https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205
- https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4
- https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff
- https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5
- https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b
- https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f
- https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d
- https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205
- https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4
- https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff
Modified: 2025-01-06
CVE-2023-52707
In the Linux kernel, the following vulnerability has been resolved:
sched/psi: Fix use-after-free in ep_remove_wait_queue()
If a non-root cgroup gets removed when there is a thread that registered
trigger and is polling on a pressure file within the cgroup, the polling
waitqueue gets freed in the following path:
do_rmdir
cgroup_rmdir
kernfs_drain_open_files
cgroup_file_release
cgroup_pressure_release
psi_trigger_destroy
However, the polling thread still has a reference to the pressure file and
will access the freed waitqueue when the file is closed or upon exit:
fput
ep_eventpoll_release
ep_free
ep_remove_wait_queue
remove_wait_queue
This results in use-after-free as pasted below.
The fundamental problem here is that cgroup_file_release() (and
consequently waitqueue's lifetime) is not tied to the file's real lifetime.
Using wake_up_pollfree() here might be less than ideal, but it is in line
with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()")
since the waitqueue's lifetime is not tied to file's one and can be
considered as another special case. While this would be fixable by somehow
making cgroup_file_release() be tied to the fput(), it would require
sizable refactoring at cgroups or higher layer which might be more
justifiable if we identify more cases like this.
BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0
Write of size 4 at addr ffff88810e625328 by task a.out/4404
CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
Call Trace:
- https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38
- https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe
- https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a
- https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a
- https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5
- https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38
- https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe
- https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a
- https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a
- https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5
Modified: 2025-01-06
CVE-2023-52708
In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_spi: fix error handling in mmc_spi_probe() If mmc_add_host() fails, it doesn't need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host(). To fix this, goto label 'fail_glue_init', if mmc_add_host() fails, and change the label 'fail_add_host' to 'fail_gpiod_request'.
- https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be
- https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f
- https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714
- https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd
- https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3
- https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be
- https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f
- https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714
- https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd
- https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3
Modified: 2025-09-23
CVE-2023-52730
In the Linux kernel, the following vulnerability has been resolved: mmc: sdio: fix possible resource leaks in some error paths If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device(). To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device(). In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced. Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone. unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
- https://git.kernel.org/stable/c/1e06cf04239e202248c8fa356bf11449dc73cfbd
- https://git.kernel.org/stable/c/30716d9f0fa1766e522cf24c8a456244e4fc9931
- https://git.kernel.org/stable/c/5c7858adada31dbed042448cff6997dd6efc472a
- https://git.kernel.org/stable/c/605d9fb9556f8f5fb4566f4df1480f280f308ded
- https://git.kernel.org/stable/c/761db46b29b496946046d8cb33c7ea6de6bef36e
- https://git.kernel.org/stable/c/92ff03c2563c9b57a027c744750f3b7d2f261c58
- https://git.kernel.org/stable/c/f855d31bb38d663c3ba672345d7cce9324ba3b72
- https://git.kernel.org/stable/c/1e06cf04239e202248c8fa356bf11449dc73cfbd
- https://git.kernel.org/stable/c/30716d9f0fa1766e522cf24c8a456244e4fc9931
- https://git.kernel.org/stable/c/5c7858adada31dbed042448cff6997dd6efc472a
- https://git.kernel.org/stable/c/605d9fb9556f8f5fb4566f4df1480f280f308ded
- https://git.kernel.org/stable/c/761db46b29b496946046d8cb33c7ea6de6bef36e
- https://git.kernel.org/stable/c/92ff03c2563c9b57a027c744750f3b7d2f261c58
- https://git.kernel.org/stable/c/f855d31bb38d663c3ba672345d7cce9324ba3b72
Modified: 2025-09-23
CVE-2023-52736
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Do not unset preset when cleaning up codec Several functions that take part in codec's initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component->probe/remove() instead. One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences. As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting ->preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver's module reloading may occur several times throughout the lifetime of an audio stack.
- https://git.kernel.org/stable/c/427ca2530da8dc61a42620d7113b05e187b6c2c0
- https://git.kernel.org/stable/c/7fc4e7191eae9d9325511e03deadfdb2224914f8
- https://git.kernel.org/stable/c/87978e6ad45a16835cc58234451111091be3c59a
- https://git.kernel.org/stable/c/e909f5f2aa55a8f9aa6919cce08015cb0e8d4668
- https://git.kernel.org/stable/c/427ca2530da8dc61a42620d7113b05e187b6c2c0
- https://git.kernel.org/stable/c/7fc4e7191eae9d9325511e03deadfdb2224914f8
- https://git.kernel.org/stable/c/87978e6ad45a16835cc58234451111091be3c59a
- https://git.kernel.org/stable/c/e909f5f2aa55a8f9aa6919cce08015cb0e8d4668
Modified: 2025-09-23
CVE-2023-52739
In the Linux kernel, the following vulnerability has been resolved: Fix page corruption caused by racy check in __free_pages When we upgraded our kernel, we started seeing some page corruption like the following consistently: BUG: Bad page state in process ganesha.nfsd pfn:1304ca page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca flags: 0x17ffffc0000000() raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000 raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 Call Trace: dump_stack+0x74/0x96 bad_page.cold+0x63/0x94 check_new_page_bad+0x6d/0x80 rmqueue+0x46e/0x970 get_page_from_freelist+0xcb/0x3f0 ? _cond_resched+0x19/0x40 __alloc_pages_nodemask+0x164/0x300 alloc_pages_current+0x87/0xf0 skb_page_frag_refill+0x84/0x110 ... Sometimes, it would also show up as corruption in the free list pointer and cause crashes. After bisecting the issue, we found the issue started from commit e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"): if (put_page_testzero(page)) free_the_page(page, order); else if (!PageHead(page)) while (order-- > 0) free_the_page(page + (1 << order), order); So the problem is the check PageHead is racy because at this point we already dropped our reference to the page. So even if we came in with compound page, the page can already be freed and PageHead can return false and we will end up freeing all the tail pages causing double free.
- https://git.kernel.org/stable/c/0a626e27f984dfbe96bd8e4fd08f20a2ede3ea23
- https://git.kernel.org/stable/c/3af734f3eac6f70ef8e272a80da40544b9d0f2b5
- https://git.kernel.org/stable/c/3b4c045a98f53a8890a94bb5846a390c8e39e673
- https://git.kernel.org/stable/c/462a8e08e0e6287e5ce13187257edbf24213ed03
- https://git.kernel.org/stable/c/0a626e27f984dfbe96bd8e4fd08f20a2ede3ea23
- https://git.kernel.org/stable/c/3af734f3eac6f70ef8e272a80da40544b9d0f2b5
- https://git.kernel.org/stable/c/3b4c045a98f53a8890a94bb5846a390c8e39e673
- https://git.kernel.org/stable/c/462a8e08e0e6287e5ce13187257edbf24213ed03
Modified: 2025-01-06
CVE-2023-52741
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix use-after-free in rdata->read_into_pages()
When the network status is unstable, use-after-free may occur when
read data from the server.
BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0
Call Trace:
- https://git.kernel.org/stable/c/2b693fe3f760c87fd9768e759f6297f743a1b3b0
- https://git.kernel.org/stable/c/3684a2f6affa1ca52a5d4a12f04d0652efdee65e
- https://git.kernel.org/stable/c/aa5465aeca3c66fecdf7efcf554aed79b4c4b211
- https://git.kernel.org/stable/c/d1fba1e096ffc7ec11df863a97c50203c47315b9
- https://git.kernel.org/stable/c/2b693fe3f760c87fd9768e759f6297f743a1b3b0
- https://git.kernel.org/stable/c/3684a2f6affa1ca52a5d4a12f04d0652efdee65e
- https://git.kernel.org/stable/c/aa5465aeca3c66fecdf7efcf554aed79b4c4b211
- https://git.kernel.org/stable/c/d1fba1e096ffc7ec11df863a97c50203c47315b9
Modified: 2025-09-25
CVE-2023-52742
In the Linux kernel, the following vulnerability has been resolved:
net: USB: Fix wrong-direction WARNING in plusb.c
The syzbot fuzzer detected a bug in the plusb network driver: A
zero-length control-OUT transfer was treated as a read instead of a
write. In modern kernels this error provokes a WARNING:
usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411
usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
Modules linked in:
CPU: 1 PID: 4645 Comm: dhcpcd Not tainted
6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/12/2023
RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
...
Call Trace:
- https://git.kernel.org/stable/c/0d2cf3fae701646061e295815bb7588d2f3671cc
- https://git.kernel.org/stable/c/1be271c52bf3554edcb8d124d1f8c7f777ee5727
- https://git.kernel.org/stable/c/25141fb4119112f4ebf8f00cf52014abbc8020b1
- https://git.kernel.org/stable/c/43379fcacea2dcee35d02efc9c8fe97807a503c9
- https://git.kernel.org/stable/c/6f69307f625904feed189008381fd83bd1a35b63
- https://git.kernel.org/stable/c/811d581194f7412eda97acc03d17fc77824b561f
- https://git.kernel.org/stable/c/f0ad46ef772438c0596df370450d8bdc8a12dbfb
- https://git.kernel.org/stable/c/0d2cf3fae701646061e295815bb7588d2f3671cc
- https://git.kernel.org/stable/c/1be271c52bf3554edcb8d124d1f8c7f777ee5727
- https://git.kernel.org/stable/c/25141fb4119112f4ebf8f00cf52014abbc8020b1
- https://git.kernel.org/stable/c/43379fcacea2dcee35d02efc9c8fe97807a503c9
- https://git.kernel.org/stable/c/6f69307f625904feed189008381fd83bd1a35b63
- https://git.kernel.org/stable/c/811d581194f7412eda97acc03d17fc77824b561f
- https://git.kernel.org/stable/c/f0ad46ef772438c0596df370450d8bdc8a12dbfb
Modified: 2025-09-25
CVE-2023-52743
In the Linux kernel, the following vulnerability has been resolved:
ice: Do not use WQ_MEM_RECLAIM flag for workqueue
When both ice and the irdma driver are loaded, a warning in
check_flush_dependency is being triggered. This is due to ice driver
workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one
is not.
According to kernel documentation, this flag should be set if the
workqueue will be involved in the kernel's memory reclamation flow.
Since it is not, there is no need for the ice driver's WQ to have this
flag set so remove it.
Example trace:
[ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
[ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
[ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
[ +0.000161] [last unloaded: bonding]
[ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
[ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[ +0.000003] Workqueue: ice ice_service_task [ice]
[ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
[ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
[ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
[ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
[ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
[ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
[ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
[ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
[ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
[ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
[ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ +0.000002] PKRU: 55555554
[ +0.000003] Call Trace:
[ +0.000002]
- https://git.kernel.org/stable/c/1ad4112c9fcf0bc08222b2b1614fba52ffd12255
- https://git.kernel.org/stable/c/4d159f7884f78b1aacb99b4fc37d1e3cb1194e39
- https://git.kernel.org/stable/c/87a5e3fc8416106e290c448fc8a6dd50ab24c634
- https://git.kernel.org/stable/c/ca834a017851c50464c25a85f3cb2daefff7bede
- https://git.kernel.org/stable/c/df59e05401450973c8c7e96fd74b49e24442dc1f
- https://git.kernel.org/stable/c/1ad4112c9fcf0bc08222b2b1614fba52ffd12255
- https://git.kernel.org/stable/c/4d159f7884f78b1aacb99b4fc37d1e3cb1194e39
- https://git.kernel.org/stable/c/87a5e3fc8416106e290c448fc8a6dd50ab24c634
- https://git.kernel.org/stable/c/ca834a017851c50464c25a85f3cb2daefff7bede
- https://git.kernel.org/stable/c/df59e05401450973c8c7e96fd74b49e24442dc1f
Modified: 2025-04-02
CVE-2023-52746
In the Linux kernel, the following vulnerability has been resolved: xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() int type = nla_type(nla); if (type > XFRMA_MAX) { return -EOPNOTSUPP; } @type is then used as an array index and can be used as a Spectre v1 gadget. if (nla_len(nla) < compat_policy[type].len) { array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users.
- https://git.kernel.org/stable/c/419674224390fca298020fc0751a20812f84b12d
- https://git.kernel.org/stable/c/5dc688fae6b7be9dbbf5304a3d2520d038e06db5
- https://git.kernel.org/stable/c/a893cc644812728e86e9aff517fd5698812ecef0
- https://git.kernel.org/stable/c/b6ee896385380aa621102e8ea402ba12db1cabff
- https://git.kernel.org/stable/c/419674224390fca298020fc0751a20812f84b12d
- https://git.kernel.org/stable/c/5dc688fae6b7be9dbbf5304a3d2520d038e06db5
- https://git.kernel.org/stable/c/a893cc644812728e86e9aff517fd5698812ecef0
- https://git.kernel.org/stable/c/b6ee896385380aa621102e8ea402ba12db1cabff
Modified: 2025-09-23
CVE-2023-52747
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Restore allocated resources on failed copyout Fix a resource leak if an error occurs.
- https://git.kernel.org/stable/c/00d9e212b8a39e6ffcf31b9d2e503d2bf6009d45
- https://git.kernel.org/stable/c/0a4f811f2e5d07bbd0c9226f4afb0a1270a831ae
- https://git.kernel.org/stable/c/6601fc0d15ffc20654e39486f9bef35567106d68
- https://git.kernel.org/stable/c/7896accedf5bf1277d2f305718e36dc8bac7e321
- https://git.kernel.org/stable/c/79b595d9591426156a9e0635a5b5115508a36fef
- https://git.kernel.org/stable/c/9bae58d58b6bb73b572356b31a62d2afc7378d12
- https://git.kernel.org/stable/c/00d9e212b8a39e6ffcf31b9d2e503d2bf6009d45
- https://git.kernel.org/stable/c/0a4f811f2e5d07bbd0c9226f4afb0a1270a831ae
- https://git.kernel.org/stable/c/6601fc0d15ffc20654e39486f9bef35567106d68
- https://git.kernel.org/stable/c/7896accedf5bf1277d2f305718e36dc8bac7e321
- https://git.kernel.org/stable/c/79b595d9591426156a9e0635a5b5115508a36fef
- https://git.kernel.org/stable/c/9bae58d58b6bb73b572356b31a62d2afc7378d12
Modified: 2024-09-11
CVE-2023-52893
In the Linux kernel, the following vulnerability has been resolved: gsmi: fix null-deref in gsmi_get_variable We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.
- https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a
- https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393
- https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8
- https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd
- https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2
- https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b
- https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5
Modified: 2024-09-11
CVE-2023-52894
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate() In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device. AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic. AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct) It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing...
- https://git.kernel.org/stable/c/09e4507ec8ef2d44da6ba4092b8ee2d81f216497
- https://git.kernel.org/stable/c/63d161f29cd39c050e8873aa36e0c9fc013bb763
- https://git.kernel.org/stable/c/a21da7f7aae618c785f7e4a275d43c06dc8412b6
- https://git.kernel.org/stable/c/a69c8dfb85b44be9cc223be07d35cc3a9baefbea
- https://git.kernel.org/stable/c/c6ec929595c7443250b2a4faea988c62019d5cd2
- https://git.kernel.org/stable/c/e92c70059178da751e5af7de02384b7dfadb5ec7
- https://git.kernel.org/stable/c/fef6b29671b66dfb71f17e337c1ad14b5a2cedae
Modified: 2024-09-11
CVE-2023-52896
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between quota rescan and disable leading to NULL pointer deref
If we have one task trying to start the quota rescan worker while another
one is trying to disable quotas, we can end up hitting a race that results
in the quota rescan worker doing a NULL pointer dereference. The steps for
this are the following:
1) Quotas are enabled;
2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().
It calls qgroup_rescan_init() which returns 0 (success) and then joins a
transaction and commits it;
3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().
It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls
btrfs_qgroup_wait_for_completion(), which returns immediately since the
rescan worker is not yet running.
Then it starts a transaction and locks fs_info->qgroup_ioctl_lock;
4) Task A queues the rescan worker, by calling btrfs_queue_work();
5) The rescan worker starts, and calls rescan_should_stop() at the start
of its while loop, which results in 0 iterations of the loop, since
the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by
task B at step 3);
6) Task B sets fs_info->quota_root to NULL;
7) The rescan worker tries to start a transaction and uses
fs_info->quota_root as the root argument for btrfs_start_transaction().
This results in a NULL pointer dereference down the call chain of
btrfs_start_transaction(). The stack trace is something like the one
reported in Link tag below:
general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: btrfs-qgroup-rescan btrfs_work_helper
RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564
Code: 48 89 fb 48 (...)
RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206
RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d
R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1004fc90f0d79a4b7d9e3d432729914f472f9ad1
- https://git.kernel.org/stable/c/3bd43374857103ba3cac751d6d4afa8d83b5d92a
- https://git.kernel.org/stable/c/64287cd456a22373053998c1fccf14b651e9cbbd
- https://git.kernel.org/stable/c/89ac597e3e807b91e2ebd6a7c36fec7b97290233
- https://git.kernel.org/stable/c/b7adbf9ada3513d2092362c8eac5cddc5b651f5c
Modified: 2024-09-13
CVE-2023-52898
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix null pointer dereference when host dies Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies. Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id] virt device at the same time that xhci_kill_endpoint_urbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back. hold the xhci spinlock while freeing the virt device
- https://git.kernel.org/stable/c/081105213ff6f661c114781d469233c7d0e09c2e
- https://git.kernel.org/stable/c/133b902378e4acbd824c29dd0d48570ad596e368
- https://git.kernel.org/stable/c/6fac4b5cecb3928a0a81069aaa815a2edc8dd5a1
- https://git.kernel.org/stable/c/a2bc47c43e70cf904b1af49f76d572326c08bca7
- https://git.kernel.org/stable/c/c462ac871f49753eca86bb960f573b993976a5ea
- https://git.kernel.org/stable/c/ea2ee5e9991caf74e0604f994c1831a5867055b2
Modified: 2024-09-13
CVE-2023-52899
In the Linux kernel, the following vulnerability has been resolved: Add exception protection processing for vd in axi_chan_handle_err function Since there is no protection for vd, a kernel panic will be triggered here in exceptional cases. You can refer to the processing of axi_chan_block_xfer_complete function The triggered kernel panic is as follows: [ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 67.848447] Mem abort info: [ 67.848449] ESR = 0x96000004 [ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.848454] SET = 0, FnV = 0 [ 67.848456] EA = 0, S1PTW = 0 [ 67.848458] Data abort info: [ 67.848460] ISV = 0, ISS = 0x00000004 [ 67.848462] CM = 0, WnR = 0 [ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000 [ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 [ 67.848472] Internal error: Oops: 96000004 [#1] SMP [ 67.848475] Modules linked in: dmatest [ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11 [ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--) [ 67.848487] pc : axi_chan_handle_err+0xc4/0x230 [ 67.848491] lr : axi_chan_handle_err+0x30/0x230 [ 67.848493] sp : ffff0803fe55ae50 [ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200 [ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080 [ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850 [ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000 [ 67.848512] x21: 0000000000000080 x20: 0000000000002000 [ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000 [ 67.848521] x17: 0000000000000000 x16: 0000000000000000 [ 67.848525] x15: 0000000000000000 x14: 0000000000000000 [ 67.848529] x13: 0000000000000000 x12: 0000000000000040 [ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a [ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270 [ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0 [ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480 [ 67.848550] x3 : dead000000000100 x2 : dead000000000122 [ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168 [ 67.848559] Call trace: [ 67.848562] axi_chan_handle_err+0xc4/0x230 [ 67.848566] dw_axi_dma_interrupt+0xf4/0x590 [ 67.848569] __handle_irq_event_percpu+0x60/0x220 [ 67.848573] handle_irq_event+0x64/0x120 [ 67.848576] handle_fasteoi_irq+0xc4/0x220 [ 67.848580] __handle_domain_irq+0x80/0xe0 [ 67.848583] gic_handle_irq+0xc0/0x138 [ 67.848585] el1_irq+0xc8/0x180 [ 67.848588] arch_cpu_idle+0x14/0x2c [ 67.848591] default_idle_call+0x40/0x16c [ 67.848594] do_idle+0x1f0/0x250 [ 67.848597] cpu_startup_entry+0x2c/0x60 [ 67.848600] rest_init+0xc0/0xcc [ 67.848603] arch_call_rest_init+0x14/0x1c [ 67.848606] start_kernel+0x4cc/0x500 [ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1) [ 67.848613] ---[ end trace 585a97036f88203a ]---
- https://git.kernel.org/stable/c/20d0a6d17e85a8a816a64fa7d7cae616f1617833
- https://git.kernel.org/stable/c/5054d001ffaf76155637c5e5b922c11016cd6a5d
- https://git.kernel.org/stable/c/51a7ad5b60efac65691729d10745c28fa1016b96
- https://git.kernel.org/stable/c/53dd833fd0a2d8f0118d01ea063a70652689d31e
- https://git.kernel.org/stable/c/57054fe516d59d03a7bcf1888e82479ccc244f87
- https://git.kernel.org/stable/c/f534dc438828cc3f1f8c6895b8bdfbef079521fb
Modified: 2024-09-13
CVE-2023-52900
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
block by calling __nilfs_btree_get_block() against an invalid virtual
block address, it returns -ENOENT because conversion of the virtual block
address to a disk block address fails. However, this return value is the
same as the internal code that b-tree lookup routines return to indicate
that the block being searched does not exist, so functions that operate on
that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from
nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was
successful and continues the insert operation using incomplete lookup path
data, causing the following crash:
general protection fault, probably for non-canonical address
0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
...
RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]
RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]
RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238
Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89
ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c
28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02
...
Call Trace:
- https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04
- https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545
- https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062
- https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243
- https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051
- https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d
- https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749
Modified: 2024-09-13
CVE-2023-52901
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Check endpoint is valid before dereferencing it When the host controller is not responding, all URBs queued to all endpoints need to be killed. This can cause a kernel panic if we dereference an invalid endpoint. Fix this by using xhci_get_virt_ep() helper to find the endpoint and checking if the endpoint is valid before dereferencing it. [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8 [233311.853964] pc : xhci_hc_died+0x10c/0x270 [233311.853971] lr : xhci_hc_died+0x1ac/0x270 [233311.854077] Call trace: [233311.854085] xhci_hc_died+0x10c/0x270 [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4 [233311.854105] call_timer_fn+0x50/0x2d4 [233311.854112] expire_timers+0xac/0x2e4 [233311.854118] run_timer_softirq+0x300/0xabc [233311.854127] __do_softirq+0x148/0x528 [233311.854135] irq_exit+0x194/0x1a8 [233311.854143] __handle_domain_irq+0x164/0x1d0 [233311.854149] gic_handle_irq.22273+0x10c/0x188 [233311.854156] el1_irq+0xfc/0x1a8 [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm] [233311.854185] cpuidle_enter_state+0x1f0/0x764 [233311.854194] do_idle+0x594/0x6ac [233311.854201] cpu_startup_entry+0x7c/0x80 [233311.854209] secondary_start_kernel+0x170/0x198
- https://git.kernel.org/stable/c/08864dc14a6803f0377ca77b9740b26db30c020f
- https://git.kernel.org/stable/c/2d2820d5f375563690c96e60676855205abfb7f5
- https://git.kernel.org/stable/c/375be2dd61a072f7b1cac9b17eea59e07b58db3a
- https://git.kernel.org/stable/c/66fc1600855c05c4ba4e997184c91cf298e0405c
- https://git.kernel.org/stable/c/9891e5c73cab3fd9ed532dc50e9799e55e974766
- https://git.kernel.org/stable/c/e8fb5bc76eb86437ab87002d4a36d6da02165654
- https://git.kernel.org/stable/c/f39c813af0b64f44af94e435c07bfa1ddc2575f5
Modified: 2024-09-13
CVE-2023-52903
In the Linux kernel, the following vulnerability has been resolved: io_uring: lock overflowing for IOPOLL syzbot reports an issue with overflow filling for IOPOLL: WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: events_unbound io_ring_exit_work Call trace: io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773 io_fill_cqe_req io_uring/io_uring.h:168 [inline] io_do_iopoll+0x474/0x62c io_uring/rw.c:1065 io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513 io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056 io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 worker_thread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863 There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which __io_cqring_overflow_flush() happens from the CQ waiting path.
Modified: 2024-09-13
CVE-2023-52906
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mpls: Fix warning during failed attribute validation
The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
combination according to the comment above 'struct nla_policy':
"
Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
NLA_BINARY Validation function called for the attribute.
All other Unused - but note that it's a union
"
This can trigger the warning [1] in nla_get_range_unsigned() when
validation of the attribute fails. Despite being of 'NLA_U32' type, the
associated 'min'/'max' fields in the policy are negative as they are
aliased by the 'validate' field.
Fix by changing the attribute type to 'NLA_BINARY' which is consistent
with the above comment and all other users of NLA_POLICY_VALIDATE_FN().
As a result, move the length validation to the validation function.
No regressions in MPLS tests:
# ./tdc.py -f tc-tests/actions/mpls.json
[...]
# echo $?
0
[1]
WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
Modules linked in:
CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
[...]
Call Trace:
- https://git.kernel.org/stable/c/2b157c3c5d6b8ddca48d53c9e662032f65af8d61
- https://git.kernel.org/stable/c/453277feb41c2235cf2c0de9209eef962c401457
- https://git.kernel.org/stable/c/8a97b544b98e44f596219ebb290fd2ba2fd5d644
- https://git.kernel.org/stable/c/9e17f99220d111ea031b44153fdfe364b0024ff2
- https://git.kernel.org/stable/c/9e2c38827cdc6fdd3bb375c8607fc04d289756f9
Modified: 2024-09-12
CVE-2023-52907
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() Fix a use-after-free that occurs in hcd when in_urb sent from pn533_usb_send_frame() is completed earlier than out_urb. Its callback frees the skb data in pn533_send_async_complete() that is used as a transfer buffer of out_urb. Wait before sending in_urb until the callback of out_urb is called. To modify the callback of out_urb alone, separate the complete function of out_urb and ack_urb. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in dummy_timer Call Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803)
- https://git.kernel.org/stable/c/0ca78c99656f5c448567db1e148367aa3b01c80a
- https://git.kernel.org/stable/c/321db5131c92983dac4f3338e8fbb6df214238c0
- https://git.kernel.org/stable/c/35529d6b827eedb6bf7e81130e4b7e0aba9e58d2
- https://git.kernel.org/stable/c/39ae73e581112cfe27ba50aecb1c891ce57cecb1
- https://git.kernel.org/stable/c/8998db5021a28ad67aa8d627bdb4226e4046ccc4
- https://git.kernel.org/stable/c/9424d2205fe94a095fb9365ec0c6137f0b394a2b
- https://git.kernel.org/stable/c/9dab880d675b9d0dd56c6428e4e8352a3339371d
Modified: 2025-10-01
CVE-2023-52930
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential bit_17 double-free A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock. [tursulin: Correct fixes tag and added cc stable.] (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e)
Modified: 2025-10-01
CVE-2023-52932
In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: add cond_resched() in get_swap_pages() The softlockup still occurs in get_swap_pages() under memory pressure. 64 CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram device is 50MB with same priority as si. Use the stress-ng tool to increase memory pressure, causing the system to oom frequently. The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case: cond_resched() is not called in scan_swap_map_slots()). Let's add cond_resched() into get_swap_pages() when failed to find available space to avoid softlockup.
- https://git.kernel.org/stable/c/29f0349c5c76b627fe06b87d4b13fa03a6ce8e64
- https://git.kernel.org/stable/c/30187be29052bba9203b0ae2bdd815e0bc2faaab
- https://git.kernel.org/stable/c/387217b97e99699c34e6d95ce2b91b327fcd853e
- https://git.kernel.org/stable/c/49178d4d61e78aed8c837dfeea8a450700f196e2
- https://git.kernel.org/stable/c/5dbe1ebd56470d03b78fc31491a9e4d433106ef2
- https://git.kernel.org/stable/c/7717fc1a12f88701573f9ed897cc4f6699c661e3
- https://git.kernel.org/stable/c/d49c85a1913385eed46dd16a25ad0928253767f0
Modified: 2025-10-28
CVE-2023-52933
In the Linux kernel, the following vulnerability has been resolved: Squashfs: fix handling and sanity checking of xattr_ids count A Sysbot [1] corrupted filesystem exposes two flaws in the handling and sanity checking of the xattr_ids count in the filesystem. Both of these flaws cause computation overflow due to incorrect typing. In the corrupted filesystem the xattr_ids value is 4294967071, which stored in a signed variable becomes the negative number -225. Flaw 1 (64-bit systems only): The signed integer xattr_ids variable causes sign extension. This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The variable is first multiplied by sizeof(struct squashfs_xattr_id) where the type of the sizeof operator is "unsigned long". On a 64-bit system this is 64-bits in size, and causes the negative number to be sign extended and widened to 64-bits and then become unsigned. This produces the very large number 18446744073709548016 or 2^64 - 3600. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0 (stored in len). Flaw 2 (32-bit systems only): On a 32-bit system the integer variable is not widened by the unsigned long type of the sizeof operator (32-bits), and the signedness of the variable has no effect due it always being treated as unsigned. The above corrupted xattr_ids value of 4294967071, when multiplied overflows and produces the number 4294963696 or 2^32 - 3400. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows again and produces a length of 0. The effect of the 0 length computation: In conjunction with the corrupted xattr_ids field, the filesystem also has a corrupted xattr_table_start value, where it matches the end of filesystem value of 850. This causes the following sanity check code to fail because the incorrectly computed len of 0 matches the incorrect size of the table reported by the superblock (0 bytes). len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids); indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids); /* * The computed size of the index table (len bytes) should exactly * match the table start and end points */ start = table_start + sizeof(*id_table); end = msblk->bytes_used; if (len != (end - start)) return ERR_PTR(-EINVAL); Changing the xattr_ids variable to be "usigned int" fixes the flaw on a 64-bit system. This relies on the fact the computation is widened by the unsigned long type of the sizeof operator. Casting the variable to u64 in the above macro fixes this flaw on a 32-bit system. It also means 64-bit systems do not implicitly rely on the type of the sizeof operator to widen the computation. [1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/
- https://git.kernel.org/stable/c/1369322c1de52c7b9b988b95c9903110a4566778
- https://git.kernel.org/stable/c/5c4d4a83bf1a862d80c1efff1c6e3ce33b501e2e
- https://git.kernel.org/stable/c/7fe583c9bec10cd4b76231c51b37f3e4ca646e01
- https://git.kernel.org/stable/c/997bed0f3cde78a3e639d624985bf4a95cf767e6
- https://git.kernel.org/stable/c/a7da7d01ac5ce9b369a1ac70e1197999cc6c9686
- https://git.kernel.org/stable/c/b38c3e9e0adc01956cc3e5a52e4d3f92f79d88e2
- https://git.kernel.org/stable/c/f65c4bbbd682b0877b669828b4e033b8d5d0a2dc
Modified: 2025-04-01
CVE-2023-52973
In the Linux kernel, the following vulnerability has been resolved:
vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF
After a call to console_unlock() in vcs_read() the vc_data struct can be
freed by vc_deallocate(). Because of that, the struct vc_data pointer
load must be done at the top of while loop in vcs_read() to avoid a UAF
when vcs_size() is called.
Syzkaller reported a UAF in vcs_size().
BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)
Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537
CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1
Hardware name: Red Hat KVM, BIOS 1.15.0-2.module
Call Trace:
- https://git.kernel.org/stable/c/226fae124b2dac217ea5436060d623ff3385bc34
- https://git.kernel.org/stable/c/55515d7d8743b71b80bfe68e89eb9d92630626ab
- https://git.kernel.org/stable/c/6332f52f44b9776568bf3c0b714ddfb0bb175e78
- https://git.kernel.org/stable/c/8506f16aae9daf354e3732bcfd447e2a97f023df
- https://git.kernel.org/stable/c/af79ea9a2443016f64d8fd8d72020cc874f0e066
- https://git.kernel.org/stable/c/d0332cbf53dad06a22189cc341391237f4ea6d9f
- https://git.kernel.org/stable/c/fc9e27f3ba083534b8bbf72ab0f5c810ffdc7d18
Modified: 2025-04-01
CVE-2023-52974
In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddress If during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails, userspace could be accessing the host's ipaddress attr. If we then free the session via iscsi_session_teardown() while userspace is still accessing the session we will hit a use after free bug. Set the tcp_sw_host->session after we have completed session creation and can no longer fail.
- https://git.kernel.org/stable/c/0aaabdb900c7415caa2006ef580322f7eac5f6b6
- https://git.kernel.org/stable/c/496af9d3682ed4c28fb734342a09e6cc0c056ea4
- https://git.kernel.org/stable/c/61e43ebfd243bcbad11be26bd921723027b77441
- https://git.kernel.org/stable/c/6abd4698f4c8a78e7bbfc421205c060c199554a0
- https://git.kernel.org/stable/c/9758ffe1c07b86aefd7ca8e40d9a461293427ca0
- https://git.kernel.org/stable/c/d4d765f4761f9e3a2d62992f825aeee593bcb6b9
- https://git.kernel.org/stable/c/f484a794e4ee2a9ce61f52a78e810ac45f3fe3b3
Modified: 2025-10-01
CVE-2023-52976
In the Linux kernel, the following vulnerability has been resolved: efi: fix potential NULL deref in efi_mem_reserve_persistent When iterating on a linked list, a result of memremap is dereferenced without checking it for NULL. This patch adds a check that falls back on allocating a new page in case memremap doesn't succeed. Found by Linux Verification Center (linuxtesting.org) with SVACE. [ardb: return -ENOMEM instead of breaking out of the loop]
- https://git.kernel.org/stable/c/87d4ff18738fd71e7e3c10827c80257da6283697
- https://git.kernel.org/stable/c/966d47e1f27c45507c5df82b2a2157e5a4fd3909
- https://git.kernel.org/stable/c/a2e6a9ff89f13666a1c3ff7195612ab949ea9afc
- https://git.kernel.org/stable/c/d8fc0b5fb3e816a4a8684bcd3ed02cbef0fce23c
- https://git.kernel.org/stable/c/d92a25627bcdf264183670da73c9a60c0bac327e
Modified: 2025-10-01
CVE-2023-52984
In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83822: Fix null pointer access on DP83825/DP83826 devices The probe() function is only used for the DP83822 PHY, leaving the private data pointer uninitialized for the smaller DP83825/26 models. While all uses of the private data structure are hidden in 82822 specific callbacks, configuring the interrupt is shared across all models. This causes a NULL pointer dereference on the smaller PHYs as it accesses the private data unchecked. Verifying the pointer avoids that.
Modified: 2025-10-29
CVE-2023-52986
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener A listening socket linked to a sockmap has its sk_prot overridden. It points to one of the struct proto variants in tcp_bpf_prots. The variant depends on the socket's family and which sockmap programs are attached. A child socket cloned from a TCP listener initially inherits their sk_prot. But before cloning is finished, we restore the child's proto to the listener's original non-tcp_bpf_prots one. This happens in tcp_create_openreq_child -> tcp_bpf_clone. Today, in tcp_bpf_clone we detect if the child's proto should be restored by checking only for the TCP_BPF_BASE proto variant. This is not correct. The sk_prot of listening socket linked to a sockmap can point to to any variant in tcp_bpf_prots. If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, then the child socket unintentionally is left if the inherited sk_prot by tcp_bpf_clone. This leads to issues like infinite recursion on close [1], because the child state is otherwise not set up for use with tcp_bpf_prot operations. Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants. Note that it wouldn't be sufficient to check the socket state when overriding the sk_prot in tcp_bpf_update_proto in order to always use the TCP_BPF_BASE variant for listening sockets. Since commit b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage") it is possible for a socket to transition to TCP_LISTEN state while already linked to a sockmap, e.g. connect() -> insert into map -> connect(AF_UNSPEC) -> listen(). [1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/
Modified: 2025-10-01
CVE-2023-52988
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path() snd_hda_get_connections() can return a negative error code. It may lead to accessing 'conn' array at a negative index. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/1b9256c96220bcdba287eeeb90e7c910c77f8c46
- https://git.kernel.org/stable/c/2b557fa635e7487f638c0f030c305870839eeda2
- https://git.kernel.org/stable/c/437e50ef6290ac835d526d0e45f466a0aa69ba1b
- https://git.kernel.org/stable/c/6e1f586ddec48d71016b81acf68ba9f49ca54db8
- https://git.kernel.org/stable/c/b9cee506da2b7920b5ea02ccd8e78a907d0ee7aa
- https://git.kernel.org/stable/c/d6870f3800dbb212ae8433183ee82f566d067c6c
- https://git.kernel.org/stable/c/f011360ad234a07cb6fbcc720fff646a93a9f0d6
Modified: 2025-10-01
CVE-2023-52989
In the Linux kernel, the following vulnerability has been resolved: firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region This patch is fix for Linux kernel v2.6.33 or later. For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem have had an issue of use-after-free. The subsystem allows multiple user space listeners to the region, while data of the payload was likely released before the listeners execute read(2) to access to it for copying to user space. The issue was fixed by a commit 281e20323ab7 ("firewire: core: fix use-after-free regression in FCP handler"). The object of payload is duplicated in kernel space for each listener. When the listener executes ioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to be released. However, it causes memory leak since the commit relies on call of release_request() in drivers/firewire/core-cdev.c. Against the expectation, the function is never called due to the design of release_client_resource(). The function delegates release task to caller when called with non-NULL fourth argument. The implementation of ioctl_send_response() is the case. It should release the object explicitly. This commit fixes the bug.
- https://git.kernel.org/stable/c/356ff89acdbe6a66019154bc7eb2d300f5b15103
- https://git.kernel.org/stable/c/531390a243ef47448f8bad01c186c2787666bf4d
- https://git.kernel.org/stable/c/53785fd9b315583cf029e39f72b73d23704a2253
- https://git.kernel.org/stable/c/5f4543c9382ae2d5062f6aa4fecae0c9258d0b0e
- https://git.kernel.org/stable/c/b2cd3947d116bb9ba7ff097b5fc747a8956764db
- https://git.kernel.org/stable/c/c8bdc88216f09cb7387fedbdf613524367328616
- https://git.kernel.org/stable/c/d5a2dcee53fa6e6e2822f93cb3f1b0cd23163bee
Modified: 2025-10-01
CVE-2023-52991
In the Linux kernel, the following vulnerability has been resolved:
net: fix NULL pointer in skb_segment_list
Commit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
introduced UDP listifyed GRO. The segmentation relies on frag_list being
untouched when passing through the network stack. This assumption can be
broken sometimes, where frag_list itself gets pulled into linear area,
leaving frag_list being NULL. When this happens it can trigger
following NULL pointer dereference, and panic the kernel. Reverse the
test condition should fix it.
[19185.577801][ C1] BUG: kernel NULL pointer dereference, address:
...
[19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390
...
[19185.834644][ C1] Call Trace:
[19185.841730][ C1]
Modified: 2025-10-29
CVE-2023-52992
In the Linux kernel, the following vulnerability has been resolved:
bpf: Skip task with pid=1 in send_signal_common()
The following kernel panic can be triggered when a task with pid=1 attaches
a prog that attempts to send killing signal to itself, also see [1] for more
details:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148
Call Trace:
- https://git.kernel.org/stable/c/0dfef503133565fa0bcf3268d8eeb5b181191a65
- https://git.kernel.org/stable/c/1283a01b6e19d05f7ed49584ea653947245cd41e
- https://git.kernel.org/stable/c/4923160393b06a34759a11b17930d71e06f396f2
- https://git.kernel.org/stable/c/a1c0263f1eb4deee132e11e52ee6982435460d81
- https://git.kernel.org/stable/c/a3d81bc1eaef48e34dd0b9b48eefed9e02a06451
Modified: 2025-10-01
CVE-2023-52993
In the Linux kernel, the following vulnerability has been resolved: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code. This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference. The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type. Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.
- https://git.kernel.org/stable/c/0b08201158f177aab469e356b4d6af24fdd118df
- https://git.kernel.org/stable/c/137f1b47da5f58805da42c1b7811e28c1e353f39
- https://git.kernel.org/stable/c/496975d1a2937f4baadf3d985991b13fc4fc4f27
- https://git.kernel.org/stable/c/5fa55950729d0762a787451dc52862c3f850f859
- https://git.kernel.org/stable/c/744fe9be9665227335539b7a77ece8d9ff62b6c0
- https://git.kernel.org/stable/c/8770cd9d7c14aa99c255a0d08186f0be953e1638
- https://git.kernel.org/stable/c/e284c273dbb4c1ed68d4204bff94d0b10e4a90f5
Modified: 2025-10-30
CVE-2023-52996
In the Linux kernel, the following vulnerability has been resolved: ipv4: prevent potential spectre v1 gadget in fib_metrics_match() if (!type) continue; if (type > RTAX_MAX) return false; ... fi_val = fi->fib_metrics->metrics[type - 1]; @type being used as an array index, we need to prevent cpu speculation or risk leaking kernel memory content.
- https://git.kernel.org/stable/c/5e9398a26a92fc402d82ce1f97cc67d832527da0
- https://git.kernel.org/stable/c/7f9828fb1f688210e681268490576f0ca65c322a
- https://git.kernel.org/stable/c/8f0eb24f1a7a60ce635f0d757a46f1a37a4d467d
- https://git.kernel.org/stable/c/ca3cf947760de050d558293002ad3e7f4b8745d2
- https://git.kernel.org/stable/c/f9753ebd61be2d957b5504cbd3fd719674f05b7a
Modified: 2025-10-30
CVE-2023-52997
In the Linux kernel, the following vulnerability has been resolved: ipv4: prevent potential spectre v1 gadget in ip_metrics_convert() if (!type) continue; if (type > RTAX_MAX) return -EINVAL; ... metrics[type - 1] = val; @type being used as an array index, we need to prevent cpu speculation or risk leaking kernel memory content.
- https://git.kernel.org/stable/c/1d1d63b612801b3f0a39b7d4467cad0abd60e5c8
- https://git.kernel.org/stable/c/34c6142f0df9cd75cba5a7aa9df0960d2854b415
- https://git.kernel.org/stable/c/6850fe301d015a7d2012d1de8caf43dafb7cc2f6
- https://git.kernel.org/stable/c/746db9ec1e672eee13965625ddac0d97e16fa20c
- https://git.kernel.org/stable/c/d50e7348b44f1e046121ff5be01b7fb6978a1149
- https://git.kernel.org/stable/c/ef050cf5fb70d995a0d03244e25179b7c66a924a
Modified: 2025-04-01
CVE-2023-52999
In the Linux kernel, the following vulnerability has been resolved:
net: fix UaF in netns ops registration error path
If net_assign_generic() fails, the current error path in ops_init() tries
to clear the gen pointer slot. Anyway, in such error path, the gen pointer
itself has not been modified yet, and the existing and accessed one is
smaller than the accessed index, causing an out-of-bounds error:
BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320
Write of size 8 at addr ffff888109124978 by task modprobe/1018
CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/12075708f2e77ee6a9f8bb2cf512c38be3099794
- https://git.kernel.org/stable/c/66689a72ba73575e76d4f6a8748d3fa2690ec1c4
- https://git.kernel.org/stable/c/71ab9c3e2253619136c31c89dbb2c69305cc89b1
- https://git.kernel.org/stable/c/ad0dfe9bcf0d78e699c7efb64c90ed062dc48bea
- https://git.kernel.org/stable/c/d4c008f3b7f7d4ffd311eb2dae5e75b3cbddacd0
- https://git.kernel.org/stable/c/ddd49cbbd4c1ceb38032018b589b44208e54f55e
Modified: 2025-10-30
CVE-2023-53000
In the Linux kernel, the following vulnerability has been resolved: netlink: prevent potential spectre v1 gadgets Most netlink attributes are parsed and validated from __nla_validate_parse() or validate_nla() u16 type = nla_type(nla); if (type == 0 || type > maxtype) { /* error or continue */ } @type is then used as an array index and can be used as a Spectre v1 gadget. array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users. This should take care of vast majority of netlink uses, but an audit is needed to take care of others where validation is not yet centralized in core netlink functions.
- https://git.kernel.org/stable/c/3e5082b1c66c7783fbcd79b5b178573230e528ff
- https://git.kernel.org/stable/c/41b74e95f297ac360ca7ed6bf200100717cb6c45
- https://git.kernel.org/stable/c/539ca5dcbc91134bbe2c45677811c31d8b030d2d
- https://git.kernel.org/stable/c/992e4ff7116a77968039277b5d6aaa535c2f2184
- https://git.kernel.org/stable/c/f0950402e8c76e7dcb08563f1b4e8000fbc62455
Modified: 2025-04-01
CVE-2023-53003
In the Linux kernel, the following vulnerability has been resolved: EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info The memory for llcc_driv_data is allocated by the LLCC driver. But when it is passed as the private driver info to the EDAC core, it will get freed during the qcom_edac driver release. So when the qcom_edac driver gets probed again, it will try to use the freed data leading to the use-after-free bug. Hence, do not pass llcc_driv_data as pvt_info but rather reference it using the platform_data pointer in the qcom_edac driver.
- https://git.kernel.org/stable/c/66e10d5f399629ef7877304d9ba2b35d0474e7eb
- https://git.kernel.org/stable/c/6f0351d0c311951b8b3064db91e61841e85b2b96
- https://git.kernel.org/stable/c/76d9ebb7f0bc10fbc78b6d576751552edf743968
- https://git.kernel.org/stable/c/977c6ba624f24ae20cf0faee871257a39348d4a9
- https://git.kernel.org/stable/c/bff5243bd32661cf9ce66f6d9210fc8f89bda145
Modified: 2025-10-01
CVE-2023-53005
In the Linux kernel, the following vulnerability has been resolved: trace_events_hist: add check for return value of 'create_hist_field' Function 'create_hist_field' is called recursively at trace_events_hist.c:1954 and can return NULL-value that's why we have to check it to avoid null pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/31b2414abeaa6de0490e85164badc6dcb1bb8ec9
- https://git.kernel.org/stable/c/592ba7116fa620425725ff0972691f352ba3caf6
- https://git.kernel.org/stable/c/886aa449235f478e262bbd5dcdee6ed6bc202949
- https://git.kernel.org/stable/c/8b152e9150d07a885f95e1fd401fc81af202d9a4
- https://git.kernel.org/stable/c/b4e7e81b4fdfcf457daee6b7a61769f62198d840
- https://git.kernel.org/stable/c/d2d1ada58e7cc100b8d7d6b082d19321ba4a700a
Modified: 2025-10-30
CVE-2023-53006
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix oops due to uncleared server->smbd_conn in reconnect In smbd_destroy(), clear the server->smbd_conn pointer after freeing the smbd_connection struct that it points to so that reconnection doesn't get confused.
- https://git.kernel.org/stable/c/4b83bc6f87eedab4599b0123e572a422689444be
- https://git.kernel.org/stable/c/5109607a4ece7cd8536172bf7549eb4dce1f3576
- https://git.kernel.org/stable/c/91be54849d5392050f5b847b42bd5e6221551ac8
- https://git.kernel.org/stable/c/a9640c0b268405f2540e8203a545e930ea88bb7d
- https://git.kernel.org/stable/c/b7ab9161cf5ddc42a288edf9d1a61f3bdffe17c7
- https://git.kernel.org/stable/c/e037baee16e0b9ace7e730888fcae9cec11daff2
Modified: 2025-10-30
CVE-2023-53007
In the Linux kernel, the following vulnerability has been resolved:
tracing: Make sure trace_printk() can output as soon as it can be used
Currently trace_printk() can be used as soon as early_trace_init() is
called from start_kernel(). But if a crash happens, and
"ftrace_dump_on_oops" is set on the kernel command line, all you get will
be:
[ 0.456075]
- https://git.kernel.org/stable/c/198c83963f6335ca6d690cff067679560f2a3a22
- https://git.kernel.org/stable/c/3bb06eb6e9acf7c4a3e1b5bc87aed398ff8e2253
- https://git.kernel.org/stable/c/76b2390fdc80c0a8300e5da5b6b62d201b6fe9ce
- https://git.kernel.org/stable/c/b0af180514edea6c83dc9a299d9f383009c99f25
- https://git.kernel.org/stable/c/b94d7c7654356860dd7719120c7d15ba38b6162a
- https://git.kernel.org/stable/c/de3930a4883ddad2244efd6d349013294c62c75c
- https://git.kernel.org/stable/c/f97eb0ab066133483a65c93eb894748de2f6b598
Modified: 2025-10-01
CVE-2023-53015
In the Linux kernel, the following vulnerability has been resolved: HID: betop: check shape of output reports betopff_init() only checks the total sum of the report counts for each report field to be at least 4, but hid_betopff_play() expects 4 report fields. A device advertising an output report with one field and 4 report counts would pass the check but crash the kernel with a NULL pointer dereference in hid_betopff_play().
- https://git.kernel.org/stable/c/07bc32e53c7bd5c91472cc485231ef6274db9b76
- https://git.kernel.org/stable/c/1a2a47b85cab50a3c146731bfeaf2d860f5344ee
- https://git.kernel.org/stable/c/28fc6095da22dc88433d79578ae1c495ebe8ca43
- https://git.kernel.org/stable/c/3782c0d6edf658b71354a64d60aa7a296188fc90
- https://git.kernel.org/stable/c/7317326f685824c7c29bd80841fd18041af6bb73
- https://git.kernel.org/stable/c/d3065cc56221d1a5eda237e94eaf2a627b88ab79
- https://git.kernel.org/stable/c/dbab4dba400d6ea9a9697fbbd287adbf7db1dac4
Modified: 2025-10-30
CVE-2023-53019
In the Linux kernel, the following vulnerability has been resolved: net: mdio: validate parameter addr in mdiobus_get_phy() The caller may pass any value as addr, what may result in an out-of-bounds access to array mdio_map. One existing case is stmmac_init_phy() that may pass -1 as addr. Therefore validate addr before using it.
- https://git.kernel.org/stable/c/1d80c259dfbadefa61b7ea334dfce5cb57f8c72f
- https://git.kernel.org/stable/c/4bc5f1f6bc94e695dfd912122af96e7115a0ddb8
- https://git.kernel.org/stable/c/7879626296e6ffd838ae0f2af1ab49ee46354973
- https://git.kernel.org/stable/c/867dbe784c5010a466f00a7d1467c1c5ea569c75
- https://git.kernel.org/stable/c/8a7b9560a3a8eb8724888c426e05926752f73aa0
- https://git.kernel.org/stable/c/ad67de330d83e8078372b52af18ffe8d39e26c85
- https://git.kernel.org/stable/c/c431a3d642593bbdb99e8a9e3eed608b730db6f8
Modified: 2025-10-01
CVE-2023-53020
In the Linux kernel, the following vulnerability has been resolved: l2tp: close all race conditions in l2tp_tunnel_register() The code in l2tp_tunnel_register() is racy in several ways: 1. It modifies the tunnel socket _after_ publishing it. 2. It calls setup_udp_tunnel_sock() on an existing socket without locking. 3. It changes sock lock class on fly, which triggers many syzbot reports. This patch amends all of them by moving socket initialization code before publishing and under sock lock. As suggested by Jakub, the l2tp lockdep class is not necessary as we can just switch to bh_lock_sock_nested().
Modified: 2025-04-01
CVE-2023-53021
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_taprio: fix possible use-after-free syzbot reported a nasty crash [1] in net_tx_action() which made little sense until we got a repro. This repro installs a taprio qdisc, but providing an invalid TCA_RATE attribute. qdisc_create() has to destroy the just initialized taprio qdisc, and taprio_destroy() is called. However, the hrtimer used by taprio had already fired, therefore advance_sched() called __netif_schedule(). Then net_tx_action was trying to use a destroyed qdisc. We can not undo the __netif_schedule(), so we must wait until one cpu serviced the qdisc before we can proceed. Many thanks to Alexander Potapenko for his help. [1] BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline] BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] do_raw_spin_trylock include/linux/spinlock.h:191 [inline] __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 spin_trylock include/linux/spinlock.h:359 [inline] qdisc_run_begin include/net/sch_generic.h:187 [inline] qdisc_run+0xee/0x540 include/net/pkt_sched.h:125 net_tx_action+0x77c/0x9a0 net/core/dev.c:5086 __do_softirq+0x1cc/0x7fb kernel/softirq.c:571 run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934 smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164 kthread+0x31b/0x430 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Uninit was created at: slab_post_alloc_hook mm/slab.h:732 [inline] slab_alloc_node mm/slub.c:3258 [inline] __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970 kmalloc_reserve net/core/skbuff.c:358 [inline] __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430 alloc_skb include/linux/skbuff.h:1257 [inline] nlmsg_new include/net/netlink.h:953 [inline] netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436 netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507 rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108 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] ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536 __sys_sendmsg net/socket.c:2565 [inline] __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
- https://git.kernel.org/stable/c/1200388a0b1c3c6fda48d4d2143db8f7e4ef5348
- https://git.kernel.org/stable/c/3a415d59c1dbec9d772dbfab2d2520d98360caae
- https://git.kernel.org/stable/c/c53acbf2facfdfabdc6e6984a1a38f5d38b606a1
- https://git.kernel.org/stable/c/c60fe70078d6e515f424cb868d07e00411b27fbc
- https://git.kernel.org/stable/c/d3b2d2820a005e43855fa71b80c4a4b194201c60
Modified: 2025-04-01
CVE-2023-53023
In the Linux kernel, the following vulnerability has been resolved: net: nfc: Fix use-after-free in local_cleanup() Fix a use-after-free that occurs in kfree_skb() called from local_cleanup(). This could happen when killing nfc daemon (e.g. neard) after detaching an nfc device. When detaching an nfc device, local_cleanup() called from nfc_llcp_unregister_device() frees local->rx_pending and decreases local->ref by kref_put() in nfc_llcp_local_put(). In the terminating process, nfc daemon releases all sockets and it leads to decreasing local->ref. After the last release of local->ref, local_cleanup() called from local_release() frees local->rx_pending again, which leads to the bug. Setting local->rx_pending to NULL in local_cleanup() could prevent use-after-free when local_cleanup() is called twice. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in kfree_skb() Call Trace: dump_stack_lvl (lib/dump_stack.c:106) print_address_description.constprop.0.cold (mm/kasan/report.c:306) kasan_check_range (mm/kasan/generic.c:189) kfree_skb (net/core/skbuff.c:955) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172) nfc_llcp_local_put (net/nfc/llcp_core.c:181) llcp_sock_destruct (net/nfc/llcp_sock.c:959) __sk_destruct (net/core/sock.c:2133) sk_destruct (net/core/sock.c:2181) __sk_free (net/core/sock.c:2192) sk_free (net/core/sock.c:2203) llcp_sock_release (net/nfc/llcp_sock.c:646) __sock_release (net/socket.c:650) sock_close (net/socket.c:1365) __fput (fs/file_table.c:306) task_work_run (kernel/task_work.c:179) ptrace_notify (kernel/signal.c:2354) syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278) syscall_exit_to_user_mode (kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:86) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106) Allocated by task 4719: kasan_save_stack (mm/kasan/common.c:45) __kasan_slab_alloc (mm/kasan/common.c:325) slab_post_alloc_hook (mm/slab.h:766) kmem_cache_alloc_node (mm/slub.c:3497) __alloc_skb (net/core/skbuff.c:552) pn533_recv_response (drivers/nfc/pn533/usb.c:65) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671) usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704) tasklet_action_common.isra.0 (kernel/softirq.c:797) __do_softirq (kernel/softirq.c:571) Freed by task 1901: kasan_save_stack (mm/kasan/common.c:45) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/genericdd.c:518) __kasan_slab_free (mm/kasan/common.c:236) kmem_cache_free (mm/slub.c:3809) kfree_skbmem (net/core/skbuff.c:874) kfree_skb (net/core/skbuff.c:931) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617) nfc_unregister_device (net/nfc/core.c:1179) pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846) pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579) usb_unbind_interface (drivers/usb/core/driver.c:458) device_release_driver_internal (drivers/base/dd.c:1279) bus_remove_device (drivers/base/bus.c:529) device_del (drivers/base/core.c:3665) usb_disable_device (drivers/usb/core/message.c:1420) usb_disconnect (drivers/usb/core.c:2261) hub_event (drivers/usb/core/hub.c:5833) process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281) worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423) kthread (kernel/kthread.c:319) ret_from_fork (arch/x86/entry/entry_64.S:301)
- https://git.kernel.org/stable/c/4bb4db7f3187c6e3de6b229ffc87cdb30a2d22b6
- https://git.kernel.org/stable/c/54f7be61584b8ec4c6df405f479495b9397bae4a
- https://git.kernel.org/stable/c/7f129927feaf7c10b1c38bbce630172e9a08c834
- https://git.kernel.org/stable/c/a59cdbda3714e11aa3ab579132864c4c8c6d54f9
- https://git.kernel.org/stable/c/ad1baab3a5c03692d22ce446f38596a126377f6a
- https://git.kernel.org/stable/c/b09ae26f08aaf2d85f96ea7f90ddd3387f62216f
- https://git.kernel.org/stable/c/d3605282ec3502ec8847915eb2cf1f340493ff79
Modified: 2026-01-22
CVE-2023-53024
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") inserts lfence instructions after 1) initializing a stack slot and 2) spilling a pointer to the stack. However, this does not cover cases where a stack slot is first initialized with a pointer (subject to sanitization) but then overwritten with a scalar (not subject to sanitization because the slot was already initialized). In this case, the second write may be subject to speculative store bypass (SSB) creating a speculative pointer-as-scalar type confusion. This allows the program to subsequently leak the numerical pointer value using, for example, a branch-based cache side channel. To fix this, also sanitize scalars if they write a stack slot that previously contained a pointer. Assuming that pointer-spills are only generated by LLVM on register-pressure, the performance impact on most real-world BPF programs should be small. The following unprivileged BPF bytecode drafts a minimal exploit and the mitigation: [...] // r6 = 0 or 1 (skalar, unknown user input) // r7 = accessible ptr for side channel // r10 = frame pointer (fp), to be leaked // r9 = r10 # fp alias to encourage ssb *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked // lfence added here because of pointer spill to stack. // // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor // for no r9-r10 dependency. // *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID, // store may be subject to SSB // // fix: also add an lfence when the slot contained a ptr // r8 = *(u64 *)(r9 - 8) // r8 = architecturally a scalar, speculatively a ptr // // leak ptr using branch-based cache side channel: r8 &= 1 // choose bit to leak if r8 == 0 goto SLOW // no mispredict // architecturally dead code if input r6 is 0, // only executes speculatively iff ptr bit is 1 r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast) SLOW: [...] After running this, the program can time the access to *(r7 + 0) to determine whether the chosen pointer bit was 0 or 1. Repeat this 64 times to recover the whole address on amd64. In summary, sanitization can only be skipped if one scalar is overwritten with another scalar. Scalar-confusion due to speculative store bypass can not lead to invalid accesses because the pointer bounds deducted during verification are enforced using branchless logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") for details. Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks} because speculative leaks are likely unexpected if these were enabled. For example, leaking the address to a protected log file may be acceptable while disabling the mitigation might unintentionally leak the address into the cached-state of a map that is accessible to unprivileged processes.
- https://git.kernel.org/stable/c/01bdcc73dbe7be3ad4d4ee9a59b71e42f461a528
- https://git.kernel.org/stable/c/81b3374944d201872cfcf82730a7860f8e7c31dd
- https://git.kernel.org/stable/c/aae109414a57ab4164218f36e2e4a17f027fcaaa
- https://git.kernel.org/stable/c/b0c89ef025562161242a7c19b213bd6b272e93df
- https://git.kernel.org/stable/c/da75dec7c6617bddad418159ffebcb133f008262
- https://git.kernel.org/stable/c/e4f4db47794c9f474b184ee1418f42e6a07412b6
Modified: 2025-10-01
CVE-2023-53026
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix ib block iterator counter overflow When registering a new DMA MR after selecting the best aligned page size for it, we iterate over the given sglist to split each entry to smaller, aligned to the selected page size, DMA blocks. In given circumstances where the sg entry and page size fit certain sizes and the sg entry is not aligned to the selected page size, the total size of the aligned pages we need to cover the sg entry is >= 4GB. Under this circumstances, while iterating page aligned blocks, the counter responsible for counting how much we advanced from the start of the sg entry is overflowed because its type is u32 and we pass 4GB in size. This can lead to an infinite loop inside the iterator function because the overflow prevents the counter to be larger than the size of the sg entry. Fix the presented problem by changing the advancement condition to eliminate overflow. Backtrace: [ 192.374329] efa_reg_user_mr_dmabuf [ 192.376783] efa_register_mr [ 192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000 [ 192.386423] pg_sz [0x80000000] umem_length[0xc0000000] [ 192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3 [ 192.399559] hp_cnt[3], pages_in_hp[524288] [ 192.403690] umem->sgt_append.sgt.nents[1] [ 192.407905] number entries: [1], pg_bit: [31] [ 192.411397] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.415601] biter->__sg_advance [665837568] sg_dma_len[3221225472] [ 192.419823] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.423976] biter->__sg_advance [2813321216] sg_dma_len[3221225472] [ 192.428243] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.432397] biter->__sg_advance [665837568] sg_dma_len[3221225472]
- https://git.kernel.org/stable/c/0afec5e9cea732cb47014655685a2a47fb180c31
- https://git.kernel.org/stable/c/362c9489720b31b6aa7491423ba65a4e98aa9838
- https://git.kernel.org/stable/c/43811d07ea64366af8ec9e168c558ec51440c39e
- https://git.kernel.org/stable/c/902063a9fea5f8252df392ade746bc9cfd07a5ae
- https://git.kernel.org/stable/c/d66c1d4178c219b6e7d7a6f714e3e3656faccc36
Modified: 2025-10-31
CVE-2023-53031
In the Linux kernel, the following vulnerability has been resolved:
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP
and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.
Command to trigger the warning:
# perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5
Performance counter stats for 'sleep 5':
0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/
5.002117947 seconds time elapsed
0.000131000 seconds user
0.001063000 seconds sys
Below is snippet of the warning in dmesg:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec
preempt_count: 2, expected: 0
4 locks held by perf-exec/2869:
#0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90
#1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0
#2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510
#3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510
irq event stamp: 4806
hardirqs last enabled at (4805): [
- https://git.kernel.org/stable/c/424bcb570cb320d1d15238cd4c933522b90f78fa
- https://git.kernel.org/stable/c/76d588dddc459fefa1da96e0a081a397c5c8e216
- https://git.kernel.org/stable/c/8cbeb60320ac45a8240b561c8ef466b86c34dedc
- https://git.kernel.org/stable/c/a90d339f1f66be4a946769b565668e2bd0686dfa
- https://git.kernel.org/stable/c/d0c6d2a31026102d4738b47a610bed4401b9834f
Modified: 2025-10-31
CVE-2023-53032
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function. When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of an arithmetic expression 2 << (netmask - mask_bits - 1) is subject to overflow due to a failure casting operands to a larger data type before performing the arithmetic. Note that it's harmless since the value will be checked at the next step. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/4e6a70fd840400e3a2e784a6673968a3eb2431c0
- https://git.kernel.org/stable/c/511cf17b2447fc41cfef8d71936e1fa53e395c1e
- https://git.kernel.org/stable/c/9ea4b476cea1b7d461d16dda25ca3c7e616e2d15
- https://git.kernel.org/stable/c/dfd834ccc1b88bbbab81b9046a3a539dd0c2d14f
- https://git.kernel.org/stable/c/e137d9bb26bd85ce07323a38e38ceb0b160db841
- https://git.kernel.org/stable/c/e88865876d47c790be0d5e23973499d75d034364
- https://git.kernel.org/stable/c/feefb33eefa166fc3e0fd17547b0bc0cb3baced9
Modified: 2025-10-31
CVE-2023-53033
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: incorrect arithmetics when fetching VLAN header bits If the offset + length goes over the ethernet + vlan header, then the length is adjusted to copy the bytes that are within the boundaries of the vlan_ethhdr scratchpad area. The remaining bytes beyond ethernet + vlan header are copied directly from the skbuff data area. Fix incorrect arithmetic operator: subtract, not add, the size of the vlan header in case of double-tagged packets to adjust the length accordingly to address CVE-2023-0179.
Modified: 2026-01-14
CVE-2023-53224
In the Linux kernel, the following vulnerability has been resolved:
ext4: Fix function prototype mismatch for ext4_feat_ktype
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.
ext4_feat_ktype was setting the "release" handler to "kfree", which
doesn't have a matching function prototype. Add a simple wrapper
with the correct prototype.
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.
Note that this code is only reached when ext4 is a loadable module and
it is being unloaded:
CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698)
...
RIP: 0010:kobject_put+0xbb/0x1b0
...
Call Trace:
- https://git.kernel.org/stable/c/0a1394e07c5d6bf1bfc25db8589ff1b1bfb6f46a
- https://git.kernel.org/stable/c/118901ad1f25d2334255b3d50512fa20591531cd
- https://git.kernel.org/stable/c/1ba10d3640e9783dad811fe4e24d55465c37c64d
- https://git.kernel.org/stable/c/2b69cdd9f9a7f596e3dd31f05f9852940d177924
- https://git.kernel.org/stable/c/94d8de83286fb1827340eba35b61c308f6b46ead
- https://git.kernel.org/stable/c/99e3fd21f8fc975c95e8cf76fbf6a3d2656f8f71
- https://git.kernel.org/stable/c/c98077f7598a562f51051eec043be0cb3e1b1b5e
Modified: 2026-01-14
CVE-2023-53330
In the Linux kernel, the following vulnerability has been resolved: caif: fix memory leak in cfctrl_linkup_request() When linktype is unknown or kzalloc failed in cfctrl_linkup_request(), pkt is not released. Add release process to error path.
- https://git.kernel.org/stable/c/1dddeceb26002cfea4c375e92ac6498768dc7349
- https://git.kernel.org/stable/c/33df9c5d5e2a18c70f5f5f3c2757d654c1b6ffa3
- https://git.kernel.org/stable/c/3acf3783a84cbdf0c9f8cf2f32ee9c49af93a2da
- https://git.kernel.org/stable/c/3ad47c8aa5648226184415e4a0cb1bf67ffbfd48
- https://git.kernel.org/stable/c/84b2cc7b36b7f6957d307fb3d01603f93cb2d655
- https://git.kernel.org/stable/c/badea57569db04b010e922e29a7aaf40a979a70b
- https://git.kernel.org/stable/c/dc1bc903970bdf63ca40ab923d3ccb765da9a8d9
- https://git.kernel.org/stable/c/fe69230f05897b3de758427b574fc98025dfc907
Modified: 2026-03-21
CVE-2023-53592
In the Linux kernel, the following vulnerability has been resolved: gpio: sifive: Fix refcount leak in sifive_gpio_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/694175cd8a1643cde3acb45c9294bca44a8e08e9
- https://git.kernel.org/stable/c/95da1882ce9372ba20278f87cdb7a34f9812c4b5
- https://git.kernel.org/stable/c/9a402a210798662b04cbe6ca466e916a15efa03a
- https://git.kernel.org/stable/c/f4a2ad1002006548e235255c65a4f1d07312be9d
- https://git.kernel.org/stable/c/f9fb4776ebbc16dfc512adbdc0fe218acb47c7cc
Modified: 2026-02-05
CVE-2023-53625
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gvt: fix vgpu debugfs clean in remove
Check carefully on root debugfs available when destroying vgpu,
e.g in remove case drm minor's debugfs root might already be destroyed,
which led to kernel oops like below.
Console: switching to colour dummy device 80x25
i915 0000:00:02.0: MDEV: Unregistering
intel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14
BUG: kernel NULL pointer dereference, address: 0000000000000150
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6
Hardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022
RIP: 0010:__lock_acquire+0x5e2/0x1f90
Code: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0
RSP: 0018:ffff9f770274f948 EFLAGS: 00010046
RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000
R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000
FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/44c0e07e3972e3f2609d69ad873d4f342f8a68ec
- https://git.kernel.org/stable/c/704f3384f322b40ba24d958473edfb1c9750c8fd
- https://git.kernel.org/stable/c/af90f8b36d78544433a48a3eda6a5faeafacd0a1
- https://git.kernel.org/stable/c/f5a9bbf962e2c4b1d9addbfaf16d7ffcc2f63bde
- https://git.kernel.org/stable/c/ffa83fba2a2ce8010eb106c779378cb3013362c7
Closed vulnerabilities
Modified: 2025-08-19
BDU:2023-00495
Уязвимость модуля mod_proxy_ajp веб-сервера Apache HTTP Server, позволяющая нарушителю отправить скрытый HTTP-запрос (атака типа HTTP Request Smuggling)
Modified: 2025-08-19
BDU:2023-00496
Уязвимость модуля mod_proxy веб-сервера Apache HTTP Server, позволяющая нарушителю выполнять атаки с разделением ответов HTTP
Modified: 2025-08-19
BDU:2023-01105
Уязвимость модуля mod_dav веб-сервера Apache HTTP Server, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-13
CVE-2006-20001
A carefully crafted If: request header can cause a memory read, or write of a single zero byte, in a pool (heap) memory location beyond the header value sent. This could cause the process to crash. This issue affects Apache HTTP Server 2.4.54 and earlier.
Modified: 2025-04-04
CVE-2022-36760
Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server allows an attacker to smuggle requests to the AJP server it forwards requests to. This issue affects Apache HTTP Server Apache HTTP Server 2.4 version 2.4.54 and prior versions.
Modified: 2025-04-04
CVE-2022-37436
Prior to Apache HTTP Server 2.4.55, a malicious backend can cause the response headers to be truncated early, resulting in some headers being incorporated into the response body. If the later headers have any security purpose, they will not be interpreted by the client.
Closed bugs
Отключённый a2dismod модуль отключается даже после a2enmod
Заменить /var/lock на /run/lock в tmpfiles.conf
