ALT-PU-2024-4843-28
Package kernel-image-rpi-un updated to version 6.1.77-alt1 for branch p10 in task 344147.
Closed vulnerabilities
Modified: 2025-01-29
BDU:2022-05657
Уязвимость функции vmw_cmd_res_check драйвера vmwgfx (drivers/gpu/vmxgfx/vmxgfx_execbuf.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2022-05658
Уязвимость функции vmw_execbuf_tie_context драйвера vmwgfx (drivers/gpu/vmxgfx/vmxgfx_execbuf.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2024-06-07
BDU:2022-07339
Уязвимость драйвера файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2022-07509
Уязвимость подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ и повысить свои привилегии
Modified: 2024-09-24
BDU:2023-00164
Уязвимость функции ksmbd_decode_ntlmssp_auth_blob модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-00358
Уязвимость функции qdisc_graft (net/sched/sch_api.c) подсистемы управления трафиком ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2024-09-30
BDU:2023-00361
Уязвимость функций gru_set_context_option(), gru_fault() и gru_handle_user_call_os() драйвера SGI GRU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-08-19
BDU:2023-00378
Уязвимость функции atm_tc_enqueue() подсистемы приоритизации отправки сетевых пакетов (net/sched/sch_atm.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-00379
Уязвимость функции cbq_classify() подсистемы приоритизации отправки сетевых пакетов (net/sched/sch_cbq.c) ядра операционной системы 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-08-19
BDU:2023-00644
Уязвимость драйвера DVB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-08-19
BDU:2023-00645
Уязвимость драйвера DVB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-09-13
BDU:2023-00747
Уязвимость драйвера drivers/hid/hid-bigbenff.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2023-00749
Уязвимость функции ib_prctl_set() ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации.
Modified: 2024-01-09
BDU:2023-01112
Уязвимость функции ntfs_trim_fs() компонента fs/ntfs3/bitmap.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-01-09
BDU:2023-01122
Уязвимость функции run_unpack() компонента fs/ntfs3/run.c ядра операционных систем Linux, позволяющая нарушителю вызвать оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2023-01129
Уязвимость механизма MPLS (Multiprotocol Label Switching) ядра операционных систем 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-02-24
BDU:2023-01209
Уязвимость функций module_gzip_decompress() и module_xz_decompress() в модуле kernel/module/decompress.c подсистемы загрузки модулей ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2023-01218
Уязвимость функции ene_remove() (drivers/media/rc/ene_ir.c) драйвера инфракрасного приемника\передатчика ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-12-24
BDU:2023-01278
Уязвимость функции parse_lease_state() (fs/ksmbd/oplock.c) подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-01280
Уязвимость функции _pick_next_task_rt() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-01281
Уязвимость функции brcmf_get_assoc_ies() драйвера drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-12-06
BDU:2023-01292
Уязвимость функции afu_mmio_region_get_by_offset (drivers/fpga/dfl-afu-region.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2023-01571
Уязвимость функции tcf_exts_exec() фильтра индексирования системы контроля трафика tcindex ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-01572
Уязвимость функции stat() подсистемы OverlayFS ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-03-19
BDU:2023-01734
Уязвимость функции ntfs_read_mft() в модуле fs/ntfs3/inode.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-19
BDU:2023-01745
Уязвимость функции mi_enum_attr() в модуле fs/ntfs3/record.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-19
BDU:2023-01746
Уязвимость функции ntfs_read_mft() в модуле fs/ntfs3/inode.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-01780
Уязвимость функции xirc2ps_detach() драйвера сетевого адаптера Xircom 16-bit PCMCIA (PC-card) операционных систем Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2025-03-19
BDU:2023-01793
Уязвимость функции io_file_bitmap_get() (io_uring/filetable.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-08-14
BDU:2023-01795
Уязвимость сервера NFS (Network File System) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-01799
Уязвимость файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2023-02097
Уязвимость реализации протокола TLS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02163
Уязвимость функции btsdio_remove() модуля drivers\bluetooth\btsdio.c драйвера Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02165
Уязвимость фильтра индексирования системы контроля трафика tcindex (net/sched/cls_tcindex.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-02407
Уязвимость функции perf_group_detach() утилиты perf ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-02515
Уязвимость функции do_prlimit() ядра операционных систем Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-30
BDU:2023-02532
Уязвимость функции _copy_from_user() в модуле lib/usercopy.c ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2024-01-09
BDU:2023-02580
Уязвимость реализации протокола IPv6 RPL ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02605
Уязвимость функции qfq_change_class() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-02-27
BDU:2023-02624
Уязвимость реализации сетевого протокола NET/ROM ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных.
Modified: 2025-08-19
BDU:2023-02625
Уязвимость функции nf_tables_commit() в модуле net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных или повысить свои привилегии в системе и выполнить произвольный код
Modified: 2024-11-11
BDU:2023-02740
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2023-09-05
BDU:2023-02741
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю перехватить действующий сеанс
Modified: 2024-11-11
BDU:2023-02742
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-11
BDU:2023-02744
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-18
BDU:2023-02746
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2023-02747
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-11
BDU:2023-02749
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю оказать влияние на целостность, доступность и конфиденциальность защищаемой информации и выполнить произвольный код
Modified: 2024-11-11
BDU:2023-02750
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2023-09-05
BDU:2023-02751
Уязвимость функции rcu_barrier() модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии и выполнить произвольный код
Modified: 2024-04-27
BDU:2023-02995
Уязвимость функции ntfs_set_ea() в модуле fs/ntfs3/xattr.c драйвера файловой системы ntfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03172
Уязвимость функции r592_remove() в модуле drivers/memstick/host/r592.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-02-27
BDU:2023-03444
Уязвимость функции rkvdec_remove() в модуле drivers/staging/media/rkvdec/rkvdec.c драйвера Rockchip Video Decoder ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-08-19
BDU:2023-03498
Уязвимость функции fl_set_geneve_opt() в модуле net/sched/cls_flower.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии.
Modified: 2025-02-27
BDU:2023-03501
Уязвимость функции renesas_usb3_remove() в модуле drivers/usb/gadget/udc/renesas_usb3.c драйвера USB устройств Renesas ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-02-27
BDU:2023-03502
Уязвимость cedrus_remove() в модуле drivers/staging/media/sunxi/cedrus/cedrus.c драйвера Allwinner sunXi ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-02-06
BDU:2023-03584
Уязвимость подсистемы управления памятью StackRot ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03677
Уязвимость подсистемы Netfilter ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-30
BDU:2023-03721
Уязвимость драйвера IPVLAN ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-03778
Уязвимость функции nft_byteorder_eval() в модуле net/netfilter/nft_byteorder.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-09
BDU:2023-03785
Уязвимость функции backtrack_insn() в модуле kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-04-27
BDU:2023-03947
Уязвимость функции nft_chain_lookup_byid() в модуле net/netfilter/nf_tables_api.c подсистемы фильтрации пакетов netfilter ядра операционной системы Linux, позволяющая нарушителю повысить привилегии и оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-02-27
BDU:2023-03951
Уязвимость функции ksmbd_smb2_check_message() в модуле fs/smb/server/smb2misc.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-02-27
BDU:2023-03952
Уязвимость функции ksmbd_conn_handler_loop() в модуле fs/smb/server/connection.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-02-27
BDU:2023-03953
Уязвимость функции ksmbd_verify_smb_message() в модуле fs/smb/server/smb_common.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-02-27
BDU:2023-03954
Уязвимость функции ksmbd_conn_handler_loop() в модуле fs/ksmbd/connection.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2026-04-09
BDU:2023-03955
Уязвимость функции session_user() в модуле fs/ksmbd/smb2pdu.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-02-27
BDU:2023-03956
Уязвимость функции deassemble_neg_contexts() в модуле fs/smb/server/smb2pdu.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-02-27
BDU:2023-03957
Уязвимость функции smb2_find_context_vals() в модуле fs/ksmbd/oplock.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2024-04-27
BDU:2023-03961
Уязвимость функции nft_immediate_destroy() в модуле net/netfilter/nft_immediate.c подсистемы Netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных.
Modified: 2025-08-19
BDU:2023-04269
Уязвимость функции qfq_change_agg() в модуле net/sched/sch_qfq.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии в системе
Modified: 2025-08-19
BDU:2023-04270
Уязвимость функции fw_set_parms() в модуле net/sched/cls_fw.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии
Modified: 2025-08-19
BDU:2023-04466
Уязвимость функции nft_pipapo_remove() в модуле net/netfilter/nft_set_pipapo.c подсистемы netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-02-06
BDU:2023-04651
Уязвимость функции nf_tables_delrule() в модуле /net/netfilter/nf_tables_api.c сетевого экрана netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-06
BDU:2023-04653
Уязвимость функции nft_immediate_deactivate() в модуле net/netfilter/nft_immediate.c сетевого экрана netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
Modified: 2025-02-06
BDU:2023-04657
Уязвимость сетевого экрана netfilter ядра операционной системы Linux в функции nf_tables_newrule(), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-01-09
BDU:2023-04742
Уязвимость функции ksmbd_smb2_check_message ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-01-09
BDU:2023-04743
Уязвимость модуля ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-04770
Уязвимость функций l2cap_sock_release (net/bluetooth/l2cap_sock.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие.
Modified: 2024-05-27
BDU:2023-05115
Уязвимость модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-02-06
BDU:2023-05369
Уязвимость компонента net/sched: cls_fw ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-02-06
BDU:2023-05388
Уязвимость функции hfsc_change_class() в модуле net/sched/sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-08-19
BDU:2023-05389
Уязвимость функции unix_stream_sendpage() в модуле net/unix/af_unix.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2026-01-20
BDU:2023-05390
Уязвимость функции u32_init_knode() в модуле net/sched/cls_u32.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-02-06
BDU:2023-05391
Уязвимость функции route4_change() в модуле net/sched/cls_route.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2024-11-11
BDU:2023-05783
Уязвимость функции qfq_dequeue() в модуле net/sched/sch_plug.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-08-19
BDU:2023-06160
Уязвимость модуля net/netfilter/ipset/ip_set_hash_netportnet.c. ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-02-06
BDU:2023-06163
Уязвимость функций nft_flush_table(), nf_tables_delchain(), nf_tables_newrule(), nf_tables_delrule(), __nft_release_table() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2024-11-11
BDU:2023-06336
Уязвимость драйвера системы хранения данных Ceph (net/ceph/messenger_v2.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2025-12-08
BDU:2023-06347
Уязвимость функции smb3_fs_context_parse_param() компонента fs/smb/client ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2023-06750
Уязвимость функции nvmet_tcp_free_crypto файла drivers/nvme/target/tcp.c подсистемы NVMe-oF/TCP ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии или выполнить произвольный код
Modified: 2025-08-19
BDU:2023-06999
Уязвимость функции igb_set_rx_buffer_len() в модуле drivers/net/ethernet/intel/igb/igb_main.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-08-19
BDU:2023-07316
Уязвимость функции __perf_read_group_add() модуля kernel/events/core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-01-31
BDU:2023-07976
Уязвимость функции nf_conntrack_dccp_packet() модуля net/netfilter/nf_conntrack_proto_dccp.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-08-19
BDU:2023-08958
Уязвимость функции nft_pipapo_walk() в модуле net/netfilter/nft_set_pipapo.c подсистемы Netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии в системе
Modified: 2025-08-19
BDU:2023-09022
Уязвимость функции igmp_start_timer() в модуле net/ipv4/igmp.c реализации протокола IGMP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии в системе
Modified: 2025-12-08
BDU:2023-09024
Уязвимость функции __nvmet_req_complete() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-08
BDU:2023-09026
Уязвимость функции nvmet_tcp_build_pdu_iovec() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-00674
Уязвимость функции tls_sw_sendmsg_splice (/net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-11
BDU:2024-00738
Уязвимость функции xenvif_get_requests() кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-19
BDU:2024-01186
Уязвимость функции nft_setelem_catchall_deactivate() в модуле net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии
Modified: 2026-04-21
BDU:2024-01187
Уязвимость функции nft_verdict_init() в модуле net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации и повысить свои привилегии
Modified: 2026-01-20
BDU:2024-01590
Уязвимость функции f2fs_rename() компонента f2fs ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-10-24
BDU:2024-01606
Уязвимость функции ksmbd_tcp_new_connection() модуля fs/smb/server/transport_tcp.c реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-09
BDU:2024-01629
Уязвимость функций smb2_get_ksmbd_tcon() и smb2_check_user_session() ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-12-05
BDU:2024-01667
Уязвимость функции of_syscon_register драйвера MFD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01669
Уязвимость функции kv_parse_power_table компонента PM Driver ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-10-24
BDU:2024-01670
Уязвимость функции ksmbd_decode_ntlmssp_auth_blob() модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-11-11
BDU:2024-01676
Уязвимость функции init_smb2_rsp_hdr() модуля ksmbd ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
Modified: 2025-02-11
BDU:2024-01694
Уязвимость функции user_sdma_txadd драйвера Infiniband ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2024-01695
Уязвимость функции radeon_crtc_init драйвера видеокарт AMD Radeon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-01756
Уязвимость функции rds_rdma_cm_event_handler_cmn компонента rds ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-06
BDU:2024-01765
Уязвимость функции vlan_dev_hard_header компонента team ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-14
BDU:2024-01766
Уязвимость функции memblock_free_late компонента ima ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-01783
Уязвимость в функциях br_handle_frame_finish() и deliver_clone() сетевой компоненты ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-06
BDU:2024-01804
Уязвимость функции netfs_rreq_unlock_folios() файловой системы netfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-06
BDU:2024-01805
Уязвимость функции __skb_flow_dissect() сетевой компоненты ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-10-14
BDU:2024-01829
Уязвимость в функции sii902x_init() драйвера Silicon Image sii902x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-01833
Уязвимость функции omap8250_remove() в модуле drivers/tty/serial/8250/8250_omap.c драйвера последовательного интерфейса 8250 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код
Modified: 2025-10-24
BDU:2024-01834
Уязвимость функции vgic_its_check_cache() в модуле arch/arm64/kvm/vgic/vgic-its.c подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-01835
Уязвимость функции of_pwm_single_xlate() в модуле drivers/pwm/core.c драйвера устройств PWM (ШИМ, широтно-импульсной модуляции) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01837
Уязвимость функции thunderx_ocx_com_threaded_isr() в модуле drivers/edac/thunderx_edac.c драйвера EDAC (Error Detection and Correction) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-01838
Уязвимость функции pvr2_context_disconnect() в модуле drivers/media/usb/pvrusb2/pvrusb2-context.c драйвера Hauppauge WinTV-PVR USB2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2024-01842
Уязвимость функции rmnet_fill_info() в модуле drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c реализации протокола MAP (Multiplexing and Aggregation Protocol) драйвера сетевых карт Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-10
BDU:2024-01843
Уязвимость функции imx_uart_stop_tx() в модуле drivers/tty/serial/imx.c драйвера последовательных устройств Motorolla IMX ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-01844
Уязвимость функции bpf_tracing_prog_attach() в модуле kernel/bpf/syscall.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01848
Уязвимость функции gfs2_rgrp_dump() в модуле fs/gfs2/rgrp.c файловой системы gfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-01849
Уязвимость функции efivarfs_reconfigure() в модуле fs/efivarfs/super.c файловой системы EFI Variable Filesystem ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-01851
Уязвимость функции bpf_map_put() в модуле kernel/bpf/syscall.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-09
BDU:2024-01852
Уязвимость функции dlpar_memory_remove_by_index() драйвера управления памятью powerpc pseries ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-04
BDU:2024-01858
Уязвимость драйвера MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-01860
Уязвимость функции nvmet_tcp_build_pdu_iovec() в модуле drivers/nvme/target/tcp.c драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-01862
Уязвимость реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность данных
Modified: 2024-11-19
BDU:2024-01865
Уязвимость функции check_stack_write_fixed_off() в модуле kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации
Modified: 2026-01-20
BDU:2024-01866
Уязвимость функции adjust_ptr_min_max_vals() в модуле kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2024-01867
Уязвимость функции unpack_profile() в модуле security/apparmor/policy_unpack.c модуля безопасности AppArmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-01878
Уязвимость функции sock_orphan() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-01924
Уязвимость функции build_insn() модуля arch/loongarch/net/bpf_jit.c компонента BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-01932
Уязвимость функции kmem_cache_destroy библиотеки lib/list_debug.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-01933
Уязвимость функции mdev_unregister_parent библиотеки mdpy.ko ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-01935
Уязвимость функции drm_bridge_get_edid компонента meson ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-01936
Уязвимость функции BUG() компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-01937
Уязвимость функции secs.epc_page компонента sgx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-01938
Уязвимость функции nilfs_gccache_submit_read_data компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-01940
Уязвимость функции cifs_demultiplex_thread() компонента cifs ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2024-01981
Уязвимость функции __smc_diag_dump() в модуле net/smc/smc_diag.c реализации протокола SMC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03616
Уязвимость драйвера Intel Hardware Feedback Interface ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-03650
Уязвимость функции ipv6_mc_down() в модуле net/ipv6/mcast.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-03651
Уязвимость функции __ip6_tnl_rcv() в модуле net/ipv6/ip6_tunnel.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-03652
Уязвимость функции ip6_tnl_parse_tlv_enc_lim() в модуле net/ipv6/ip6_tunnel.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-03653
Уязвимость функции __sock_xmit() в модуле drivers/block/nbd.c драйвера nbd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-03655
Уязвимость функции can_map_frag() в модуле net/ipv4/tcp.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-03657
Уязвимость функции fscache_put_cache() в модуле fs/netfs/fscache_cache.c файловой системы netfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03658
Уязвимость функции bio_first_folio() в модуле include/linux/bio.h подсистемы управления блочными устройствами ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03659
Уязвимость функции llc_conn_handler() в модуле net/llc/llc_conn.c реализации протокола LLC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-03660
Уязвимость функции llc_ui_sendmsg() в модуле net/llc/af_llc.c реализации протокола LLC2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-03661
Уязвимость функции create_snapshot() в модуле fs/btrfs/ioctl.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-03704
Уязвимость функции __f2fs_setxattr() в модуле fs/f2fs/xattr.c файловой системы f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-29
BDU:2024-03705
Уязвимость функции binder_alloc_free_page() в модуле drivers/android/binder_alloc.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-03706
Уязвимость функции uio_open() в модуле drivers/uio/uio.c драйвера uio ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-03940
Уязвимость функции aqc111_rx_fixup() драйвера адаптера Aquantia AQtion USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2024-04132
Уязвимость функции blkpg_do_ioctl() в модуле block/ioctl.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-02-27
BDU:2024-04138
Уязвимость функции vfio_ap_mdev_filter_matrix() драйвера криптографического устройства платформы IBM S/390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04139
Уязвимость функции reqsk_queue_alloc() реализации протокола TCP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-11
BDU:2024-04146
Уязвимость функции ksmbd_nl_policy() реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-04147
Уязвимость функции iwl_dbg_tlv_override_trig_node() драйвера адаптеров беспроводной связи Intel iwlwifi ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-04576
Уязвимость функции cifs_debug_data_proc_show() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-07
BDU:2024-04579
Уязвимость функции unix_stream_recv_urg() реализации сокетов AF_UNIX ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-12
BDU:2024-04588
Уязвимость функции f2fs_read_multi_pages() файловой системы f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-10
BDU:2024-06074
Уязвимость функции svc_tcp_listen_data_ready() реализации протокола RPC (Remote Procedure Call) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2024-10-04
BDU:2024-06622
Уязвимость компонента hci_qca ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-04
BDU:2024-06623
Уязвимость компонента efi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-04
BDU:2024-06624
Уязвимость компонента sched/core ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-04
BDU:2024-06643
Уязвимость компонента fastrpc ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-04
BDU:2024-06644
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-04
BDU:2024-06645
Уязвимость функции pci_get_domain_bus_and_slot ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
BDU:2024-06646
Уязвимость компонента net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-04
BDU:2024-06647
Уязвимость компонента dpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06855
Уязвимость функции ieee80211_tx_ba_session_handle_start() в компоненте mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06856
Уязвимость компонента idxd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06905
Уязвимость компонента drm/amdgpu/vkms ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06906
Уязвимость компонента drm/amdgpu ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-09
BDU:2024-06907
Уязвимость ядра операционной системы Linux, связанная с неправильным побитовым смещением целого числа, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06908
Уязвимость функций fc_lport_ptp_setup() fc_lport_ptp_setup(), fc_rport_create(), fc_rport_create(), fc_rport_create() ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06909
Уязвимость функции smb_inherit_dacl() ядра операционной системы Linux, связанная с записью за границами буфера, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06910
Уязвимость компонента drm/amd/display ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06911
Уязвимость функции opal_powercap_init() компонента arch/powerpc/platforms/powernv/opal-powercap.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06912
Уязвимость компонента dtSearch ядра операционной системы Linux, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-06927
Уязвимость компонента net/wireless/nl80211.c ядра операционной системы Linux, связанная с неправильным ограничением потребления энергии, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06931
Уязвимость компонента drivers/media/test-drivers/vidtv/vidtv_psi.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06978
Уязвимость функции компонента ALSA ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-22
BDU:2024-06981
Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06983
Уязвимость компонента fs/pstore/platform.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-22
BDU:2024-06984
Уязвимость компонента drivers/gpu/drm/bridge/ite-it66121.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06986
Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-12
BDU:2024-06987
Уязвимость компонента drivers/clk/mediatek/clk-mt7629.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07440
Уязвимость компонента qgroup ядра операционной системы Linux, связанная с ошибками управления ресурсами, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-07442
Уязвимость компонента drm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07443
Уязвимость компонента io_uring ядра операционной системы 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: 2025-05-06
BDU:2024-07455
Уязвимость компонента nfsd ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07456
Уязвимость компонента iommu ядра операционной системы Linux, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07476
Уязвимость компонента af9035 ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-26
BDU:2024-07478
Уязвимость компонента nommu ядра операционной системы Linux, связанная с ошибками освобождения памяти, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-18
BDU:2024-07587
Уязвимость компонента qcom-geni-serial ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность и доступность защищаемой информации
Modified: 2024-10-11
BDU:2024-07589
Уязвимость компонента arm64/mm ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07590
Уязвимость компонента iommu/arm-smmu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07591
Уязвимость компонента iommu/arm-smmu-v3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07592
Уязвимость компонента storvsc ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07593
Уязвимость компонента sof-nau8825 ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07594
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07597
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2024-10-18
BDU:2024-07600
Уязвимость функции drv_disable_wq() драйвера idxd ядра операционной системы 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-11
BDU:2024-07631
Уязвимость компонента tty ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-11
BDU:2024-07632
Уязвимость компонента gadgetfs ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании
Modified: 2025-02-06
BDU:2024-07646
Уязвимость функции nft_chain_filter компонента Netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07798
Уязвимость функции sony_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07799
Уязвимость функции __ip{,6}_append_data() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-07800
Уязвимость функции __smsc75xx_read_reg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07818
Уязвимость компонента sockmap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-07819
Уязвимость компонента RDMA/srp ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-02-25
BDU:2024-07820
Уязвимость компонента nfc ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации в системе
Modified: 2025-10-24
BDU:2024-07821
Уязвимость компонента hub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07822
Уязвимость компонента perf/x86/lbr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07823
Уязвимость компонента powermate ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2024-07825
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-07826
Уязвимость компонента platform/x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-07827
Уязвимость компонента ipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07828
Уязвимость функции __dma_entry_alloc_check_leak() компонента dma-debug ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07829
Уязвимость компонента sun6i ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации в системе
Modified: 2025-08-19
BDU:2024-07830
Уязвимость компонента RDMA/siw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07831
Уязвимость компонента sun6i ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2024-07832
Уязвимость компонента ravb ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-09-05
BDU:2024-07833
Уязвимость компонента nci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07834
Уязвимость компонента x86/alternatives ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07835
Уязвимость компонента amdtee ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-10-24
BDU:2024-07836
Уязвимость компонента ring-buffer ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации в системе
Modified: 2025-10-24
BDU:2024-07837
Уязвимость компонента pm80xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07838
Уязвимость компонента powerpc/47x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07840
Уязвимость компонента erofs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07841
Уязвимость компонента iommu/arm-smmu-v3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-07842
Уязвимость компонента mctp ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-10-24
BDU:2024-07843
Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-02-25
BDU:2024-07845
Уязвимость компонента erofs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-07846
Уязвимость компонента vaddr-test ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07847
Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-07848
Уязвимость компонента ipoib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07849
Уязвимость компонента iommu/vt-d ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07850
Уязвимость компонента hci_codec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07851
Уязвимость компонента pinctrl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-07852
Уязвимость компонента ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07853
Уязвимость компонента mvm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2024-08163
Уязвимость компонента vivid ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-01-29
BDU:2024-08374
Уязвимость компонента ca8210 ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-01-29
BDU:2024-08401
Уязвимость компонента mtk-jpeg ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2024-08402
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-08403
Уязвимость компонента mhi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-08413
Уязвимость компонента mhi ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации
Modified: 2025-03-21
BDU:2024-09030
Уязвимость функции scsi_host_busy() компонента drivers/scsi/scsi_error.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09032
Уязвимость функции stdev_release() компонента drivers/pci/switch/switchtec.c ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-09453
Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09454
Уязвимость функции rcu_scheduler_active() компонента net/sunrpc/xprtmultipath.c ядра операционной системы Linux, связанная с переполнением буфера на стеке, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09455
Уязвимость функции kasprintf() компонента arch/powerpc/mm/init-common.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-09707
Уязвимость компонентов io_uring/af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09722
Уязвимость компонента tpd12s015 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09754
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09821
Уязвимость компонента pipe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09830
Уязвимость компонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09831
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09834
Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09862
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09863
Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-08-19
BDU:2024-09919
Уязвимость компонента LPIT ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2024-09921
Уязвимость компонента of ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09923
Уязвимость компонента scarlett2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09925
Уязвимость в компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09927
Уязвимость компонентов powerpc/imc-pmu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09930
Уязвимость компонента scarlett2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09931
Уязвимость компонента mvpp2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09943
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10027
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10028
Уязвимость компонента calipso ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10029
Уязвимость компонента ACPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10030
Уязвимость компонента scarlett2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10031
Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10032
Уязвимость компонента powerpc/powernv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10033
Уязвимость компонентов powerpc/powernv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10185
Уязвимость функции vhost_vdpa_probe() компонента vhost-vdpa ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10197
Уязвимость компонента dwc2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10202
Уязвимость компонента hwmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10203
Уязвимость компонента padata ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-12-03
BDU:2024-10204
Уязвимость компонента cp2112 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10205
Уязвимость компонентов cxl/mem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10206
Уязвимость функции bttv_remove() в модуле drivers/media/pci/bt8xx/bttv-driver.c компонента bttv ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-12-03
BDU:2024-10207
Уязвимость компонента hsr ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-12-03
BDU:2024-10208
Уязвимость компонента hisi ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2024-12-03
BDU:2024-10209
Уязвимость компонентов drm/bridge ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10210
Уязвимость функции cxl_region_attach() компонентов cxl/region ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-03
BDU:2024-10211
Уязвимость компонента blk-mq ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10230
Уязвимость компонента mux ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10253
Уязвимость компонентов locking/ww_mutex/test ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10254
Уязвимость компонента Input ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-10-24
BDU:2024-10255
Уязвимость компонентов perf/core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10256
Уязвимость компонента atl1c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10257
Уязвимость компонента btusb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10258
Уязвимость компонента tipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10265
Уязвимость компонента llc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10268
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10269
Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10363
Уязвимость компонентов powerpc/64s/interrupt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10364
Уязвимость компонентов drm/amdgpu/fence ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10366
Уязвимость компонента mmc_spi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-10367
Уязвимость компонентов sched/psi ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-09-05
BDU:2024-10368
Уязвимость функций sock_map_{close,destroy,unhash}() ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2024-10374
Уязвимость компонента fbdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10398
Уязвимость функции qcom_llcc_probe() компонента llcc ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10403
Уязвимость функций clk_mt6765_apmixed_probe(), clk_mt6765_top_probe() и clk_mt6765_ifr_probe() компонента clk-mt6765 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10408
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10410
Уязвимость компонентов IB/mlx5 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-01-10
BDU:2024-10412
Уязвимость функции sprintf() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10413
Уязвимость компонента hisi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10414
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10416
Уязвимость функции wmi_char_open() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10417
Уязвимость драйвера компонента imon (drivers/media/rc/imon.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10458
Уязвимость драйвера графического процессора radeon (drivers/gpu/drm/radeon/evergreen.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10461
Уязвимость функции gsm_cleanup_mux() драйвера TTY (drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-10
BDU:2024-10462
Уязвимость функций mtk_topckgen_init(), mtk_infrasys_init_early() и mtk_infrasys_init() компонента clk-mt6797 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10489
Уязвимость компонента ibmvfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10490
Уязвимость компонентов drm/panel/panel-tpo-tpg110 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10492
Уязвимость компонента hisi_sas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10493
Уязвимость компонента tcpm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10496
Уязвимость компонента clk-mt6779 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10499
Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10500
Уязвимость компонентов RDMA/irdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10501
Уязвимость компонентов xfrm/compat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10502
Уязвимость компонентов IB/hfi1 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-10-24
BDU:2024-10503
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10504
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10505
Уязвимость компонента jfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10506
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10507
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-10-24
BDU:2024-10508
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10514
Уязвимость компонента sim ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10515
Уязвимость компонентов drm/amd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-10516
Уязвимость компонентов drm/amd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10520
Уязвимость компонента clk-mt7629-eth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10522
Уязвимость компонента dev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-24
BDU:2024-10523
Уязвимость компонента clk-mt2701 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-29
BDU:2024-10660
Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю выполнить атаку методом подмены
Modified: 2025-03-21
BDU:2025-00163
Уязвимость функции jfs_mount() в модуле fs/jfs/jfs_mount.c файловой системы jfs ядра операционной системы Linux в , позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-01-19
BDU:2025-00164
Уязвимость функции amdgpu_cs_pass1() в модуле drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-00165
Уязвимость функции bcm_release() в модуле net/can/bcm.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-00782
Уязвимость компонента net/mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-00783
Уязвимость компонента drivers/gpu/drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01928
Уязвимость компонентов platform/surface ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01974
Уязвимость компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2025-01975
Уязвимость компонента nfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-18
BDU:2025-01984
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-03449
Уязвимость компонентов drm/i915 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-08-19
BDU:2025-03817
Уязвимость функции do_fp_load() модуля arch/powerpc/lib/sstep.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03818
Уязвимость функции rt2x00lib_disable_radio() модуля drivers/net/wireless/ralink/rt2x00/rt2x00dev.c - драйвера поддержки адаптеров беспроводной связи Ralink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-14
BDU:2025-03819
Уязвимость функции rkisp1_csi_disable() модуля drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-01-20
BDU:2025-03820
Уязвимость функции mana_poll_tx_cq() модуля drivers/net/ethernet/microsoft/mana/mana_en.c - драйвера поддержки сетевых адаптеров Ethernet Microsoft ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2025-03821
Уязвимость функции section_nr_to_pfn() модуля include/linux/mmzone.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-05-06
BDU:2025-03938
Уязвимость компонента sc16is7xx.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04351
Уязвимость функции mlx5_cmd_init() модуля drivers/net/ethernet/mellanox/mlx5/core/cmd.c - драйвера поддержки сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04356
Уязвимость функции pcs_set_mux() модуля drivers/pinctrl/pinctrl-single.c - драйвера поддержки контроллеров выводов PINCTRL ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04357
Уязвимость функции ifcvf_probe() модуля drivers/vdpa/ifcvf/ifcvf_main.c - драйвера поддежки устройств vDPA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04447
Уязвимость функции ice_add_adv_recipe() модуля drivers/net/ethernet/intel/ice/ice_switch.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-04448
Уязвимость функции cxl_region_decode_reset() модуля drivers/cxl/core/region.c - драйвера поддержки устройств CXL (Compute Express Link) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-04450
Уязвимость функции ceph_handle_caps() модуля fs/ceph/caps.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04548
Уязвимость функции trans_stat_show() модуля drivers/devfreq/devfreq.c - драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-04570
Уязвимость функции dev_pm_skip_resume() модуля drivers/base/power/main.c - драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04678
Уязвимость функции cifs_compose_mount_options() модуля fs/smb/client/cifsproto.h поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-02-17
BDU:2025-05358
Уязвимость ядра операционной системы Linux, связанная с некорректной зачисткой или освобождением ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-05359
Уязвимость ядра операционной системы Linux, связанная с копированием буфера без проверки размера входных данных, позволяющая нарушителю повысить свои привилегии
BDU:2025-05360
Уязвимость функции ieee802154_hdr_peek_addrs() ядра операционной системы Linux, позволяющая нарушителю оказать влияние на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-05361
Уязвимость функции kzalloc() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-05362
Уязвимость ядра операционной системы Linux, связанная c использованием памяти после её освобождения, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-05363
Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-05364
Уязвимость функции nilfs_ioctl_wrap_copy() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-05365
Уязвимость функции alloc_precpu() ядра операционной системы Linux, позволяющая нарушителю выполнить отказ в обслуживании
Modified: 2026-02-17
BDU:2025-05366
Уязвимость функции ish_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06020
Уязвимость модуля drivers/platform/chrome/cros_ec_chardev.c ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2026-02-17
BDU:2025-06025
Уязвимость функции nft_payload() модуля net/netfilter /nft_payload.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06212
Уязвимость компонента ovl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06216
Уязвимость функции vmci_dispatch_dgs() ядра операционной системы 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-06235
Уязвимость функции sof_ipc4_priority_mask_dfs_write() компонента AsoC ядра операционной системы 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-06240
Уязвимость функций fscache_is_acquire_pending() и fscache_wake_pending_volume() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06241
Уязвимость модуля drivers/block/ublk_drv.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06243
Уязвимость функций arch_simulate_insn() и arch_prepare_kprobe() ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06253
Уязвимость функций update_parent_subparts_cpumask() и spin_lock_irq() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06257
Уязвимость функции lru_gen_migrate_mm() компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06259
Уязвимость функции hv_balloon_debugfs_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06260
Уязвимость функции fib_metrics_match() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06262
Уязвимость функции fec_enet_free_buffers() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06265
Уязвимость функции init_ISA_irqs() и make_8259A_irq() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06268
Уязвимость функции simulation_jalr() ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06272
Уязвимость модуля arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06276
Уязвимость функции debugfs_add_domain_dir() ядра операционной системы 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-06291
Уязвимость компонента gfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06292
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06293
Уязвимость компонента fbdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06294
Уязвимость компонентов mm/uffd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06295
Уязвимость компонента fpga ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06296
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06297
Уязвимость компонента zmap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06298
Уязвимость компонента property.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06299
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06300
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю повысить привилегии
Modified: 2026-01-20
BDU:2025-06301
Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06302
Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06303
Уязвимость компонентов EDAC/highbank ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06304
Уязвимость компонента reset ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06305
Уязвимость компонентов mm/hugetlb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06308
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06309
Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06310
Уязвимость компонента nvmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06311
Уязвимость компонентов drm/i915 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06313
Уязвимость компонентов drm/i915 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06315
Уязвимость компонента Squashfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06317
Уязвимость компонентов mm/MADV_COLLAPSE ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06330
Уязвимость функции create_hist_field() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06331
Уязвимость функции dwmac5_handle_dma_err() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-06332
Уязвимость функции local_cleanup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06333
Уязвимость функции enetc_tx_onestep_tstamp() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06334
Уязвимость функции hci_get_random_address() компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании2
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-06345
Уязвимость функции hci_cmd_sync_queue(), hci_le_terminate_big() или hci_le_big_terminate() ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06353
Уязвимость функции rfcomm_sock_connect() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании1
Modified: 2026-02-17
BDU:2025-06355
Уязвимость функции tegra_dma_terminate_all() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06357
Уязвимость функции pt_core_execute_cmd() и pt_core_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-06363
Уязвимость функции ovl_copy_up_tmpfile() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06378
Уязвимость функции i915_perf_open_ioctl(), i915_perf_add_config_ioctl() и i915_perf_remove_config_ioctl() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-02-17
BDU:2025-06396
Уязвимость функции j1939_session_deactivate() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06576
Уязвимость функции nf_tables_dump_setelem() модуля net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06765
Уязвимость функции smb2_open() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06766
Уязвимость модуля drivers/md/dm-crypt.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06767
Уязвимость модулей net/ipv4/ip_gre.c и net/ipv6/ip6_gre.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06769
Уязвимость модуля drivers/thunderbolt/debugfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06784
Уязвимость функции ucsi_connector_change() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06785
Уязвимость функции amdtee_open_session() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06788
Уязвимость функции hci_cmd_sync_clear() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06806
Уязвимость функции EXPORT_SYMBOL_GPL(), iscsi_session_teardown() и iscsi_sw_tcp_session_destroy() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06835
Уязвимость модуля drivers/usb/gadget/function/u_audio.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06836
Уязвимость модуля drivers/usb/typec/tcpm/tcpm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06837
Уязвимость модуля drivers/usb/dwc2/platform.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06838
Уязвимость функции security_sb_delete() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06840
Уязвимость функции hci_init_stage_sync() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07410
Уязвимость функции ath11k_wmi_pdev_dfs_radar_detected_event() модуля drivers/net/wireless/ath/ath11k/wmi.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07474
Уязвимость функции ath9k_htc_txstatus() модуля drivers/net/wireless/ath/ath9k/htc_drv_txrx.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07475
Уязвимость функции diNewExt() модуля fs/jfs/jfs_imap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07476
Уязвимость функции dbAllocBits() модуля fs/jfs/jfs_dmap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07477
Уязвимость функции dtSplitRoot() модуля fs/jfs/jfs_dtree.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07478
Уязвимость функции dbAdjTree() модуля fs/jfs/jfs_dmap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07481
Уязвимость функции aq_ptp_ring_alloc() модуля drivers/net/ethernet/aquantia/atlantic/aq_ptp.c - драйвера поддержки сетевых адаптеров Ethernet с чипсетом aQuantia Atlantic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07483
Уязвимость функции ath11k_wmi_gtk_offload_status_event() модуля drivers/net/wireless/ath/ath11k/wmi.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07498
Уязвимость функции hci_dma_irq_handler() модуля drivers/i3c/master/mipi-i3c-hci/dma.c - драйвера поддержки I3C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07505
Уязвимость функции nbd_dev_remove() модуля drivers/block/nbd.c - драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07508
Уязвимость функции smb20_oplock_break_ack() модуля fs/ksmbd/smb2pdu.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07509
Уязвимость функции set_cluster_dirty() модуля fs/f2fs/compress.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-07510
Уязвимость функции __poke_user() модуля arch/s390/kernel/ptrace.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-07532
Уязвимость функции rng_get_data() модуля drivers/char/hw_random/core.c - драйвера поддержки алфавитно-цифровых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07713
Уязвимость компонента s390/dasd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-07714
Уязвимость компонента net/smc ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
BDU:2025-07716
Уязвимость функции usb_get_bos_descriptor() компонента drivers/usb/core/config.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
Modified: 2025-10-24
BDU:2025-08236
Уязвимость функции wfx_upload_ap_templates() модуля drivers/net/wireless/silabs/wfx/sta.c - драйвера поддержки адаптеров беспроводной связи Silicon Laboratories ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-08237
Уязвимость функции drm_mode_page_flip_ioctls модуля drivers/gpu/drm/drm_plane.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
BDU:2025-08238
Уязвимость функции shmem_fetch_notification() модуля drivers/firmware/arm_scmi/common.h - драйвера поддержки прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-07
BDU:2025-08239
Уязвимость функции scomp_acomp_comp_decomp() модуля crypto/scompress.c криптографической подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-10239
Уязвимость функции retract_page_tables() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-10256
Уязвимость функций rcu_read_lock_held(), BPF_CALL_4() and BPF_CALL_2() (kernel/bpf/helpers.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-10562
Уязвимость функции mvneta_ethtool_get_strings() модуля drivers/net/ethernet/marvell/mvneta.c - драйвера поддержки сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-10563
Уязвимость функции amdgpu_dm_i2c_xfer() модуля drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-10564
Уязвимость функции spi_unregister_controller() модуля drivers/spi/spi.c - драйвера поддержки устройств SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-10566
Уязвимость функции ovs_meter_cmd_set() модуля net/openvswitch/meter.c поддержки маршрутизаторов Open vSwitch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-10571
Уязвимость функции vcc_probe() модуля drivers/tty/vcc.c - драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-10573
Уязвимость функции hidpp_probe() модуля drivers/hid/hid-logitech-hidpp.c - драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12410
Уязвимость функции cpu_map_update_elem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-22
BDU:2025-12411
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после ее освобождения, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12412
Уязвимость функции skb_partial_csum_set ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12413
Уязвимость ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12417
Уязвимость компонента net ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12418
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12419
Уязвимость функции device_add ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12420
Уязвимость функции cas_init_one ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-12483
Уязвимость компонента drm/panel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12787
Уязвимость функций virtio_mmio_release_dev() и virtio_mmio_probe() в модуле drivers/virtio/virtio_mmio.c поддержки шины virtio ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-12788
Уязвимость модуля crypto/xts.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12790
Уязвимость функции xfrmi_xmit() в модуле net/xfrm/xfrm_interface_core.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-12793
Уязвимость функции put_pasid_state() в модуле drivers/iommu/amd/iommu_v2.c драйвера IOMMU ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-09
BDU:2025-12805
Уязвимость функции pdc_iodc_print() в модуле arch/parisc/kernel/firmware.c ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12822
Уязвимость функции ext4_get_group_info() в модуле fs/ext4/ext4.h файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12825
Уязвимость модуля drivers/infiniband/hw/hfi1/chip.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12857
Уязвимость функции udf_merge_extents() в модуле fs/udf/inode.c файловой системы OSTA-UDF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-09
BDU:2025-12865
Уязвимость функции ublk_ctrl_start_dev() в модуле drivers/block/ublk_drv.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-12892
Уязвимость функции qed_mcp_trace_dump() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12900
Уязвимость функции mnt_get_count() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12901
Уязвимость модуля drivers/scsi/mpt3sas/mpt3sas_base.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12902
Уязвимость функции __block_write_full_page() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12904
Уязвимость функции dev_set_name() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12906
Уязвимость функции devfreq_dev_release() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12907
Уязвимость модуля include/media/v4l2-mem2mem.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12908
Уязвимость функции tipc_link_proto_rcv() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12937
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным
BDU:2025-12938
Уязвимость компонента LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12939
Уязвимость компонента nvme-fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12941
Уязвимость компонента sdm845-db845c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12942
Уязвимость компонента mediatek c ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-02-17
BDU:2025-12974
Уязвимость модулей drivers/net/ethernet/intel/ice/ice_eswitch.c и drivers/net/ethernet/intel/ice/ice_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12975
Уязвимость функции pm_runtime_resume_and_get() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12976
Уязвимость функции qrtr_recvmsg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12977
Уязвимость функции pcie_link_state() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12982
Уязвимость модуля drivers/scsi/ses.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12984
Уязвимость функции fwnet_finish_incoming_packet() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12985
Уязвимость функции vlan_get_protocol_and_depth() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12986
Уязвимость функции imx_dsp_rproc() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13351
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13352
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13361
Уязвимость компонентов drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13366
Уязвимость компонентов cpu/hotplug ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-14112
Уязвимость функции ttm_lru_bulk_move_del ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14126
Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14127
Уязвимость компонента perf_output_begin ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
BDU:2025-14128
Уязвимость компонента net ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14129
Уязвимость ядра операционных систем Linux, связанная с разыменованием нулевого указателя, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2025-14130
Уязвимость функции rtnl_lock ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14131
Уязвимость функции iavf_remove ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14227
Уязвимость функции __genradix_iter_peek() модуля include/linux/generic-radix-tree.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14263
Уязвимость функции intel_engines_init() модуля drivers/gpu/drm/i915/gt/intel_engine_cs.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14281
Уязвимость функции tcf_ct_handle_fragments() модуля net/sched/act_ct.c ядра операционной системы Linux, позволяющая удаленному нарушителю оказать воздействие на доступность защищаемой информации
BDU:2025-14287
Уязвимость функции ramoops_init_przs() модуля fs/pstore/ram.c поддержки постоянного хранилища ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14288
Уязвимость функции alloc_flex_gd() модуля fs/ext4/resize.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14291
Уязвимость функции aio_ring_mremap() модуля fs/aio.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14297
Уязвимость функции wilc_wlan_init() модуля drivers/net/wireless/microchip/wilc1000/wlan.c драйвера поддержки адаптеров беспроводной связи Microchip ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-14573
Уязвимость функции tipc_connect() модуля net/tipc/socket.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14584
Уязвимость функции binder_update_page_range() модуля drivers/android/binder_alloc.c драйвера поддержки связи с Android ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14586
Уязвимость функции call_usermodehelper_exec() модуля kernel/umh.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14587
Уязвимость функции nilfs_ioctl_set_alloc_range() модуля fs/nilfs2/ioctl.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14589
Уязвимость функции ceph_netfs_issue_read() модуля fs/ceph/addr.c поддержки распределенной файловой системы Ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14591
Уязвимость функции devfreq_monitor() модуля drivers/devfreq/devfreq.c драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14592
Уязвимость функции virtblk_probe() модуля drivers/block/virtio_blk.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14602
Уязвимость функции rnbd_srv_get_full_path() модуля drivers/block/rnbd/rnbd-srv.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2025-15029
Уязвимость функции nft_limit_eval() модуля net/netfilter/nft_limit.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-15038
Уязвимость функции kvm_arch_vcpu_ioctl_set_fpu() модуля arch/s390/kvm/kvm-s390.c поддержки платформы S390 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
BDU:2025-15042
Уязвимость функции __tracing_map_insert() модуля kernel/trace/tracing_map.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15084
Уязвимость функции time_travel_update_time() модуля arch/um/kernel/time.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15304
Уязвимость функции optlen() модуля net/netfilter/nft_exthdr.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-15324
Уязвимость функции kalmia_send_init_packet() модуля drivers/net/usb/kalmia.c - драйвера поддержки сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15325
Уязвимость функции mptcp_update_infinite_map() модуля net/mptcp/protocol.c реализации протокола MPTCP ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15326
Уязвимость функции set_flicker() модуля drivers/media/usb/gspca/cpia1.c - драйвера поддержки мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15327
Уязвимость функции bond_setup_by_slave() модуля drivers/net/bonding/bond_main.c - драйвера поддержки сетевых адаптеров ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15328
Уязвимость функции rpc_clnt_remove_pipedir() модуля net/sunrpc/clnt.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15329
Уязвимость функции i2c_dev_irq_from_resources() модуля drivers/i2c/i2c-core.h - драйвера поддержки I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15330
Уязвимость функции ath11k_htt_pktlog() модуля drivers/net/wireless/ath/ath11k/dp_rx.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15341
Уязвимость функции ipvlan_addr_lookup() модуля drivers/net/ipvlan/ipvlan_core.c - драйвера поддержки сетевых адаптеров ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15342
Уязвимость функции otx2vf_remove() модуля drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c - драйвера поддержки сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15349
Уязвимость функции dbAllocCtl() модуля fs/jfs/jfs_dmap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2025-15383
Уязвимость функции sock_recv_drops() модуля net/socket.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15384
Уязвимость функции extent_fiemap() модуля fs/btrfs/extent_io.c поддержки файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15387
Уязвимость функции dbMount() модуля fs/jfs/jfs_dmap.c поддержки файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15436
Уязвимость функции amdgpu_vram_mgr_fini() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15439
Уязвимость функции hci_dat_v1_init() модуля drivers/i3c/master/mipi-i3c-hci/dat_v1.c драйвера поддержки I3C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16229
Уязвимость функции ses_intf_remove() компонента scsi ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2026-02-17
BDU:2025-16231
Уязвимость функции iwl_write_to_user_buf() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16232
Уязвимость модуля drivers/infiniband/core/cma.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16237
Уязвимость функции null_timeout_rq() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16238
Уязвимость функции ath11k_ahb_fw_resources_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16240
Уязвимость функций freezer_apply_state(), freezer_change_state() в модуле kernel/cgroup/legacy_freezer.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-16258
Уязвимость функции nft_chain_lookup_byid() в модуле net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-16269
Уязвимость функции hci_suspend_notifier() в модуле net/bluetooth/hci_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-11
BDU:2025-16277
Уязвимость функции amdgpu_dm_fini() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16278
Уязвимость функции virtnet_open() компонента virtio_net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-16279
Уязвимость функции mvpp2_ethtool_get_rxnfc() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16287
Уязвимость модуля drivers/clk/tegra/clk-tegra124-emc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16298
Уязвимость модуля net/core/skbuff.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-16310
Уязвимость функции dbAllocDmapLev() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16317
Уязвимость модуля arch/powerpc/kernel/rtas_flash.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-01167
Уязвимость функции device_add() модуля drivers/base/core.c драйвера шинных устройства ядра операционной системы 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-01331
Уязвимость функции ses_enclosure_data_process() модуля drivers/scsi/ses.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01398
Уязвимость функции xgene_hwmon_probe() модуля drivers/hwmon/xgene-hwmon.c драйвера мониторинга оборудования ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01409
Уязвимость функции lookup_inline_extent_backref() модуля fs/btrfs/extent-tree.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01417
Уязвимость функции usb_shark_probe() модуля drivers/media/radio/radio-shark.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01453
Уязвимость функции gfs2_show_options() модуля fs/gfs2/super.c файловой системы GFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01462
Уязвимость функции status_resync() модуля drivers/md/md.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01496
Уязвимость функции radeon_atombios_fini() модуля drivers/gpu/drm/radeon/radeon_device.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01499
Уязвимость функции jfs_link() модуля fs/jfs/namei.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01502
Уязвимость функции bcmgenet_desc_rx() модуля drivers/net/ethernet/broadcom/genet/bcmgenet.c драйвера сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01503
Уязвимость функции usbnet_probe () модуля drivers/net/usb/usbnet.c драйвера сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01505
Уязвимость функции null_init_tag_set() модуля drivers/block/null_blk/main.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01525
Уязвимость функции brcmf_c_preinit_dcmds() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01526
Уязвимость функции ieee80211_probe_client() модуля net/mac80211/cfg.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01528
Уязвимость функции bnxt_get_nvram_directory() модуля drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c драйвера сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01529
Уязвимость функции lio_target_nacl_info_show() модуля drivers/target/iscsi/iscsi_target_configfs.c драйвера TCM ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01530
Уязвимость функции mt7601u_rx_next_seg_len() модуля drivers/net/wireless/mediatek/mt7601u/dma.c драйвера адаптеров беспроводной связи Mediatek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01537
Уязвимость функции acpi_processor_get_lpi_info() модуля drivers/acpi/processor_idle.c драйвера ACPI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01565
Уязвимость функции nfsd_splice_actor() модуля fs/nfsd/vfs.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01599
Уязвимость функции drain_obj_stock() модуля mm/memcontrol.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01626
Уязвимость функций rtw89_core_register_hw(), rtw89_pci_probe() модуля drivers/net/wireless/realtek/rtw89/core.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01633
Уязвимость функции gfx_v9_0_hw_fini() модуля drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02039
Уязвимость функции avs_dsp_receive_rx() модуля sound/soc/intel/avs/ipc.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02040
Уязвимость функции dma_resv_get_fences() модуля drivers/dma-buf/dma-resv.c 2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02041
Уязвимость функции ovl_permission() модуля fs/overlayfs/inode.c файловой системы Overlayfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2026-02043
Уязвимость функции vdpasim_free() модуля drivers/vdpa/vdpa_sim/vdpa_sim.c драйвера устройств vDPA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02044
Уязвимость функции generate_lfp_data_ptrs() модуля drivers/gpu/drm/i915/display/intel_bios.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02045
Уязвимость функции __do_sys_set_mempolicy_home_node() модуля mm/mempolicy.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02047
Уязвимость функции nested_svm_vmexit() модуля arch/x86/kvm/svm/nested.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02051
Уязвимость функции wilc_netdev_ifc_init() модуля drivers/net/wireless/microchip/wilc1000/netdev.c драйвера адаптеров беспроводной связи Microchip ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02053
Уязвимость функции r5l_log_flush_endio() модуля drivers/md/raid5-cache.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2026-02054
Уязвимость функции dev_add_physical_location() модуля drivers/base/physical_location.c драйвера шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02056
Уязвимость функции nouveau_connector_create() модуля drivers/gpu/drm/nouveau/nouveau_connector.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02057
Уязвимость функции mlx5_cmd_err_trace() модуля drivers/net/ethernet/mellanox/mlx5/core/cmd.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02174
Уязвимость функции igb_alloc_q_vector() в модуле drivers/net/ethernet/intel/igb/igb_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02175
Уязвимость функции brcmf_c_preinit_dcmds() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02176
Уязвимость драйвера dvb-core ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02185
Уязвимость функции acpi_ds_call_control_method() в модуле drivers/acpi/acpica/dsmethod.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-03
BDU:2026-02186
Уязвимость функции btsdio_remove() в модуле drivers/bluetooth/btsdio.c драйвера устройств Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02187
Уязвимость функции igb_io_error_detected() в модуле drivers/net/ethernet/intel/igb/igb_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02188
Уязвимость функции load_balance() в модуле kernel/sched/fair.c поддержки системы учета ресурсов ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02189
Уязвимость функции ieee80211_rx_h_action() в модуле net/mac80211/rx.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02190
Уязвимость функции lpfc_wr_object() в модуле drivers/scsi/lpfc/lpfc_sli.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02191
Уязвимость функции get_max_inline_xattr_value_size() в модуле fs/ext4/inline.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02200
Уязвимость функции l2cap_le_command_rej() в модуле net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02203
Уязвимость функции qla2x00_terminate_rport_io() в модуле drivers/scsi/qla2xxx/qla_attr.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02260
Уязвимость функции pick_file() в модуле fs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02261
Уязвимость функции brcmf_get_assoc_ies() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02263
Уязвимость функции dbMount() в модуле fs/jfs/jfs_dmap.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02264
Уязвимость функции dbMount() в модуле fs/jfs/jfs_dmap.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02265
Уязвимость функции crypt_message() в модуле fs/cifs/smb2ops.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02267
Уязвимость функции dbg_create_files() в модуле drivers/usb/chipidea/debug.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02270
Уязвимость функции destroy() в модуле drivers/md/dm-cache-target.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02272
Уязвимость функции devm_rtc_allocate_device() в модуле drivers/rtc/class.c драйвера Real Time Clock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02274
Уязвимость функции dm_resume() в модуле drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02276
Уязвимость функции ip6mr_cache_report() модуля net/ipv6/ip6mr.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02277
Уязвимость функции ismt_access() модуля drivers/i2c/busses/i2c-ismt.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02278
Уязвимость функции iwl_pcie_irq_rx_msix_handler() модуля drivers/net/wireless/intel/iwlwifi/pcie/rx.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02282
Уязвимость функции l2cap_disconnect_rsp() модуля net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02284
Уязвимость функции iommu_debugfs_add() в модуле arch/powerpc/kernel/iommu.c поддержки платформы PowerPC ядра операционной системы 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-02344
Уязвимость функции vmx_init() в модуле arch/x86/kvm/vmx/vmx.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02357
Уязвимость функции ext4_clu_mapped() в модуле fs/ext4/extents.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02358
Уязвимость функции btrfs_drop_extents() в модуле fs/btrfs/file.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02363
Уязвимость функции amdgpu_bo_validate_size() в модуле drivers/gpu/drm/amd/amdgpu/amdgpu_object.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02368
Уязвимость функции ext2_setsize() модуля fs/ext2/inode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02370
Уязвимость функции alpine_msix_init_domains() модуля drivers/irqchip/irq-alpine-msi.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02371
Уязвимость функции tsi148_dma_list_add() модуля drivers/staging/vme_user/vme_tsi148.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02373
Уязвимость функции mtk_vdec_worker() модуля drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02374
Уязвимость функции qm_get_qos_value() модуля drivers/crypto/hisilicon/qm.c драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02437
Уязвимость функции nvme_trace_bio_complete() модуля [модуль] ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2026-02438
Уязвимость функции tcindex_set_parms() модуля net/sched/cls_tcindex.c подсистемы управления трафиком net/sched ядра операционной системы 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-02442
Уязвимость функций mtype_add_cidr() и mtype_del_cidr() модуля net/netfilter/ipset/ip_set_hash_gen.h компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02443
Уязвимость функции io_init() модуля drivers/mtd/ubi/build.c драйвера памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02513
Уязвимость функции ena_com_comp_status_to_errno() модуля drivers/net/ethernet/amazon/ena/ena_com.c драйвера сетевых адаптеров Ethernet Amazon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02514
Уязвимость функции sctp_sendmsg_to_asoc() модуля net/sctp/socket.c реализации протокола SCTP (Stream Control Transmission Protocol) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02515
Уязвимость функции recovery_request_write() модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02516
Уязвимость функции skb_segment() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02517
Уязвимость функции seqiv_aead_encrypt_complete2() модуля crypto/seqiv.c криптографической подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02518
Уязвимость функции ath9k_hif_usb_rx_stream() модуля drivers/net/wireless/ath/ath9k/hif_usb.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, вызвать отказ в обслуживании
BDU:2026-02519
Уязвимость функции vub300_probe() модуля drivers/mmc/host/vub300.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02520
Уязвимость функции rtsx_pci_sdmmc_drv_probe() модуля drivers/mmc/host/rtsx_pci_sdmmc.c драйвера карт MMC/SD/SDIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02521
Уязвимость функции vkms_init() модуля drivers/gpu/drm/vkms/vkms_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02522
Уязвимость функции radeon_acpi_vfct_bios() модуля drivers/gpu/drm/radeon/radeon_bios.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02523
Уязвимость функции nlm_unlock_files() модуля fs/lockd/svcsubs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02524
Уязвимость функции msc313_rtc_probe() модуля drivers/rtc/rtc-msc313.c драйвера Real Time Clock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02525
Уязвимость функции get_dvsec_vendor0() модуля drivers/misc/ocxl/config.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02526
Уязвимость функции do_floppy_init() модуля drivers/block/floppy.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03245
Уязвимость функции smb2_set_ea() модуля fs/smb/server/smb2pdu.c поддержки сервера SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03266
Уязвимость функции brcmf_pcie_init_ringbuffers() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03267
Уязвимость функции dx_probe() модуля fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03268
Уязвимость функции diUnmount() модуля fs/jfs/jfs_imap.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03271
Уязвимость функции panfrost_ioctl_create_bo() модуля drivers/gpu/drm/panfrost/panfrost_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03277
Уязвимость функций prepare_threshold_block(), amd_threshold_interrupt(), mce_threshold_create_device() модуля arch/x86/kernel/cpu/mce/amd.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03279
Уязвимость функции do_get_hw_stats() модуля drivers/infiniband/hw/mlx5/counters.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03280
Уязвимость функции mwifiex_handle_uap_rx_forward() модуля drivers/net/wireless/marvell/mwifiex/uap_txrx.c драйвера адаптеров беспроводной связи Marvell ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03281
Уязвимость функции smc_clc_send_confirm_accept() модуля net/smc/smc_clc.c реализации CLC-рукопожатия TCP-сокета подсистемы SMC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03309
Уязвимость функции f2fs_decompress_cluster() модуля fs/f2fs/compress.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
BDU:2026-03311
Уязвимость функции udf_file_write_iter() модуля fs/udf/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03315
Уязвимость функции hwsim_cloned_frame_received_nl() модуля drivers/net/wireless/virtual/mac80211_hwsim.c драйвера адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03316
Уязвимость функции ntfs_list_ea() модуля fs/ntfs3/xattr.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03323
Уязвимость функции do_rbd_add() модуля drivers/block/rbd.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03324
Уязвимость функции __nilfs_mark_inode_dirty() модуля fs/nilfs2/inode.c файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03326
Уязвимость функций run_lwt_bpf(), bpf_lwt_xmit_reroute() модуля net/core/lwt_bpf.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03328
Уязвимость модуля drivers/scsi/mpi3mr/mpi3mr_fw.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03329
Уязвимость функции smb2_compound_op() модуля fs/smb/client/smb2inode.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03330
Уязвимость функций hci_link_keys_clear(), hci_smp_ltks_clear(), hci_smp_irks_clear(), hci_blocked_keys_clear() модуля net/bluetooth/hci_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03331
Уязвимость функции mtk_drm_bind() модуля drivers/gpu/drm/mediatek/mtk_drm_drv.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Mediatek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03338
Уязвимость модуля drivers/acpi/acpica/psopcode.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03339
Уязвимость функции mlx5e_skb_fifo_pop() и mlx5e_ptp_handle_ts_cqe() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03340
Уязвимость функции xsk_diag_fill() модуля net/xdp/xsk_diag.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03341
Уязвимость функции allocate_mr_list() модуля fs/cifs/smbdirect.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03342
Уязвимость функций free_irq_cpu_rmap(), irq_cpu_rmap_release(), irq_cpu_rmap_add() модуля lib/cpu_rmap.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03343
Уязвимость функции blk_mq_mark_tag_wait() модуля block/blk-mq.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03347
Уязвимость функций imx_dsp_rproc_stop(), imx_dsp_rproc_vq_work() модуля drivers/remoteproc/imx_dsp_rproc.c драйвера подсистемы удаленного процессора ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03348
Уязвимость функции qla_nvme_ls_req() модуля drivers/scsi/qla2xxx/qla_nvme.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03349
Уязвимость функции il4965_setup_deferred_work() модуля drivers/net/wireless/intel/iwlegacy/4965-mac.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03350
Уязвимость функции ext4_validate_block_bitmap() модуля fs/ext4/balloc.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03354
Уязвимость модуля drivers/soundwire/qcom.c драйвера SoundWire ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03355
Уязвимость функции buffer_prepare() модуля drivers/media/pci/cx23885/cx23885-core.c драйвера мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03356
Уязвимость функции find_tosym() модуля scripts/mod/modpost.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03357
Уязвимость функции ksmbd_tree_conn_lookup() модуля fs/ksmbd/mgmt/tree_connect.c подсистемы SMB-сервера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03359
Уязвимость функции bio_poll() модуля block/blk-core.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03360
Уязвимость функции raid10_sync_request() модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03361
Уязвимость функции nfsd4_copy() модуля fs/nfsd/nfs4proc.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03459
Уязвимость функции ext4_load_journal() в модуле fs/ext4/super.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03561
Уязвимость функции get_timer_irq() в модуле arch/loongarch/kernel/time.c поддержки архитектуры LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03584
Уязвимость функции cpufreq_policy_alloc() модуля drivers/cpufreq/cpufreq.c драйвера масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03587
Уязвимость функции mt7921_mcu_parse_response() модуля drivers/net/wireless/mediatek/mt76/mt7921/mcu.c драйвера адаптеров беспроводной связи Mediatek ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03588
Уязвимость функции __f2fs_submit_merged_write() модуля fs/f2fs/data.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03589
Уязвимость функций mlx5e_tc_esw_init(), mlx5e_tc_esw_cleanup() модуля drivers/net/ethernet/mellanox/mlx5/core/en_tc.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03591
Уязвимость функции fch_misc_setup() модуля drivers/acpi/acpi_apd.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03636
Уязвимость функции pass_establish() модуля drivers/infiniband/hw/cxgb4/cm.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03640
Уязвимость функции svm_range_vram_node_new() модуля drivers/gpu/drm/amd/amdkfd/kfd_svm.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03642
Уязвимость функции mlx5e_fs_tt_redirect_any_create() модуля drivers/net/ethernet/mellanox/mlx5/core/en/fs_tt_redirect.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03643
Уязвимость функции bcm_tx_setup() модуля net/can/bcm.c подсистемы шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03645
Уязвимость функции brcmf_netdev_start_xmit() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03646
Уязвимость функции ov2740_init_controls() модуля drivers/media/i2c/ov2740.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03647
Уязвимость функции xlnx_add_cb_for_notify_event() модуля drivers/soc/xilinx/xlnx_event_manager.c драйвера SOC (система на кристалле) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03737
Уязвимость функций tcpci_register_port() и tcpci_unregister_port() модуля drivers/usb/typec/tcpm/tcpci.c драйвера диспетчера контроллеров портов USB TypeC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03739
Уязвимость функции lookup_rec() модуля kernel/trace/ftrace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03744
Уязвимость функции __remove_instance() модуля kernel/trace/trace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03745
Уязвимость функции loop_queue_rq() модуля drivers/block/loop.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03747
Уязвимость функции bnxt_ethtool_init() модуля drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c драйвера поддержки сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03754
Уязвимость функции mpi3mr_get_all_tgt_info() модуля drivers/scsi/mpi3mr/mpi3mr_app.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03768
Уязвимость функции lbs_init_adapter() модуля drivers/net/wireless/marvell/libertas/main.c драйвера адаптеров беспроводной связи Marvell ядра операционной системы 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-03777
Уязвимость функции p9_tag_alloc() модуля net/9p/client.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03778
Уязвимость функции fbcon_do_set_font() модуля drivers/video/fbdev/core/fbcon.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03794
Уязвимость функции init_amd() модуля arch/x86/lib/clear_page_64.S ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03795
Уязвимость функции iwl_dbgfs_fw_info_seq_next() модуля drivers/net/wireless/intel/iwlwifi/fw/debugfs.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03797
Уязвимость функции sctp_generate_iftsn() модуля net/sctp/stream_interleave.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03798
Уязвимость функции __fsl_mc_device_remove_if_not_in_mc() модуля drivers/bus/fsl-mc/dprc-driver.c драйвера шины fslmc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03799
Уязвимость функции dccp_error() модуля net/netfilter/nf_conntrack_proto_dccp.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03800
Уязвимость функции max_corrected_read_errors_store() модуля drivers/md/md.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03801
Уязвимость функции bdisp_probe() модуля drivers/media/platform/st/sti/bdisp/bdisp-v4l2.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03802
Уязвимость функции _rtw_join_timeout_handler() модуля drivers/staging/rtl8723bs/core/rtw_mlme.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03803
Уязвимость функции imxrt1050_clocks_probe() модуля drivers/clk/imx/clk-imxrt1050.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03804
Уязвимость функции hisi_inno_phy_probe() модуля drivers/phy/hisilicon/phy-hisi-inno-usb2.c драйвера PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03805
Уязвимость функции __smc_lgr_terminate() модуля net/smc/smc_core.c реализации семейства протоколов сокетов SMC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03806
Уязвимость функции ice_get_module_eeprom() модуля drivers/net/ethernet/intel/ice/ice_ethtool.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы 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-03816
Уязвимость функции vmbus_acpi_add() модуля drivers/hv/vmbus_drv.c драйвера гостевого режима Microsoft HyperV ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03817
Уязвимость функции nvme_tcp_get_address() модуля drivers/nvme/host/tcp.c драйвера NVME ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03818
Уязвимость функции __rcu_irq_enter_check_tick() модуля kernel/rcu/tree.c подсистемы синхронизации в многопоточных системах ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03824
Уязвимость функций qla4xxx_set_chap_entry() и qla4xxx_iface_set_param() модуля drivers/scsi/qla4xxx/ql4_os.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03827
Уязвимость функции fq_resize() модуля net/sched/sch_fq.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03830
Уязвимость функции __cpu_map_ring_cleanup() модуля kernel/bpf/cpumap.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03831
Уязвимость функции ath6kl_htc_pipe_rx_complete() модуля drivers/net/wireless/ath/ath6kl/htc_pipe.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03832
Уязвимость функции hisi_pcie_pmu_offline_cpu() модуля drivers/perf/hisilicon/hisi_pcie_pmu.c драйвера мониторинга производительности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03834
Уязвимость функции del_mtd_device() модуля drivers/mtd/mtdcore.c драйвера памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03835
Уязвимость функции mipid_spi_probe() модуля drivers/video/fbdev/omap/lcd_mipid.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03836
Уязвимость функции alloc_wbufs() модуля fs/ubifs/super.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03837
Уязвимость функции nvme_init_ctrl() модуля drivers/nvme/host/core.c драйвера NVME ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03839
Уязвимость функции mpfs_reset_unregister_adev() модуля drivers/clk/microchip/clk-mpfs.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03841
Уязвимость функции acpi_ut_copy_ipackage_to_ipackage() модуля drivers/acpi/acpica/utcopy.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03842
Уязвимость функции dlm_midcomms_commit_mhandle() модуля fs/dlm/midcomms.c поддержки распределенного менеджера блокировок ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03845
Уязвимость функции ath9k_hif_usb_alloc_tx_urbs() модуля drivers/net/wireless/ath/ath9k/hif_usb.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03846
Уязвимость функции tx_macro_put_dec_enum() модуля sound/soc/codecs/lpass-tx-macro.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03851
Уязвимость функции mlx5_esw_vport_disable() модуля drivers/net/ethernet/mellanox/mlx5/core/eswitch.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03852
Уязвимость функции intel_context_find_active_request() модуля drivers/gpu/drm/i915/gt/intel_context.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03853
Уязвимость функции drm_gem_shmem_mmap() модуля drivers/gpu/drm/drm_gem_shmem_helper.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03854
Уязвимость функции bitmap_ip_create() модуля net/netfilter/ipset/ip_set_bitmap_ip.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03855
Уязвимость функции do_feature_check_call() модуля drivers/firmware/xilinx/zynqmp.c драйвера прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03856
Уязвимость функции ndlc_remove() модуля drivers/nfc/st-nci/ndlc.c драйвера NFC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03857
Уязвимость функции __nvmet_req_complete() модуля drivers/nvme/target/core.c драйвера NVME ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03858
Уязвимость функции smsc75xx_rx_fixup() модуля drivers/net/usb/smsc75xx.c драйвера сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03859
Уязвимость функции cfusbl_device_notify() модуля net/caif/caif_usb.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03865
Уязвимость функции queue_oob() модуля net/unix/af_unix.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03882
Уязвимость функции lpuart_set_termios() модуля drivers/tty/serial/fsl_lpuart.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03889
Уязвимость функции imx8mn_clocks_probe() модуля drivers/clk/imx/clk-imx8mn.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03896
Уязвимость функции ubifs_sysfs_init() модуля fs/ubifs/sysfs.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03898
Уязвимость функции icc_node_destroy() модуля drivers/interconnect/core.c драйвера межсоединений ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03908
Уязвимость функции ntfs_lookup() модуля fs/ntfs3/namei.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03911
Уязвимость функции veth_convert_skb_to_xdp_buff() модуля drivers/net/veth.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03912
Уязвимость функции dp_display_remove() модуля drivers/gpu/drm/msm/dp/dp_display.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03914
Уязвимость функции gen11_compute_sseu_info() модуля drivers/gpu/drm/i915/gt/intel_sseu.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03919
Уязвимость функции topology_get_acpi_cpu_tag() модуля drivers/acpi/pptt.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03921
Уязвимость функции ocfs2_write_end_nolock() модуля fs/ocfs2/aops.c файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03923
Уязвимость функции rcu_scale_cleanup() модуля kernel/rcu/rcuscale.c подсистемы синхронизации в многопоточных системах ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03937
Уязвимость функции vxlan_init() модуля drivers/net/vxlan/vxlan_core.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03944
Уязвимость функции cfctrl_linkup_request() модуля net/caif/cfctrl.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03945
Уязвимость функции mdp5_plane_destroy_state() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03946
Уязвимость функции ep93xxfb_probe() модуля drivers/video/fbdev/ep93xx-fb.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03947
Уязвимость функции __do_trace_net_dev_start_xmit() модуля include/trace/events/net.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03948
Уязвимость функции fec_drv_remove() модуля drivers/net/ethernet/freescale/fec_main.c драйвера сетевых адаптеров Ethernet Freescale ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03949
Уязвимость функции hi846_init_controls() модуля drivers/media/i2c/hi846.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03950
Уязвимость функции dpu_writeback_init() модуля drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03952
Уязвимость функции ubi_resize_volume() модуля drivers/mtd/ubi/vmt.c драйвера памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03953
Уязвимость функции dmi_sysfs_register_handle() модуля drivers/firmware/dmi-sysfs.c драйвера прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03954
Уязвимость функции btrfs_reduce_alloc_profile() модуля fs/btrfs/block-group.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03955
Уязвимость функции storvsc_host_reset_handler() модуля drivers/scsi/storvsc_drv.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03956
Уязвимость функции mdp5_crtc_reset() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03957
Уязвимость функции watchdog_cdev_register() модуля drivers/watchdog/watchdog_dev.c поддержки сторожевого таймера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03958
Уязвимость функции fdp_nci_i2c_read_device_properties() модуля drivers/nfc/fdp/i2c.c драйвера NFC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03959
Уязвимость функции walk_stackframe() модуля arch/riscv/kernel/stacktrace.c подсистемы управления модулями платформы с архитектурой RISCV ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03960
Уязвимость функции svc_stop_kthreads() модуля net/sunrpc/svc.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03961
Уязвимость функции exynos_generic_icc_probe() модуля drivers/interconnect/samsung/exynos.c драйвера межсоединений ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03972
Уязвимость функции vp_vdpa_remove() модуля drivers/vdpa/virtio_pci/vp_vdpa.c драйвера устройств vDPA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03973
Уязвимость функции __mptcp_close_ssk() модуля net/mptcp/protocol.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03974
Уязвимость функций __mptcp_close_ssk() и mptcp_worker() модуля net/mptcp/protocol.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03980
Уязвимость функции nest_imc_event_init() модуля arch/powerpc/perf/imc-pmu.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04048
Уязвимость функции ov772x_probe() модуля drivers/media/i2c/ov772x.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04049
Уязвимость функции test_firmware_init() модуля lib/test_firmware.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04050
Уязвимость функции devm_clk_notifier_register() модуля drivers/clk/clk.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04051
Уязвимость функции amdgpu_amdkfd_gpuvm_import_dmabuf() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы 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-04057
Уязвимость функции init_bios_attributes() модуля drivers/platform/x86/dell/dell-wmi-sysman/sysman.c драйвера устройств X86 ядра операционной системы 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-04075
Уязвимость функции __bch_btree_node_alloc() модуля drivers/md/bcache/btree.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04076
Уязвимость функции prepare_trampoline() модуля arch/arm64/net/bpf_jit_comp.c поддержки сети на платформе ARM 64бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04077
Уязвимость функции iommu_group_alloc() модуля drivers/iommu/iommu.c драйвера IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04078
Уязвимость функции c4iw_fill_res_cm_id_entry() модуля drivers/infiniband/hw/cxgb4/restrack.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04080
Уязвимость функции aspeed_socinfo_init() модуля drivers/soc/aspeed/aspeed-socinfo.c драйвера SOC (система на кристалле) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04081
Уязвимость функции io_ring_exit_work() модуля io_uring/io_uring.c интерфейса асинхронного ввода/вывода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04082
Уязвимость функции vc4_hdmi_handle_hotplug() модуля drivers/gpu/drm/vc4/vc4_hdmi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04083
Уязвимость функции hi846_parse_dt() модуля drivers/media/i2c/hi846.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-04088
Уязвимость функции ntfs_fill_super() модуля fs/ntfs3/super.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04089
Уязвимость функции hpre_probe() модуля drivers/crypto/hisilicon/hpre/hpre_main.c драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04090
Уязвимость функции snd_ac97_mixer() модуля sound/pci/ac97/ac97_codec.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04092
Уязвимость функции intel_gvt_debugfs_add_vgpu() модуля drivers/gpu/drm/i915/gvt/debugfs.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04094
Уязвимость функции ieee80211_rx_mgmt_assoc_resp() модуля net/mac80211/mlme.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04104
Уязвимость функции nfsd4_decode_compound() модуля fs/nfsd/nfs4xdr.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04105
Уязвимость функции skb_copy_ubufs() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04106
Уязвимость функции rb_reset_cpu() модуля kernel/trace/ring_buffer.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-04107
Уязвимость функции wcd938x_mbhc_init() модуля sound/soc/codecs/wcd938x.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04109
Уязвимость функции nested_vmcb02_prepare_control() модуля arch/x86/kvm/svm/nested.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04110
Уязвимость функции iavf_set_channels() модуля drivers/net/ethernet/intel/iavf/iavf_ethtool.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-04111
Уязвимость функции bcm_qspi_probe() модуля drivers/spi/spi-bcm-qspi.c драйвера устройств SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04112
Уязвимость функции ice_eswitch_port_start_xmit() модуля drivers/net/ethernet/intel/ice/ice_eswitch.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании
BDU:2026-04113
Уязвимость функции blkcg_init_disk() модуля block/blk-cgroup.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04114
Уязвимость функции ext4_alloc_inode() модуля fs/ext4/super.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04117
Уязвимость функции s3c24xx_serial_getclk() модуля drivers/tty/serial/samsung_tty.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04118
Уязвимость функций hfsplus_cat_read_inode() и hfsplus_cat_write_inode() модуля fs/hfsplus/inode.c поддержки расширенной файловой системы Apple HFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04119
Уязвимость функции evlist__free_syscall_tp_fields() модуля tools/perf/builtin-trace.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04123
Уязвимость функции mtk_iommu_probe() модуля drivers/iommu/mtk_iommu.c драйвера IOMMU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04330
Уязвимость функции unmerge_and_remove_all_rmap_items() модуля mm/ksm.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04331
Уязвимость функции try_smi_init() модуля drivers/char/ipmi/ipmi_si_intf.c драйвера алфавитноцифровых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04332
Уязвимость функции platform_irqchip_probe() модуля drivers/irqchip/irqchip.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04334
Уязвимость функции dc_construct_ctx() модуля drivers/gpu/drm/amd/display/dc/core/dc.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04335
Уязвимость функции snd_ymfpci_memalloc() модуля sound/pci/ymfpci/ymfpci_main.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04336
Уязвимость функции rpi_ts_probe() модуля drivers/input/touchscreen/raspberrypi-ts.c драйвера сенсорного экрана ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04338
Уязвимость функции write_oob_to_regs() модуля drivers/mtd/nand/raw/brcmnand/brcmnand.c драйвера памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04339
Уязвимость функции mtk_drm_crtc_create() модуля drivers/gpu/drm/mediatek/mtk_drm_crtc.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04344
Уязвимость функции ks_wlan_set_encode_ext() модуля drivers/staging/ks7010/ks_wlan_net.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04382
Уязвимость функции hci_cs_disconnect() модуля net/bluetooth/hci_event.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04406
Уязвимость функции iavf_alloc_q_vectors() модуля drivers/net/ethernet/intel/iavf/iavf_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04411
Уязвимость функции davinci_cpufreq_probe() модуля drivers/cpufreq/davinci-cpufreq.c драйвера масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04412
Уязвимость функции sdma_v4_0_sw_fini() модуля drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04414
Уязвимость функции vti_tunnel_xmit() модуля net/ipv4/ip_vti.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04415
Уязвимость функции event_hist_trigger_parse() модуля kernel/trace/trace_events_hist.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04416
Уязвимость функции mlx5dr_cmd_create_reformat_ctx() модуля drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04417
Уязвимость функции spi_qup_remove() модуля drivers/spi/spi-qup.c драйвера устройств SPI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04418
Уязвимость функции imx_clk_scu_alloc_dev() модуля drivers/clk/imx/clk-scu.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04421
Уязвимость функции iwl_mvm_update_mcc() модуля drivers/net/wireless/intel/iwlwifi/mvm/nvm.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04422
Уязвимость функции otx2_remove() модуля drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c драйвера сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04423
Уязвимость функции mhi_init_mmio() модуля drivers/bus/mhi/host/init.c драйвера шины MHI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04424
Уязвимость функции iptunnel_pmtud_build_icmp() модуля net/ipv4/ip_tunnel_core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04425
Уязвимость функции bond_xmit_hash() модуля drivers/net/bonding/bond_main.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04426
Уязвимость функции nl80211_parse_mbssid_elems() модуля net/wireless/nl80211.c поддержки беспроводной связи ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04427
Уязвимость функции nl80211_parse_mbssid_elems() модуля net/wireless/nl80211.c поддержки беспроводной связи ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04428
Уязвимость функции nl80211_parse_mbssid_elems() модуля net/wireless/nl80211.c поддержки беспроводной связи ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04429
Уязвимость функции BPF_CALL_3() модуля net/core/filter.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04430
Уязвимость функции ubifs_release_folio() модуля fs/ubifs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04431
Уязвимость функции intel_get_crtc_new_encoder() модуля drivers/gpu/drm/i915/display/intel_display.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04432
Уязвимость функции zcdn_create() модуля drivers/s390/crypto/zcrypt_api.c драйвера криптографии на платформе S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04433
Уязвимость функции unregister_fprobe() модуля kernel/trace/fprobe.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04435
Уязвимость функции qrtr_endpoint_post() модуля net/qrtr/af_qrtr.c поддержки маршрутизаторов Qualcomm IPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04436
Уязвимость функции riscv_pmu_start() модуля drivers/perf/riscv_pmu.c драйвера мониторинга производительности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04437
Уязвимость функции sifive_gpio_probe() модуля drivers/gpio/gpio-sifive.c драйвера GPIO ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04438
Уязвимость функции device_add() модуля drivers/base/core.c драйвера шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04439
Уязвимость функции cifs_demultiplex_thread() модуля fs/smb/client/connect.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04441
Уязвимость функции qla24xx_issue_sa_replace_iocb() модуля drivers/scsi/qla2xxx/qla_edif.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04442
Уязвимость функции dm_integrity_init() модуля drivers/md/dm-integrity.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04470
Уязвимость функции intel_fbdev_set_suspend() модуля drivers/gpu/drm/i915/display/intel_fbdev.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04497
Уязвимость функции f2fs_fill_super() модуля fs/f2fs/super.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04517
Уязвимость функции dasd_eckd_init() модуля drivers/s390/block/dasd_eckd.c драйвера блочных устройств на платформе S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04550
Уязвимость функции ext4_mb_release_group_pa() модуля fs/ext4/mballoc.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04586
Уязвимость функции nilfs_segctor_thread() модуля fs/nilfs2/segment.c файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04587
Уязвимость функции cifs_readpage_worker() модуля fs/smb/client/file.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04588
Уязвимость функции __ocfs2_move_extent() модуля fs/ocfs2/move_extents.c файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04589
Уязвимость функции qla24xx_build_scsi_type_6_iocbs() модуля drivers/scsi/qla2xxx/qla_iocb.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04590
Уязвимость модуля drivers/usb/gadget/udc/pxa25x_udc.c драйвера гаджетов USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04591
Уязвимость функции pi_create_file() модуля kernel/printk/index.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04599
Уязвимость функции usb_debugfs_init() модуля drivers/usb/core/usb.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04604
Уязвимость функции amdgpu_ring_fini() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04606
Уязвимость функции fei_debugfs_add_attr() модуля kernel/fail_function.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04608
Уязвимость функции btrfs_cancel_balance() модуля fs/btrfs/volumes.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04609
Уязвимость функции ni_create_attr_list() модуля fs/ntfs3/frecord.c файловой системы NTFS 3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04610
Уязвимость функции uwrite() модуля scripts/recordmcount.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04611
Уязвимость функции radeon_cs_parser_init() модуля drivers/gpu/drm/radeon/radeon_cs.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04612
Уязвимость функции drm_client_modeset_probe() модуля drivers/gpu/drm/drm_client_modeset.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04613
Уязвимость функции vmballoon_debugfs_init() модуля drivers/misc/vmw_balloon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04614
Уязвимость функции ubifs_tmpfile() модуля fs/ubifs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04615
Уязвимость функции snd_hdac_regmap_sync() модуля sound/hda/hdac_regmap.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04616
Уязвимость функции btrfs_truncate_block() модуля fs/btrfs/inode.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04617
Уязвимость функции cifs_smb3_do_mount() модуля fs/smb/client/cifsfs.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04619
Уязвимость функции msm_dsi_host_init() модуля drivers/gpu/drm/msm/dsi/dsi_host.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04620
Уязвимость функции az6007_i2c_xfer() модуля drivers/media/usb/dvb-usb-v2/az6007.c драйвера мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04621
Уязвимость функции mac80211_hwsim_select_tx_link() модуля drivers/net/wireless/virtual/mac80211_hwsim.c драйвера адаптеров беспроводной связи ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04622
Уязвимость функции acpi_ds_init_aml_walk() модуля drivers/acpi/acpica/dswstate.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04623
Уязвимость функции pch_uart_exit_port() модуля drivers/tty/serial/pch_uart.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04624
Уязвимость функции qla24xx_bsg_request() модуля drivers/scsi/qla2xxx/qla_bsg.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04625
Уязвимость функции dw2102_i2c_transfer() модуля drivers/media/usb/dvb-usb/dw2102.c драйвера мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04626
Уязвимость функции swap_inode_boot_loader() модуля fs/ext4/ioctl.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04627
Уязвимость функции ext4_expand_extra_isize_ea() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04628
Уязвимость функции gpio_ir_recv_remove() модуля drivers/media/rc/gpio-ir-recv.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04629
Уязвимость функции ext4_xattr_inode_iget() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04630
Уязвимость функции build_avpair_blob() модуля fs/cifs/cifsencrypt.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04857
Уязвимость функции omap4_sram_init() модуля arch/arm/mach-omap2/omap4-common.c поддержки платформы ARM ядра операционной системы 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-04871
Уязвимость функции ila_xlat_nl_cmd_get_mapping() модуля net/ipv6/ila/ila_xlat.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05729
Уязвимость функции rb_end_commit() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-05733
Уязвимость функции usb_put_hcd() модуля drivers/usb/host/xhci-mtk.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05734
Уязвимость функции __dev_queue_xmit() модуля net/core/filter.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05738
Уязвимость функции cfg80211_sme_connect() модуля net/wireless/sme.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05739
Уязвимость функции tracing_err_log_open() модуля kernel/trace/trace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05740
Уязвимость функции serial8250_unregister_port() модуля drivers/tty/serial/8250/8250_core.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05758
Уязвимость функций psp_hdcp_initialize() и psp_dtm_initialize() в модуле drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05789
Уязвимость функции qed_iov_get_vf_info() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05790
Уязвимость функции xdp_umem_reg() компонента xsk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05793
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05794
Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05854
Уязвимость функции kfd_process_device_init_vm() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05857
Уязвимость функции ext4_fc_reserve_space() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05859
Уязвимость функции ext4_unlink() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05861
Уязвимость функции ioctl() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05863
Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05864
Уязвимость компонента octeontx2-vf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05865
Уязвимость ядра операционной системы Linux, связанная с разыменованием нулевого указателя, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05866
Уязвимость функции tcp_bpf_recvmsg_parser ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05867
Уязвимость функции amddrm_buddy_fini() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05868
Уязвимость компонента Wi-Fi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05869
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05870
Уязвимость функции bnxt_re() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05871
Уязвимость функции too_many_unix_fds() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05872
Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05875
Уязвимость функции fentry_run() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05876
Уязвимость компонента imx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05877
Уязвимость функции mwifiex_process_mgmt_packet() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05878
Уязвимость функции sendmsg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05879
Уязвимость функции op_release() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05880
Уязвимость функции follow_automount() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05881
Уязвимость функции dma_fence_wait() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05882
Уязвимость функции hci_conn_params() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05883
Уязвимость функции shared_cpu_map ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05884
Уязвимость функции ida_alloc ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-05885
Уязвимость функции vblank_nom() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05886
Уязвимость функции get_user_pages_fast ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05888
Уязвимость функции of_node_put() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05889
Уязвимость функции mlx5_ib_destroy_wq() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05890
Уязвимость функции in_atomic() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05891
Уязвимость функции run_bpf_prog() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05892
Уязвимость функции b15_dma_inv_range() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05893
Уязвимость функции ppr_get() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05894
Уязвимость функции irq_data_get_affinity_mask() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05895
Уязвимость функции debugfs_lookup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05896
Уязвимость функции ramfs_kill_sb() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05897
Уязвимость функции get_line_out_pfx() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05898
Уязвимость функции debugfs_lookup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05899
Уязвимость функции debugfs_lookup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05900
Уязвимость функции debugfs_lookup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05901
Уязвимость функции rcu_print_task_exp_stall() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05903
Уязвимость компонента HID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05904
Уязвимость функции tegra_xusb_padctl_get_usb3_companion() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05935
Уязвимость функции rdtgroup_mkdir() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05936
Уязвимость функции unregister_netdevice_many_notify() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05938
Уязвимость функции raw_get_next() ядра операционной системы 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-05957
Уязвимость функции init_mqueue_fs() модуля ipc/mqueue.c подсистемы межпроцессного взаимодействия IPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05958
Уязвимость функции init_mtd() модуля drivers/mtd/mtdcore.c драйвера памяти MTD ядра операционной системы 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-05971
Уязвимость функции arm_trbe_probe_cpuhp() модуля drivers/hwtracing/coresight/coresight-trbe.c драйвера трассировки HW ядра операционной системы 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-05976
Уязвимость функции vkms_release() модуля drivers/gpu/drm/vkms/vkms_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05977
Уязвимость функции padata_do_parallel() модуля kernel/padata.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05979
Уязвимость функции mt8183_mt6358_ts3a227_max98357_dev_probe() модуля sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c поддержки звука SoC ядра операционной системы 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-05984
Уязвимость функции wpcm450_aic_of_init() модуля drivers/irqchip/irq-wpcm450-aic.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05986
Уязвимость функции xfrm_update_ae_params() модуля net/xfrm/xfrm_user.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05987
Уязвимость функции ti_sci_intr_irq_domain_probe() модуля drivers/irqchip/irq-ti-sci-intr.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05988
Уязвимость функции udf_name_from_CS0() модуля fs/udf/unicode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05989
Уязвимость функции ucsi_acpi_sync_write() модуля drivers/usb/typec/ucsi/ucsi_acpi.c драйвера интерфейса разъема USB Type C (UCSI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05991
Уязвимость функции raid_component_add() модуля drivers/scsi/raid_class.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05992
Уязвимость функции hv_pci_restore_msi_msg() модуля drivers/pci/controller/pci-hyperv.c драйвера устройств PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05994
Уязвимость функции skb_try_coalesce() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05995
Уязвимость функции addrconf_del_dad_work() модуля net/ipv6/addrconf.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05996
Уязвимость функции vxlan_flag_attr_error() модуля [модуль] ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05997
Уязвимость функции mlxsw_m_linecards_init() модуля drivers/net/ethernet/mellanox/mlxsw/minimal.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05998
Уязвимость функции dwc3_qcom_probe() модуля drivers/usb/dwc3/dwc3-qcom.c драйвера контроллера на базе DesignWare USB3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05999
Уязвимость функции genpd_debug_add() модуля drivers/base/power/domain.c драйвера шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06000
Уязвимость функции ext4_sb_release() модуля fs/ext4/sysfs.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06001
Уязвимость функции __sta_info_destroy_part1() модуля net/mac80211/sta_info.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06003
Уязвимость функции hi3660_thermal_probe() модуля drivers/thermal/hisi_thermal.c драйвера управления температурой ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06005
Уязвимость функции ext4_da_write_end() модуля fs/ext4/inode.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06006
Уязвимость функции vmbus_disconnect() модуля drivers/hv/connection.c драйвера гостевого режима Microsoft HyperV ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06009
Уязвимость функции persistent_ram_post_init() модуля fs/pstore/ram_core.c поддержки постоянного хранилища ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06010
Уязвимость функции icmp6_dev() модуля net/ipv6/icmp.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06011
Уязвимость функции __acquires() модуля drivers/md/md-bitmap.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06020
Уязвимость функции debugfs_lookup() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06021
Уязвимость функции gic_configure_irq() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06022
Уязвимость функции ubi_wl_put_peb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06023
Уязвимость функции debugfs_lookup() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06024
Уязвимость функции ishtp_cl_bus_match() ядра операционных систем Linux, позволяющая нарушителю вызвать сбой в работе ядра операционной системы
BDU:2026-06025
Уязвимость функции DCB_ATTR_BCN() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06026
Уязвимость функции ufshcd_wait_for_dev_cmd() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06027
Уязвимость функции md_end_flush() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06028
Уязвимость функции nfs_d_automount() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06029
Уязвимость функции TTM_TT_FLAG_PRIV_POPULATED() ядра операционных систем Linux, позволяющая нарушителю вызвать нарушение конфиденциальности
BDU:2026-06030
Уязвимость функции early_init_dt_scan_memory() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность данных
BDU:2026-06037
Уязвимость функции i915_gem_object_is_framebuffer() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06038
Уязвимость функции iscsi_target_sk_data_ready() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06042
Уязвимость функции erofs_worker() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06043
Уязвимость функции kfree() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06044
Уязвимость функции mpi3mr_remove() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06046
Уязвимость функции mpi3mr_init_ioc() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06065
Уязвимость функции kset_register() в модуле lib/kobject.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06070
Уязвимость функции iwl_mvm_tx_skb_sta() в модуле drivers/net/wireless/intel/iwlwifi/mvm/tx.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06071
Уязвимость функции kill_kprobe() в модуле kernel/kprobes.c ядра операционной системы 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-06074
Уязвимость функции _rtl8812ae_phy_set_txpower_limit() в модуле drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы 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-06080
Уязвимость функции amdgpu_amdkfd_gpuvm_acquire_process_vm() в модуле drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c ядра операционной системы 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-06087
Уязвимость функции hci_create_cis_sync() в модуле net/bluetooth/hci_conn.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06090
Уязвимость функции am65_cpsw_nuss_ndo_slave_open() в модуле drivers/net/ethernet/ti/am65-cpsw-nuss.c драйвера сетевых адаптеров Ethernet Texas Instruments ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06091
Уязвимость функции mt7915_put_hif2() в модуле drivers/net/wireless/mediatek/mt76/mt7915/pci.c драйвера адаптеров беспроводной связи Mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06093
Уязвимость функции cros_usbpd_notify_init() в модуле drivers/platform/chrome/cros_usbpd_notify.c поддержки платформы оборудования Chrome OS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06094
Уязвимость функции zswap_writeback_entry() в модуле mm/zswap.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06096
Уязвимость функции fill_frame_info() в модуле net/hsr/hsr_forward.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06097
Уязвимость функции __ibmvnic_open() в модуле drivers/net/ethernet/ibm/ibmvnic.c драйвера сетевых адаптеров Ethernet IBM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06098
Уязвимость функции iscsi_sw_tcp_conn_set_param() в модуле drivers/scsi/iscsi_tcp.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06099
Уязвимость функции mt7915_mcu_exit() в модуле drivers/net/wireless/mediatek/mt76/mt7915/mcu.c драйвера адаптеров беспроводной связи Mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06100
Уязвимость функции rtw89_append_probe_req_ie() в модуле drivers/net/wireless/realtek/rtw89/fw.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06101
Уязвимость функции ionic_devlink_alloc() в модуле drivers/net/ethernet/pensando/ionic/ionic_devlink.c драйвера сетевых адаптеров Ethernet Pensando ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06102
Уязвимость функции rt6_nlmsg_size() в модуле net/ipv6/route.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06103
Уязвимость функции cxl_parse_cfmws() в модуле drivers/cxl/acpi.c драйвера устройств CXL (Compute Express Link) ядра операционной системы 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-04-02
CVE-2021-47432
In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Don't overflow in peek() When we started spreading new inode numbers throughout most of the 64 bit inode space, that triggered some corner case bugs, in particular some integer overflows related to the radix tree code. Oops.
- https://git.kernel.org/stable/c/784d01f9bbc282abb0c5ade5beb98a87f50343ac
- https://git.kernel.org/stable/c/9492261ff2460252cf2d8de89cdf854c7e2b28a0
- https://git.kernel.org/stable/c/aa7f1827953100cdde0795289a80c6c077bfe437
- https://git.kernel.org/stable/c/ec298b958cb0c40d70c68079da933c8f31c5134c
- https://git.kernel.org/stable/c/784d01f9bbc282abb0c5ade5beb98a87f50343ac
- https://git.kernel.org/stable/c/9492261ff2460252cf2d8de89cdf854c7e2b28a0
- https://git.kernel.org/stable/c/aa7f1827953100cdde0795289a80c6c077bfe437
- https://git.kernel.org/stable/c/ec298b958cb0c40d70c68079da933c8f31c5134c
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-38457
A use-after-free(UAF) vulnerability was found in function 'vmw_cmd_res_check' in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in Linux kernel's vmwgfx driver with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).
Modified: 2024-11-21
CVE-2022-40133
A use-after-free(UAF) vulnerability was found in function 'vmw_execbuf_tie_context' in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in Linux kernel's vmwgfx driver with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).
Modified: 2025-04-08
CVE-2022-4379
A use-after-free vulnerability was found in __nfs42_ssc_open() in fs/nfs/nfs4file.c in the Linux kernel. This flaw allows an attacker to conduct a remote denial
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75333d48f92256a0dec91dbf07835e804fc411c0
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeba12b26c79fc35e07e511f692a8907037d95da
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LECFVUHKIRBV5JJBE3KQCLGKNYJPBRCN/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RAVD6JIILAVSRHZ4VXSV3RAAGUXKVXZA/
- https://seclists.org/oss-sec/2022/q4/185
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75333d48f92256a0dec91dbf07835e804fc411c0
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeba12b26c79fc35e07e511f692a8907037d95da
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LECFVUHKIRBV5JJBE3KQCLGKNYJPBRCN/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RAVD6JIILAVSRHZ4VXSV3RAAGUXKVXZA/
- https://seclists.org/oss-sec/2022/q4/185
- https://security.netapp.com/advisory/ntap-20230223-0004/
Modified: 2024-11-21
CVE-2022-45886
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_net.c has a .disconnect versus dvb_device_open race condition that leads to a use-after-free.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4172385b0c9ac366dcab78eda48c26814b87ed1a
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-3-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4172385b0c9ac366dcab78eda48c26814b87ed1a
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-3-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
Modified: 2024-11-21
CVE-2022-45919
An issue was discovered in the Linux kernel through 6.0.10. In drivers/media/dvb-core/dvb_ca_en50221.c, a use-after-free can occur is there is a disconnect after an open, because of the lack of a wait_event.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=280a8ab81733da8bc442253c700a52c4c0886ffd
- https://lore.kernel.org/linux-media/20221121063308.GA33821%40ubuntu/T/#u
- https://security.netapp.com/advisory/ntap-20230113-0008/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=280a8ab81733da8bc442253c700a52c4c0886ffd
- https://lore.kernel.org/linux-media/20221121063308.GA33821%40ubuntu/T/#u
- https://security.netapp.com/advisory/ntap-20230113-0008/
Modified: 2025-04-04
CVE-2022-47929
In the Linux kernel before 6.1.6, a NULL pointer dereference bug in the traffic control subsystem allows an unprivileged user to trigger a denial of service (system crash) via a crafted traffic control configuration that is set up with "tc qdisc" and "tc class" commands. This affects qdisc_graft in net/sched/sch_api.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96398560f26aa07e8f2969d73c8197e6a6d10407
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html
- https://www.debian.org/security/2023/dsa-5324
- https://www.spinics.net/lists/netdev/msg555705.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96398560f26aa07e8f2969d73c8197e6a6d10407
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html
- https://www.debian.org/security/2023/dsa-5324
- https://www.spinics.net/lists/netdev/msg555705.html
Modified: 2025-02-27
CVE-2022-48423
In the Linux kernel before 6.1.3, fs/ntfs3/record.c does not validate resident attribute names. An out-of-bounds write may occur.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54e45702b648b7c0000e90b3e9b890e367e16ea8
- https://security.netapp.com/advisory/ntap-20230505-0003/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54e45702b648b7c0000e90b3e9b890e367e16ea8
- https://security.netapp.com/advisory/ntap-20230505-0003/
Modified: 2025-02-27
CVE-2022-48424
In the Linux kernel before 6.1.3, fs/ntfs3/inode.c does not validate the attribute name offset. An unhandled page fault may occur.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79
- https://security.netapp.com/advisory/ntap-20230505-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79
- https://security.netapp.com/advisory/ntap-20230505-0002/
Modified: 2025-05-16
CVE-2022-48425
In the Linux kernel through 6.2.7, fs/ntfs3/inode.c has an invalid kfree because it does not validate MFT flags before replaying logs.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=467333af2f7b95eeaa61a5b5369a80063cd971fd
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd
- https://security.netapp.com/advisory/ntap-20230413-0006/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=467333af2f7b95eeaa61a5b5369a80063cd971fd
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd
- https://security.netapp.com/advisory/ntap-20230413-0006/
Modified: 2024-11-21
CVE-2022-48502
An issue was discovered in the Linux kernel before 6.2. The ntfs3 subsystem does not properly check for correctness during disk reads, leading to an out-of-bounds read in ntfs_set_ea in fs/ntfs3/xattr.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b
- https://security.netapp.com/advisory/ntap-20230703-0004/
- https://syzkaller.appspot.com/bug?extid=8778f030156c6cd16d72
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b
- https://security.netapp.com/advisory/ntap-20230703-0004/
- https://syzkaller.appspot.com/bug?extid=8778f030156c6cd16d72
Modified: 2025-01-13
CVE-2022-48628
In the Linux kernel, the following vulnerability has been resolved:
ceph: drop messages from MDS when unmounting
When unmounting all the dirty buffers will be flushed and after
the last osd request is finished the last reference of the i_count
will be released. Then it will flush the dirty cap/snap to MDSs,
and the unmounting won't wait the possible acks, which will ihold
the inodes when updating the metadata locally but makes no sense
any more, of this. This will make the evict_inodes() to skip these
inodes.
If encrypt is enabled the kernel generate a warning when removing
the encrypt keys when the skipped inodes still hold the keyring:
WARNING: CPU: 4 PID: 168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0
CPU: 4 PID: 168846 Comm: umount Tainted: G S 6.1.0-rc5-ceph-g72ead199864c #1
Hardware name: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 12/17/2015
RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0
RSP: 0018:ffffc9000b277e28 EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00
RDX: 0000000080000000 RSI: ffffffff822f3a09 RDI: ffff888108f59000
RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 0000000000000000
R10: 0000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40
R13: ffff888108f59000 R14: ffff8881d394f800 R15: 0000000000000000
FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571
- https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5
- https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd
- https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571
- https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5
- https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd
Modified: 2025-02-03
CVE-2022-48706
In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Do proper cleanup if IFCVF init fails ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here.
Modified: 2024-12-31
CVE-2022-48707
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix null pointer dereference for resetting decoder Not all decoders have a reset callback. The CXL specification allows a host bridge with a single root port to have no explicit HDM decoders. Currently the region driver assumes there are none. As such the CXL core creates a special pass through decoder instance without a commit/reset callback. Prior to this patch, the ->reset() callback was called unconditionally when calling cxl_region_decode_reset. Thus a configuration with 1 Host Bridge, 1 Root Port, and one directly attached CXL type 3 device or multiple CXL type 3 devices attached to downstream ports of a switch can cause a null pointer dereference. Before the fix, a kernel crash was observed when we destroy the region, and a pass through decoder is reset. The issue can be reproduced as below, 1) create a region with a CXL setup which includes a HB with a single root port under which a memdev is attached directly. 2) destroy the region with cxl destroy-region regionX -f.
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-12-31
CVE-2022-48709
In the Linux kernel, the following vulnerability has been resolved: ice: switch: fix potential memleak in ice_add_adv_recipe() When ice_add_special_words() fails, the 'rm' is not released, which will lead to a memory leak. Fix this up by going to 'err_unroll' label. Compile tested only.
Modified: 2024-09-06
CVE-2022-48867
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Prevent use after free on completion memory On driver unload any pending descriptors are flushed at the time the interrupt is freed: idxd_dmaengine_drv_remove() -> drv_disable_wq() -> idxd_wq_free_irq() -> idxd_flush_pending_descs(). If there are any descriptors present that need to be flushed this flow triggers a "not present" page fault as below: BUG: unable to handle page fault for address: ff391c97c70c9040 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page The address that triggers the fault is the address of the descriptor that was freed moments earlier via: drv_disable_wq()->idxd_wq_free_resources() Fix the use after free by freeing the descriptors after any possible usage. This is done after idxd_wq_reset() to ensure that the memory remains accessible during possible completion writes by the device.
Modified: 2024-09-04
CVE-2022-48868
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Let probe fail when workqueue cannot be enabled The workqueue is enabled when the appropriate driver is loaded and disabled when the driver is removed. When the driver is removed it assumes that the workqueue was enabled successfully and proceeds to free allocations made during workqueue enabling. Failure during workqueue enabling does not prevent the driver from being loaded. This is because the error path within drv_enable_wq() returns success unless a second failure is encountered during the error path. By returning success it is possible to load the driver even if the workqueue cannot be enabled and allocations that do not exist are attempted to be freed during driver remove. Some examples of problematic flows: (a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq(). (b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010 Fix the drv_enable_wq() error path by returning the original error that indicates failure of workqueue enabling. This ensures that the probe fails when an error is encountered and the driver remove paths are only attempted when the workqueue was enabled successfully.
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-48870
In the Linux kernel, the following vulnerability has been resolved:
tty: fix possible null-ptr-defer in spk_ttyio_release
Run the following tests on the qemu platform:
syzkaller:~# modprobe speakup_audptr
input: Speakup as /devices/virtual/input/input4
initialized device: /dev/synth, node (MAJOR 10, MINOR 125)
speakup 3.1.6: initialized
synth name on entry is: (null)
synth probe
spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned
failed (errno -16), then remove the module, we will get a null-ptr-defer
problem, as follow:
syzkaller:~# modprobe -r speakup_audptr
releasing synth audptr
BUG: kernel NULL pointer dereference, address: 0000000000000080
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1
RIP: 0010:mutex_lock+0x14/0x30
Call Trace:
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-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-08-29
CVE-2022-48874
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free and race in fastrpc_map_find Currently, there is a race window between the point when the mutex is unlocked in fastrpc_map_lookup and the reference count increasing (fastrpc_map_get) in fastrpc_map_find, which can also lead to use-after-free. So lets merge fastrpc_map_find into fastrpc_map_lookup which allows us to both protect the maps list by also taking the &fl->lock spinlock and the reference count, since the spinlock will be released only after. Add take_ref argument to make this suitable for all callers.
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-08-29
CVE-2022-48876
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix initialization of rx->link and rx->link_sta
There are some codepaths that do not initialize rx->link_sta properly. This
causes a crash in places which assume that rx->link_sta is valid if rx->sta
is valid.
One known instance is triggered by __ieee80211_rx_h_amsdu being called from
fast-rx. It results in a crash like this one:
BUG: kernel NULL pointer dereference, address: 00000000000000a8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 1 PID: 506 Comm: mt76-usb-rx phy Tainted: G E 6.1.0-debian64x+1.7 #3
Hardware name: ZOTAC ZBOX-ID92/ZBOX-IQ01/ZBOX-ID92/ZBOX-IQ01, BIOS B220P007 05/21/2014
RIP: 0010:ieee80211_deliver_skb+0x62/0x1f0 [mac80211]
Code: 00 48 89 04 24 e8 9e a7 c3 df 89 c0 48 03 1c c5 a0 ea 39 a1 4c 01 6b 08 48 ff 03 48
83 7d 28 00 74 11 48 8b 45 30 48 63 55 44 <48> 83 84 d0 a8 00 00 00 01 41 8b 86 c0
11 00 00 8d 50 fd 83 fa 01
RSP: 0018:ffff999040803b10 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffffb9903f496480 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff999040803ce0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d21828ac900
R13: 000000000000004a R14: ffff8d2198ed89c0 R15: ffff8d2198ed8000
FS: 0000000000000000(0000) GS:ffff8d24afe80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000a8 CR3: 0000000429810002 CR4: 00000000001706e0
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: 2025-10-10
CVE-2022-48880
In the Linux kernel, the following vulnerability has been resolved: platform/surface: aggregator: Add missing call to ssam_request_sync_free() Although rare, ssam_request_sync_init() can fail. In that case, the request should be freed via ssam_request_sync_free(). Currently it is leaked instead. Fix this.
Modified: 2024-08-29
CVE-2022-48881
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd: Fix refcount leak in amd_pmc_probe pci_get_domain_bus_and_slot() takes reference, the caller should release the reference by calling pci_dev_put() after use. Call pci_dev_put() in the error path to fix this.
Modified: 2024-08-29
CVE-2022-48882
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix macsec possible null dereference when updating MAC security entity (SecY) Upon updating MAC security entity (SecY) in hw offload path, the macsec security association (SA) initialization routine is called. In case of extended packet number (epn) is enabled the salt and ssci attributes are retrieved using the MACsec driver rx_sa context which is unavailable when updating a SecY property such as encoding-sa hence the null dereference. Fix by using the provided SA to set those attributes.
Modified: 2025-09-26
CVE-2022-48883
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user.
Modified: 2025-01-08
CVE-2022-48884
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix command stats access after free Command may fail while driver is reloading and can't accept FW commands till command interface is reinitialized. Such command failure is being logged to command stats. This results in NULL pointer access as command stats structure is being freed and reallocated during mlx5 devlink reload (see kernel log below). Fix it by making command stats statically allocated on driver probe. Kernel log: [ 2394.808802] BUG: unable to handle kernel paging request at 000000000002a9c0 [ 2394.810610] PGD 0 P4D 0 [ 2394.811811] Oops: 0002 [#1] SMP NOPTI ... [ 2394.815482] RIP: 0010:native_queued_spin_lock_slowpath+0x183/0x1d0 ... [ 2394.829505] Call Trace: [ 2394.830667] _raw_spin_lock_irq+0x23/0x26 [ 2394.831858] cmd_status_err+0x55/0x110 [mlx5_core] [ 2394.833020] mlx5_access_reg+0xe7/0x150 [mlx5_core] [ 2394.834175] mlx5_query_port_ptys+0x78/0xa0 [mlx5_core] [ 2394.835337] mlx5e_ethtool_get_link_ksettings+0x74/0x590 [mlx5_core] [ 2394.836454] ? kmem_cache_alloc_trace+0x140/0x1c0 [ 2394.837562] __rh_call_get_link_ksettings+0x33/0x100 [ 2394.838663] ? __rtnl_unlock+0x25/0x50 [ 2394.839755] __ethtool_get_link_ksettings+0x72/0x150 [ 2394.840862] duplex_show+0x6e/0xc0 [ 2394.841963] dev_attr_show+0x1c/0x40 [ 2394.843048] sysfs_kf_seq_show+0x9b/0x100 [ 2394.844123] seq_read+0x153/0x410 [ 2394.845187] vfs_read+0x91/0x140 [ 2394.846226] ksys_read+0x4f/0xb0 [ 2394.847234] do_syscall_64+0x5b/0x1a0 [ 2394.848228] entry_SYSCALL_64_after_hwframe+0x65/0xca
Modified: 2024-09-06
CVE-2022-48885
In the Linux kernel, the following vulnerability has been resolved: ice: Fix potential memory leak in ice_gnss_tty_write() The ice_gnss_tty_write() return directly if the write_buf alloc failed, leaking the cmd_buf. Fix by free cmd_buf if write_buf alloc failed.
Modified: 2024-09-06
CVE-2022-48886
In the Linux kernel, the following vulnerability has been resolved: ice: Add check for kzalloc Add the check for the return value of kzalloc in order to avoid NULL pointer dereference. Moreover, use the goto-label to share the clean code.
Modified: 2024-09-06
CVE-2022-48887
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Remove rcu locks from user resources User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources. Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources.
Modified: 2024-08-29
CVE-2022-48888
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Fix memory leak in msm_mdss_parse_data_bus_icc_path of_icc_get() alloc resources for path1, we should release it when not need anymore. Early return when IS_ERR_OR_NULL(path0) may leak path1. Defer getting path1 to fix this. Patchwork: https://patchwork.freedesktop.org/patch/514264/
Modified: 2024-09-06
CVE-2022-48889
In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: sof-nau8825: fix module alias overflow
The maximum name length for a platform_device_id entry is 20 characters
including the trailing NUL byte. The sof_nau8825.c file exceeds that,
which causes an obscure error message:
sound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: illegal character encoding in string literal [-Werror,-Winvalid-source-encoding]
MODULE_ALIAS("platform:adl_max98373_nau8825
Modified: 2024-09-06
CVE-2022-48890
In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can't do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force. Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.
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-08-29
CVE-2022-48892
In the Linux kernel, the following vulnerability has been resolved: sched/core: Fix use-after-free bug in dup_user_cpus_ptr() Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel. Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches. Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock. Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over.
Modified: 2025-11-03
CVE-2022-48893
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Cleanup partial engine discovery failures If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated. v2: - Drop the destroy_pinned_context() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz)
- https://git.kernel.org/stable/c/5c855bcc730656c4b7d30aaddcd0eafc7003e112
- https://git.kernel.org/stable/c/78350c36fb15afef423404a83dcbc5c558dce795
- https://git.kernel.org/stable/c/78a033433a5ae4fee85511ee075bc9a48312c79e
- https://git.kernel.org/stable/c/7d21587d35bc816c85a51b8686f0f7e8e676fb14
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2024-09-11
CVE-2022-48894
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Don't unregister on shutdown Similar to SMMUv2, this driver calls iommu_device_unregister() from the shutdown path, which removes the IOMMU groups with no coordination whatsoever with their users - shutdown methods are optional in device drivers. This can lead to NULL pointer dereferences in those drivers' DMA API calls, or worse. Instead of calling the full arm_smmu_device_remove() from arm_smmu_device_shutdown(), let's pick only the relevant function call - arm_smmu_device_disable() - more or less the reverse of arm_smmu_device_reset() - and call just that from the shutdown path.
Modified: 2024-09-11
CVE-2022-48895
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: Don't unregister on shutdown Michael Walle says he noticed the following stack trace while performing a shutdown with "reboot -f". He suggests he got "lucky" and just hit the correct spot for the reboot while there was a packet transmission in flight. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 6.1.0-rc5-00088-gf3600ff8e322 #1930 Hardware name: Kontron KBox A-230-LS (DT) pc : iommu_get_dma_domain+0x14/0x20 lr : iommu_dma_map_page+0x9c/0x254 Call trace: iommu_get_dma_domain+0x14/0x20 dma_map_page_attrs+0x1ec/0x250 enetc_start_xmit+0x14c/0x10b0 enetc_xmit+0x60/0xdc dev_hard_start_xmit+0xb8/0x210 sch_direct_xmit+0x11c/0x420 __dev_queue_xmit+0x354/0xb20 ip6_finish_output2+0x280/0x5b0 __ip6_finish_output+0x15c/0x270 ip6_output+0x78/0x15c NF_HOOK.constprop.0+0x50/0xd0 mld_sendpack+0x1bc/0x320 mld_ifc_work+0x1d8/0x4dc process_one_work+0x1e8/0x460 worker_thread+0x178/0x534 kthread+0xe0/0xe4 ret_from_fork+0x10/0x20 Code: d503201f f9416800 d503233f d50323bf (f9404c00) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt This appears to be reproducible when the board has a fixed IP address, is ping flooded from another host, and "reboot -f" is used. The following is one more manifestation of the issue: $ reboot -f kvm: exiting hardware virtualization cfg80211: failed to load regulatory.db arm-smmu 5000000.iommu: disabling translation sdhci-esdhc 2140000.mmc: Removing from iommu group 11 sdhci-esdhc 2150000.mmc: Removing from iommu group 12 fsl-edma 22c0000.dma-controller: Removing from iommu group 17 dwc3 3100000.usb: Removing from iommu group 9 dwc3 3110000.usb: Removing from iommu group 10 ahci-qoriq 3200000.sata: Removing from iommu group 2 fsl-qdma 8380000.dma-controller: Removing from iommu group 20 platform f080000.display: Removing from iommu group 0 etnaviv-gpu f0c0000.gpu: Removing from iommu group 1 etnaviv etnaviv: Removing from iommu group 1 caam_jr 8010000.jr: Removing from iommu group 13 caam_jr 8020000.jr: Removing from iommu group 14 caam_jr 8030000.jr: Removing from iommu group 15 caam_jr 8040000.jr: Removing from iommu group 16 fsl_enetc 0000:00:00.0: Removing from iommu group 4 arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000 fsl_enetc 0000:00:00.1: Removing from iommu group 5 arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000 arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000 fsl_enetc 0000:00:00.2: Removing from iommu group 6 fsl_enetc_mdio 0000:00:00.3: Removing from iommu group 8 mscc_felix 0000:00:00.5: Removing from iommu group 3 fsl_enetc 0000:00:00.6: Removing from iommu group 7 pcieport 0001:00:00.0: Removing from iommu group 18 arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications arm-smmu 5000000.iommu: GFSR 0x00000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000 pcieport 0002:00:00.0: Removing from iommu group 19 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 pc : iommu_get_dma_domain+0x14/0x20 lr : iommu_dma_unmap_page+0x38/0xe0 Call trace: iommu_get_dma_domain+0x14/0x20 dma_unmap_page_attrs+0x38/0x1d0 en ---truncated---
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-48897
In the Linux kernel, the following vulnerability has been resolved: arm64/mm: fix incorrect file_map_count for invalid pmd The page table check trigger BUG_ON() unexpectedly when split hugepage: ------------[ cut here ]------------ kernel BUG at mm/page_table_check.c:119! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748 Hardware name: linux,dummy-virt (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_table_check_set.isra.0+0x398/0x468 lr : page_table_check_set.isra.0+0x1c0/0x468 [...] Call trace: page_table_check_set.isra.0+0x398/0x468 __page_table_check_pte_set+0x160/0x1c0 __split_huge_pmd_locked+0x900/0x1648 __split_huge_pmd+0x28c/0x3b8 unmap_page_range+0x428/0x858 unmap_single_vma+0xf4/0x1c8 zap_page_range+0x2b0/0x410 madvise_vma_behavior+0xc44/0xe78 do_madvise+0x280/0x698 __arm64_sys_madvise+0x90/0xe8 invoke_syscall.constprop.0+0xdc/0x1d8 do_el0_svc+0xf4/0x3f8 el0_svc+0x58/0x120 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x19c/0x1a0 [...] On arm64, pmd_leaf() will return true even if the pmd is invalid due to pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count will not only decrease once but also increase once. Then in set_pte_at(), the file_map_count increase again, and so trigger BUG_ON() unexpectedly. Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the problem.
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: 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-30
CVE-2022-49739
In the Linux kernel, the following vulnerability has been resolved: gfs2: Always check inode size of inline inodes Check if the inode size of stuffed (inline) inodes is within the allowed range when reading inodes from disk (gfs2_dinode_in()). This prevents us from on-disk corruption. The two checks in stuffed_readpage() and gfs2_unstuffer_page() that just truncate inline data to the maximum allowed size don't actually make sense, and they can be removed now as well.
- https://git.kernel.org/stable/c/45df749f827c286adbc951f2a4865b67f0442ba9
- https://git.kernel.org/stable/c/46c9088cabd4d0469fdb61ac2a9c5003057fe94d
- https://git.kernel.org/stable/c/4d4cb76636134bf9a0c9c3432dae936f99954586
- https://git.kernel.org/stable/c/70376c7ff31221f1d21db5611d8209e677781d3a
- https://git.kernel.org/stable/c/7c414f6f06e9a3934901b6edc3177ae5a1e07094
- https://git.kernel.org/stable/c/d458a0984429c2d47e60254f5bc4119cbafe83a2
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-49742
In the Linux kernel, the following vulnerability has been resolved: f2fs: initialize locks earlier in f2fs_fill_super() syzbot is reporting lockdep warning at f2fs_handle_error() [1], for spin_lock(&sbi->error_lock) is called before spin_lock_init() is called. For safe locking in error handling, move initialization of locks (and obvious structures) in f2fs_fill_super() to immediately after memory allocation.
Modified: 2026-01-19
CVE-2022-49743
In the Linux kernel, the following vulnerability has been resolved: ovl: Use "buf" flexible array for memcpy() destination The "buf" flexible array needs to be the memcpy() destination to avoid false positive run-time warning from the recent FORTIFY_SOURCE hardening: memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21)
Modified: 2025-10-30
CVE-2022-49744
In the Linux kernel, the following vulnerability has been resolved: mm/uffd: fix pte marker when fork() without fork event Patch series "mm: Fixes on pte markers". Patch 1 resolves the syzkiller report from Pengfei. Patch 2 further harden pte markers when used with the recent swapin error markers. The major case is we should persist a swapin error marker after fork(), so child shouldn't read a corrupted page. This patch (of 2): When fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may have it and has pte marker installed. The warning is improper along with the comment. The right thing is to inherit the pte marker when needed, or keep the dst pte empty. A vague guess is this happened by an accident when there's the prior patch to introduce src/dst vma into this helper during the uffd-wp feature got developed and I probably messed up in the rebase, since if we replace dst_vma with src_vma the warning & comment it all makes sense too. Hugetlb did exactly the right here (copy_hugetlb_page_range()). Fix the general path. Reproducer: https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c Bugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=216808
Modified: 2025-10-30
CVE-2022-49745
In the Linux kernel, the following vulnerability has been resolved: fpga: m10bmc-sec: Fix probe rollback Handle probe error rollbacks properly to avoid leaks.
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-29
CVE-2022-49747
In the Linux kernel, the following vulnerability has been resolved: erofs/zmap.c: Fix incorrect offset calculation Effective offset to add to length was being incorrectly calculated, which resulted in iomap->length being set to 0, triggering a WARN_ON in iomap_iter_done(). Fix that, and describe it in comments. This was reported as a crash by syzbot under an issue about a warning encountered in iomap_iter_done(), but unrelated to erofs. C reproducer: https://syzkaller.appspot.com/text?tag=ReproC&x=1037a6b2880000 Kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=e2021a61197ebe02 Dashboard link: https://syzkaller.appspot.com/bug?extid=a8e049cd3abd342936b6
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-49750
In the Linux kernel, the following vulnerability has been resolved: cpufreq: CPPC: Add u64 casts to avoid overflowing The fields of the _CPC object are unsigned 32-bits values. To avoid overflows while using _CPC's values, add 'u64' casts.
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: 2026-04-18
CVE-2022-49752
In the Linux kernel, the following vulnerability has been resolved: device property: fix of node refcount leak in fwnode_graph_get_next_endpoint() The 'parent' returned by fwnode_graph_get_port_parent() with refcount incremented when 'prev' is not NULL, it needs be put when finish using it. Because the parent is const, introduce a new variable to store the returned fwnode, then put it before returning from fwnode_graph_get_next_endpoint().
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-10-01
CVE-2022-49754
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() Smatch Warning: net/bluetooth/mgmt_util.c:375 mgmt_mesh_add() error: __memcpy() 'mesh_tx->param' too small (48 vs 50) Analysis: 'mesh_tx->param' is array of size 48. This is the destination. u8 param[sizeof(struct mgmt_cp_mesh_send) + 29]; // 19 + 29 = 48. But in the caller 'mesh_send' we reject only when len > 50. len > (MGMT_MESH_SEND_SIZE + 31) // 19 + 31 = 50.
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-49756
In the Linux kernel, the following vulnerability has been resolved: phy: usb: sunplus: Fix potential null-ptr-deref in sp_usb_phy_probe() sp_usb_phy_probe() will call platform_get_resource_byname() that may fail and return NULL. devm_ioremap() will use usbphy->moon4_res_mem->start as input, which may causes null-ptr-deref. Check the ret value of platform_get_resource_byname() to avoid the null-ptr-deref.
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-10-01
CVE-2022-49758
In the Linux kernel, the following vulnerability has been resolved: reset: uniphier-glue: Fix possible null-ptr-deref It will cause null-ptr-deref when resource_size(res) invoked, if platform_get_resource() returns NULL.
Modified: 2025-10-01
CVE-2022-49759
In the Linux kernel, the following vulnerability has been resolved:
VMCI: Use threaded irqs instead of tasklets
The vmci_dispatch_dgs() tasklet function calls vmci_read_data()
which uses wait_event() resulting in invalid sleep in an atomic
context (and therefore potentially in a deadlock).
Use threaded irqs to fix this issue and completely remove usage
of tasklets.
[ 20.264639] BUG: sleeping function called from invalid context at drivers/misc/vmw_vmci/vmci_guest.c:145
[ 20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd
[ 20.264645] preempt_count: 101, expected: 0
[ 20.264646] RCU nest depth: 0, expected: 0
[ 20.264647] 1 lock held by vmtoolsd/762:
[ 20.264648] #0: ffff0000874ae440 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: vsock_connect+0x60/0x330 [vsock]
[ 20.264658] Preemption disabled at:
[ 20.264659] [
Modified: 2025-10-29
CVE-2022-49760
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix PTE marker handling in hugetlb_change_protection()
Patch series "mm/hugetlb: uffd-wp fixes for hugetlb_change_protection()".
Playing with virtio-mem and background snapshots (using uffd-wp) on
hugetlb in QEMU, I managed to trigger a VM_BUG_ON(). Looking into the
details, hugetlb_change_protection() seems to not handle uffd-wp correctly
in all cases.
Patch #1 fixes my test case. I don't have reproducers for patch #2, as it
requires running into migration entries.
I did not yet check in detail yet if !hugetlb code requires similar care.
This patch (of 2):
There are two problematic cases when stumbling over a PTE marker in
hugetlb_change_protection():
(1) We protect an uffd-wp PTE marker a second time using uffd-wp: we will
end up in the "!huge_pte_none(pte)" case and mess up the PTE marker.
(2) We unprotect a uffd-wp PTE marker: we will similarly end up in the
"!huge_pte_none(pte)" case even though we cleared the PTE, because
the "pte" variable is stale. We'll mess up the PTE marker.
For example, if we later stumble over such a "wrongly modified" PTE marker,
we'll treat it like a present PTE that maps some garbage page.
This can, for example, be triggered by mapping a memfd backed by huge
pages, registering uffd-wp, uffd-wp'ing an unmapped page and (a)
uffd-wp'ing it a second time; or (b) uffd-unprotecting it; or (c)
unregistering uffd-wp. Then, ff we trigger fallocate(FALLOC_FL_PUNCH_HOLE)
on that file range, we will run into a VM_BUG_ON:
[ 195.039560] page:00000000ba1f2987 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0
[ 195.039565] flags: 0x7ffffc0001000(reserved|node=0|zone=0|lastcpupid=0x1fffff)
[ 195.039568] raw: 0007ffffc0001000 ffffe742c0000008 ffffe742c0000008 0000000000000000
[ 195.039569] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[ 195.039569] page dumped because: VM_BUG_ON_PAGE(compound && !PageHead(page))
[ 195.039573] ------------[ cut here ]------------
[ 195.039574] kernel BUG at mm/rmap.c:1346!
[ 195.039579] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 195.039581] CPU: 7 PID: 4777 Comm: qemu-system-x86 Not tainted 6.0.12-200.fc36.x86_64 #1
[ 195.039583] Hardware name: LENOVO 20WNS1F81N/20WNS1F81N, BIOS N35ET50W (1.50 ) 09/15/2022
[ 195.039584] RIP: 0010:page_remove_rmap+0x45b/0x550
[ 195.039588] Code: [...]
[ 195.039589] RSP: 0018:ffffbc03c3633ba8 EFLAGS: 00010292
[ 195.039591] RAX: 0000000000000040 RBX: ffffe742c0000000 RCX: 0000000000000000
[ 195.039592] RDX: 0000000000000002 RSI: ffffffff8e7aac1a RDI: 00000000ffffffff
[ 195.039592] RBP: 0000000000000001 R08: 0000000000000000 R09: ffffbc03c3633a08
[ 195.039593] R10: 0000000000000003 R11: ffffffff8f146328 R12: ffff9b04c42754b0
[ 195.039594] R13: ffffffff8fcc6328 R14: ffffbc03c3633c80 R15: ffff9b0484ab9100
[ 195.039595] FS: 00007fc7aaf68640(0000) GS:ffff9b0bbf7c0000(0000) knlGS:0000000000000000
[ 195.039596] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 195.039597] CR2: 000055d402c49110 CR3: 0000000159392003 CR4: 0000000000772ee0
[ 195.039598] PKRU: 55555554
[ 195.039599] Call Trace:
[ 195.039600]
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-12
CVE-2022-49932
In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace
Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes
/dev/kvm to userspace and thus allows userspace to create VMs (and call
other ioctls). E.g. KVM will encounter a NULL pointer when attempting to
add a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to
create a VM before vmx_init() configures said list.
BUG: kernel NULL pointer dereference, address: 0000000000000008
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP
CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel]
Modified: 2025-11-24
CVE-2022-50236
In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Fix crash on isr after kexec() If the system is rebooted via isr(), the IRQ handler might be triggered before the domain is initialized. Resulting on an invalid memory access error. Fix: [ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070 [ 0.501166] Call trace: [ 0.501174] report_iommu_fault+0x28/0xfc [ 0.501180] mtk_iommu_isr+0x10c/0x1c0 [ joro: Fixed spelling in commit message ]
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-24
CVE-2022-50247
In the Linux kernel, the following vulnerability has been resolved: usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq Can not set the @shared_hcd to NULL before decrease the usage count by usb_put_hcd(), this will cause the shared hcd not released.
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-50258
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds() This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated. Found by a modified version of syzkaller. [ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][ T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [ 47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.633002][ ---truncated---
- https://git.kernel.org/stable/c/0a06cadcc2a0044e4a117cc0e61436fc3a0dad69
- https://git.kernel.org/stable/c/17dbe90e13f52848c460d253f15b765038ec6dc0
- https://git.kernel.org/stable/c/3a3a5e3f94068cd562d62a57da6983c8cd07d53c
- https://git.kernel.org/stable/c/881f50d76c3892262730ddf5c894eb00310e736c
- https://git.kernel.org/stable/c/89243a7b0ea19606ba1c2873c9d569026ccb344f
- https://git.kernel.org/stable/c/ba166e0ebdde3dfa833f0a3edaf2b2934d4a87f7
- https://git.kernel.org/stable/c/d481fd6064bf215d7c5068e15aa390c3b16c9cd0
- https://git.kernel.org/stable/c/d6ef66194bb4a6c18f5b9649bf62597909b040e4
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-50262
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate BOOT record_size
When the NTFS BOOT record_size field < 0, it represents a
shift value. However, there is no sanity check on the shift result
and the sbi->record_bits calculation through blksize_bits() assumes
the size always > 256, which could lead to NPD while mounting a
malformed NTFS image.
[ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158
[ 318.675682] #PF: supervisor read access in kernel mode
[ 318.675869] #PF: error_code(0x0000) - not-present page
[ 318.676246] PGD 0 P4D 0
[ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5
[ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0
[ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180
[ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246
[ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080
[ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080
[ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000
[ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000
[ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0
[ 318.685623] Call Trace:
[ 318.686607]
Modified: 2025-12-02
CVE-2022-50263
In the Linux kernel, the following vulnerability has been resolved: vdpasim: fix memory leak when freeing IOTLBs After commit bda324fd037a ("vdpasim: control virtqueue support"), vdpasim->iommu became an array of IOTLB, so we should clean the mappings of each free one by one instead of just deleting the ranges in the first IOTLB which may leak maps.
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-02
CVE-2022-50266
In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix check for probe enabled in kill_kprobe() In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be called always fails. This is because before that we set the KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always false. The disarm_kprobe_ftrace() call introduced by commit: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler") to fix the NULL pointer reference problem. When the probe is enabled, if we do not disarm it, this problem still exists. Fix it by putting the probe enabled check before setting the KPROBE_FLAG_GONE flag.
Modified: 2025-12-03
CVE-2022-50267
In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_pci: 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, beside, runtime PM also needs be disabled.
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-50269
In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix memory leak in vkms_init() A memory leak was reported after the vkms module install failed. unreferenced object 0xffff88810bc28520 (size 16): comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first 16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............ backtrace: [<00000000e7561ff8>] kmalloc_trace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0 [<000000001505ee87>] do_init_module+0x1a4/0x680 [<00000000958079ad>] load_module+0x6249/0x7110 [<00000000117e4696>] __do_sys_finit_module+0x140/0x200 [<00000000f74b12d2>] do_syscall_64+0x35/0x80 [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that the vkms_init() returns without checking the return value of vkms_create(), and if the vkms_create() failed, the config allocated at the beginning of vkms_init() is leaked. vkms_init() config = kmalloc(...) # config allocated ... return vkms_create() # vkms_create failed and config is leaked Fix this problem by checking return value of vkms_create() and free the config if error happened.
Modified: 2026-01-23
CVE-2022-50270
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix the assign logic of iocb commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint") introduces iocb field in 'f2fs_direct_IO_enter' trace event And it only assigns the pointer and later it accesses its field in trace print log. Unable to handle kernel paging request at virtual address ffffffc04cef3d30 Mem abort info: ESR = 0x96000007 EC = 0x25: DABT (current EL), IL = 32 bits pc : trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4 lr : trace_raw_output_f2fs_direct_IO_enter+0x2c/0xa4 sp : ffffffc0443cbbd0 x29: ffffffc0443cbbf0 x28: ffffff8935b120d0 x27: ffffff8935b12108 x26: ffffff8935b120f0 x25: ffffff8935b12100 x24: ffffff8935b110c0 x23: ffffff8935b10000 x22: ffffff88859a936c x21: ffffff88859a936c x20: ffffff8935b110c0 x19: ffffff8935b10000 x18: ffffffc03b195060 x17: ffffff8935b11e76 x16: 00000000000000cc x15: ffffffef855c4f2c x14: 0000000000000001 x13: 000000000000004e x12: ffff0000ffffff00 x11: ffffffef86c350d0 x10: 00000000000010c0 x9 : 000000000fe0002c x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : 0000000002000000 x5 : ffffff8935b11e9a x4 : 0000000000006250 x3 : ffff0a00ffffff04 x2 : 0000000000000002 x1 : ffffffef86a0a31f x0 : ffffff8935b10000 Call trace: trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4 print_trace_fmt+0x9c/0x138 print_trace_line+0x154/0x254 tracing_read_pipe+0x21c/0x380 vfs_read+0x108/0x3ac ksys_read+0x7c/0xec __arm64_sys_read+0x20/0x30 invoke_syscall+0x60/0x150 el0_svc_common.llvm.1237943816091755067+0xb8/0xf8 do_el0_svc+0x28/0xa0 Fix it by copying the required variables for printing and while at it fix the similar issue at some other places in the same file.
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-50277
In the Linux kernel, the following vulnerability has been resolved: ext4: don't allow journal inode to have encrypt flag Mounting a filesystem whose journal inode has the encrypt flag causes a NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' mount option is used. The problem is that when jbd2_journal_init_inode() calls bmap(), it eventually finds its way into ext4_iomap_begin(), which calls fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if the inode is encrypted, then its encryption key must already be set up. That's not the case here, since the journal inode is never "opened" like a normal file would be. Hence the crash. A reproducer is: mkfs.ext4 -F /dev/vdb debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808" mount /dev/vdb /mnt -o inlinecrypt To fix this, make ext4 consider journal inodes with the encrypt flag to be invalid. (Note, maybe other flags should be rejected on the journal inode too. For now, this is just the minimal fix for the above issue.) I've marked this as fixing the commit that introduced the call to fscrypt_limit_io_blocks(), since that's what made an actual crash start being possible. But this fix could be applied to any version of ext4 that supports the encrypt feature.
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-03
CVE-2022-50279
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()
There is a global-out-of-bounds reported by KASAN:
BUG: KASAN: global-out-of-bounds in
_rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411
CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D
6.1.0-rc8+ #144 e15588508517267d37
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
Call Trace:
- https://git.kernel.org/stable/c/057b52461dc005ecd85a3e4998913b1492ec0f72
- https://git.kernel.org/stable/c/0c962dcd6bf64b78eaffc09e497a2beb4e48bc32
- https://git.kernel.org/stable/c/117dbeda22ec5ea0918254d03b540ef8b8a64d53
- https://git.kernel.org/stable/c/1e950b9a841bc96e98ee25680d5c7aa305120be1
- https://git.kernel.org/stable/c/28ea268d95e57cdf6394a058f0d854206d478772
- https://git.kernel.org/stable/c/f1fe40120de6ad4ffa8299fde035a5feba10d4fb
- https://git.kernel.org/stable/c/fc3442247716fc426bbcf62ed65e086e48a6d44f
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-03
CVE-2022-50284
In the Linux kernel, the following vulnerability has been resolved: ipc: fix memory leak in init_mqueue_fs() When setup_mq_sysctls() failed in init_mqueue_fs(), mqueue_inode_cachep is not released. In order to fix this issue, the release path is reordered.
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-50287
In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs When (size != 0 || ptrs->lvds_ entries != 3), the program tries to free() the ptrs. However, the ptrs is not created by calling kzmalloc(), but is obtained by pointer offset operation. This may lead to memory leaks or undefined behavior. Fix this by replacing the arguments of kfree() with ptrs_block. (cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec)
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-50293
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range If we get -ENOMEM while dropping file extent items in a given range, at btrfs_drop_extents(), due to failure to allocate memory when attempting to increment the reference count for an extent or drop the reference count, we handle it with a BUG_ON(). This is excessive, instead we can simply abort the transaction and return the error to the caller. In fact most callers of btrfs_drop_extents(), directly or indirectly, already abort the transaction if btrfs_drop_extents() returns any error. Also, we already have error paths at btrfs_drop_extents() that may return -ENOMEM and in those cases we abort the transaction, like for example anything that changes the b+tree may return -ENOMEM due to a failure to allocate a new extent buffer when COWing an existing extent buffer, such as a call to btrfs_duplicate_item() for example. So replace the BUG_ON() calls with proper logic to abort the transaction and return the error.
Modified: 2025-12-03
CVE-2022-50294
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in lbs_init_adapter() When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not released. Add free memory to processing error path.
- https://git.kernel.org/stable/c/037f84c0bfae5c436c651d0e804264e2648010ec
- https://git.kernel.org/stable/c/16a03958618fb91bb1bc7077cf3211055162cc2f
- https://git.kernel.org/stable/c/23b34e08de5c2380414c9d3c33e8235094bcccae
- https://git.kernel.org/stable/c/4c102ad59bfa66c0f6662af64fa3b9007b02c20f
- https://git.kernel.org/stable/c/653d13a73e498d0bb6aeaf689aaa960defa7878b
- https://git.kernel.org/stable/c/98e0ff6980c89239d9e5d3da90d791c2383dc23a
- https://git.kernel.org/stable/c/9c8f50c7433bdfba1588831c413136ecc3f29f99
- https://git.kernel.org/stable/c/d46c33f667b05c22bc5c5b69aa730349c4b6fe31
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-50300
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix extent map use-after-free when handling missing device in read_one_chunk Store the error code before freeing the extent_map. Though it's reference counted structure, in that function it's the first and last allocation so this would lead to a potential use-after-free. The error can happen eg. when chunk is stored on a missing device and the degraded mount option is missing. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721
Modified: 2025-12-04
CVE-2022-50302
In the Linux kernel, the following vulnerability has been resolved: lockd: set other missing fields when unlocking files vfs_lock_file() expects the struct file_lock to be fully initialised by the caller. Re-exported NFSv3 has been seen to Oops if the fl_file field is NULL.
- https://git.kernel.org/stable/c/18ebd35b61b4693a0ddc270b6d4f18def232e770
- https://git.kernel.org/stable/c/31c93ee5f1e4dc278b562e20f3c3274ac34997f3
- https://git.kernel.org/stable/c/688575aef211b0986fc51010116f5888a99d76a2
- https://git.kernel.org/stable/c/95d42a8d3d4ae84a0bd3ee23e1fee240cdf0a9f0
- https://git.kernel.org/stable/c/d7aa9f7778316beb690f6e2763b6d672ad8b256f
Modified: 2025-12-04
CVE-2022-50303
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10
Modified: 2025-12-04
CVE-2022-50304
In the Linux kernel, the following vulnerability has been resolved:
mtd: core: fix possible resource leak in init_mtd()
I got the error report while inject fault in init_mtd():
sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'
Call Trace:
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-03
CVE-2022-50316
In the Linux kernel, the following vulnerability has been resolved: orangefs: Fix kmemleak in orangefs_sysfs_init() When insert and remove the orangefs module, there are kobjects memory leaked as below: unreferenced object 0xffff88810f95af00 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................ 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005a6e4dfe>] orangefs_sysfs_init+0x42/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<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 unreferenced object 0xffff88810f95ae80 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................ 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001a4841fa>] orangefs_sysfs_init+0xc7/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<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 unreferenced object 0xffff88810f95ae00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff `............... 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005915e797>] orangefs_sysfs_init+0x12b/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<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 unreferenced object 0xffff88810f95ad80 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x............... 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000007a14eb35>] orangefs_sysfs_init+0x1ac/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<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 unreferenced object 0xffff88810f95ac00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.531s) hex dump (first 32 bytes): e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g............. 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001f38adcb>] orangefs_sysfs_init+0x291/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<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/ ---truncated---
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-04
CVE-2022-50319
In the Linux kernel, the following vulnerability has been resolved: coresight: trbe: remove cpuhp instance node before remove cpuhp state cpuhp_state_add_instance() and cpuhp_state_remove_instance() should be used in pairs. Or there will lead to the warn on cpuhp_remove_multi_state() since the cpuhp_step list is not empty. The following is the error log with 'rmmod coresight-trbe': Error: Removing state 215 which has instances left. Call trace: __cpuhp_remove_state_cpuslocked+0x144/0x160 __cpuhp_remove_state+0xac/0x100 arm_trbe_device_remove+0x2c/0x60 [coresight_trbe] platform_remove+0x34/0x70 device_remove+0x54/0x90 device_release_driver_internal+0x1e4/0x250 driver_detach+0x5c/0xb0 bus_remove_driver+0x64/0xc0 driver_unregister+0x3c/0x70 platform_driver_unregister+0x20/0x30 arm_trbe_exit+0x1c/0x658 [coresight_trbe] __arm64_sys_delete_module+0x1ac/0x24c invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x1a0 do_el0_svc+0x38/0xd0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x19c/0x1a0 ---[ end trace 0000000000000000 ]---
Modified: 2025-12-03
CVE-2022-50321
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit() The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it. Compile tested only.
- https://git.kernel.org/stable/c/212fde3fe76e962598ce1d47b97cc78afdfc71b3
- https://git.kernel.org/stable/c/3a4d18318f473e97d628f410215b3fac32d07aed
- https://git.kernel.org/stable/c/4c55fdebc1c358de96bfab52ed309d58a3ba66ef
- https://git.kernel.org/stable/c/7f159116d620615779adbf88a5d94713702216d8
- https://git.kernel.org/stable/c/d869a189505224601e310c7769cb90b0e2f60b31
- https://git.kernel.org/stable/c/e08e6812efb6a8c676e733de0518594d1517e0d9
- https://git.kernel.org/stable/c/e5d01e85cf46628647cd696cb72ba4659b18967f
- https://git.kernel.org/stable/c/e8ef89e5b89ee041a94eecfb6c31fcc237f9168c
Modified: 2025-12-04
CVE-2022-50322
In the Linux kernel, the following vulnerability has been resolved: rtc: msc313: Fix function prototype mismatch in msc313_rtc_probe() 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. msc313_rtc_probe() was passing clk_disable_unprepare() directly, which did not have matching prototypes for devm_add_action_or_reset()'s callback argument. Refactor to use devm_clk_get_enabled() instead. 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.
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-50325
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Fix potential RX buffer overflow If an event caused firmware to return invalid RX size for LARGE_CONFIG_GET, memcpy_fromio() could end up copying too many bytes. Fix by utilizing min_t().
Modified: 2026-01-16
CVE-2022-50327
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value The return value of acpi_fetch_acpi_dev() could be NULL, which would cause a NULL pointer dereference to occur in acpi_device_hid(). [ rjw: Subject and changelog edits, added empty line after if () ]
- https://git.kernel.org/stable/c/2437513a814b3e93bd02879740a8a06e52e2cf7d
- https://git.kernel.org/stable/c/2ecd629c788bbfb96be058edade2e934d3763eaf
- https://git.kernel.org/stable/c/8e8b5f12ee4ab6f5d252c9ca062a4ada9554e6d9
- https://git.kernel.org/stable/c/ad1190744da9d812da55b76f2afce750afb0a3bd
- https://git.kernel.org/stable/c/b85f0e292f73f353eea915499604fbf50c8238b4
- https://git.kernel.org/stable/c/fdee7a0acc566c4194d40a501b8a1584e86cc208
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
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-50335
In the Linux kernel, the following vulnerability has been resolved: 9p: set req refcount to zero to avoid uninitialized usage When a new request is allocated, the refcount will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110): p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline] v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline] __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Below is a similar scenario, the scenario in the syzbot log looks more complicated than this one, but this patch can fix it. T21124 p9_read_work ======================== second trans ================================= p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount, 2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req) To fix it, we can initialize the refcount to zero before add to idr.
Modified: 2025-12-04
CVE-2022-50336
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add null pointer check to attr_load_runs_vcn
Some metadata files are handled before MFT. This adds a null pointer
check for some corner cases that could lead to NPD while reading these
metadata files for a malformed NTFS image.
[ 240.190827] BUG: kernel NULL pointer dereference, address: 0000000000000158
[ 240.191583] #PF: supervisor read access in kernel mode
[ 240.191956] #PF: error_code(0x0000) - not-present page
[ 240.192391] PGD 0 P4D 0
[ 240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
[ 240.193805] CPU: 0 PID: 242 Comm: mount Tainted: G B 5.19.0+ #17
[ 240.194477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 240.195152] RIP: 0010:ni_find_attr+0xae/0x300
[ 240.195679] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f
[ 240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286
[ 240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a
[ 240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60
[ 240.197877] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed
[ 240.198292] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000
[ 240.198647] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000
[ 240.199410] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000
[ 240.199895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 240.200314] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0
[ 240.200839] Call Trace:
[ 240.201104]
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-50342
In the Linux kernel, the following vulnerability has been resolved: floppy: Fix memory leak in do_floppy_init() A memory leak was reported when floppy_alloc_disk() failed in do_floppy_init(). unreferenced object 0xffff888115ed25a0 (size 8): comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 8 bytes): 00 ac 67 5b 81 88 ff ff ..g[.... backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<00000000a87bfa9e>] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180 [<000000006f02e8b1>] blk_mq_alloc_tag_set+0x573/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810fc30540 (size 32): comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<000000006b91eab4>] blk_mq_alloc_tag_set+0x393/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 If the floppy_alloc_disk() failed, disks of current drive will not be set, thus the lastest allocated set->tag cannot be freed in the error handling path. A simple call graph shown as below: floppy_module_init() floppy_init() do_floppy_init() for (drive = 0; drive < N_DRIVE; drive++) blk_mq_alloc_tag_set() blk_mq_alloc_tag_set_tags() blk_mq_realloc_tag_set_tags() # set->tag allocated floppy_alloc_disk() blk_mq_alloc_disk() # error occurred, disks failed to allocated ->out_put_disk: for (drive = 0; drive < N_DRIVE; drive++) if (!disks[drive][0]) # the last disks is not set and loop break break; blk_mq_free_tag_set() # the latest allocated set->tag leaked Fix this problem by free the set->tag of current drive before jump to error handling path. [efremov: added stable list, changed title]
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-50350
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix a race condition between login_work and the login thread In case a malicious initiator sends some random data immediately after a login PDU; the iscsi_target_sk_data_ready() callback will schedule the login_work and, at the same time, the negotiation may end without clearing the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are required to complete the login). The login has been completed but the login_work function will find the LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsit_conn structure will be freed, login_work will dereference a released socket structure and the kernel crashes. BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod] RIP: 0010:_raw_read_lock_bh+0x15/0x30 Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0 Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored. Add a comment to clearify the return values of iscsi_target_do_login()
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-50354
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix kfd_process_device_init_vm error handling Should only destroy the ib_mem and let process cleanup worker to free the outstanding BOs. Reset the pointer in pdd->qpd structure, to avoid NULL pointer access in process destroy worker. BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu] kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu] kfd_process_destroy_pdds+0x71/0x190 [amdgpu] kfd_process_wq_release+0x2a2/0x3b0 [amdgpu] process_one_work+0x2a1/0x600 worker_thread+0x39/0x3d0
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-50361
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: add missing unregister_netdev() in wilc_netdev_ifc_init()
Fault injection test reports this issue:
kernel BUG at net/core/dev.c:10731!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
Call Trace:
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-50369
In the Linux kernel, the following vulnerability has been resolved:
drm/vkms: Fix null-ptr-deref in vkms_release()
A null-ptr-deref is triggered when it tries to destroy the workqueue in
vkms->output.composer_workq in vkms_release().
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24
RIP: 0010:destroy_workqueue+0x2f/0x710
...
Call Trace:
- https://git.kernel.org/stable/c/0b8f390e2251191f1b179cc87f65d54c96565f0d
- https://git.kernel.org/stable/c/1f9836f95271e7acf016667eee0aeae3386f9645
- https://git.kernel.org/stable/c/2fe2a8f40c21161ffe7653cc234e7934db5b7cc5
- https://git.kernel.org/stable/c/57031c474c3a920ea73afeb5dc352e537f5793ee
- https://git.kernel.org/stable/c/596f1ba3987e601e31a5abf1f75ce1d2635aceac
Modified: 2026-01-14
CVE-2022-50371
In the Linux kernel, the following vulnerability has been resolved: led: qcom-lpg: Fix sleeping in atomic lpg_brighness_set() function can sleep, while led's brightness_set() callback must be non-blocking. Change LPG driver to use brightness_set_blocking() instead. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0 preempt_count: 101, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.1.0-rc1-00014-gbe99b089c6fc-dirty #85 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) Call trace: dump_backtrace.part.0+0xe4/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x88/0xb4 dump_stack+0x18/0x34 __might_resched+0x170/0x254 __might_sleep+0x48/0x9c __mutex_lock+0x4c/0x400 mutex_lock_nested+0x2c/0x40 lpg_brightness_single_set+0x40/0x90 led_set_brightness_nosleep+0x34/0x60 led_heartbeat_function+0x80/0x170 call_timer_fn+0xb8/0x340 __run_timers.part.0+0x20c/0x254 run_timer_softirq+0x3c/0x7c _stext+0x14c/0x578 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x164/0x170 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x64/0x68 cpuidle_enter_state+0xc8/0x380 cpuidle_enter+0x38/0x50 do_idle+0x244/0x2d0 cpu_startup_entry+0x24/0x30 rest_init+0x128/0x1a0 arch_post_acpi_subsys_init+0x0/0x18 start_kernel+0x6f4/0x734 __primary_switched+0xbc/0xc4
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-50383
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Can't set dst buffer to done when lat decode error Core thread will call v4l2_m2m_buf_done to set dst buffer done for lat architecture. If lat call v4l2_m2m_buf_done_and_job_finish to free dst buffer when lat decode error, core thread will access kernel NULL pointer dereference, then crash.
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-03-17
CVE-2022-50390
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED
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 ./include/drm/ttm/ttm_tt.h:122:26
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
Modified: 2026-01-14
CVE-2022-50391
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix memory leak in set_mempolicy_home_node system call When encountering any vma in the range with policy other than MPOL_BIND or MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on the policy just allocated with mpol_dup(). This allows arbitrary users to leak kernel memory.
Modified: 2026-01-14
CVE-2022-50392
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8183: fix refcount leak in mt8183_mt6358_ts3a227_max98357_dev_probe() The node returned by of_parse_phandle() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the error path in mt8183_mt6358_ts3a227_max98357_dev_probe().
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-50396
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_set_parms
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810c287f00 (size 256):
comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b
- https://git.kernel.org/stable/c/18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6
- https://git.kernel.org/stable/c/372ae77cf11d11fb118cbe2d37def9dd5f826abd
- https://git.kernel.org/stable/c/399ab7fe0fa0d846881685fd4e57e9a8ef7559f7
- https://git.kernel.org/stable/c/3abebc503a5148072052c229c6b04b329a420ecd
- https://git.kernel.org/stable/c/53af9c793f644d5841d84d8e0ad83bd7ab47f3e0
- https://git.kernel.org/stable/c/55ac68b53f1cea1926ee2313afc5d66b91daad71
- https://git.kernel.org/stable/c/6c55953e232ea668731091d111066521f3b7719b
- https://git.kernel.org/stable/c/7a6fb69bbcb21e9ce13bdf18c008c268874f0480
- https://git.kernel.org/stable/c/7c183dc0af472dec33d2c0786a5e356baa8cad19
- https://git.kernel.org/stable/c/b314f6c3512108d7a656c5caf07c82d1bbbdc0f1
- https://git.kernel.org/stable/c/c4de6057e7c6654983acb63d939d26ac0d7bbf39
- https://git.kernel.org/stable/c/facc4405e8b7407e03216207b1d1d640127de0c8
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-03-17
CVE-2022-50404
In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: release buffer when fbcon_do_set_font() failed syzbot is reporting memory leak at fbcon_do_set_font() [1], for commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") missed that the buffer might be newly allocated by fbcon_set_font().
- https://git.kernel.org/stable/c/06926607b9fddf7ce8017493899ce6eb7e79a123
- https://git.kernel.org/stable/c/3c3bfb8586f848317ceba5d777e11204ba3e5758
- https://git.kernel.org/stable/c/5a341810a22e51c3a7a108f7896b5fd58d44d127
- https://git.kernel.org/stable/c/88ec6d11052da527eb9268831e7a9bc5bbad02f6
- https://git.kernel.org/stable/c/a609bfc1e644a8467cb31945ed1488374ebdc013
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-50407
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - increase the memory of local variables Increase the buffer to prevent stack overflow by fuzz test. The maximum length of the qos configuration buffer is 256 bytes. Currently, the value of the 'val buffer' is only 32 bytes. The sscanf does not check the dest memory length. So the 'val buffer' may stack overflow.
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-50416
In the Linux kernel, the following vulnerability has been resolved: irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init() If of_iomap() failed, 'aic' should be freed before return. Otherwise there is a memory leak.
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-50420
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/hpre - fix resource leak in remove process In hpre_remove(), when the disable operation of qm sriov failed, the following logic should continue to be executed to release the remaining resources that have been allocated, instead of returning directly, otherwise there will be resource leakage.
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-20
CVE-2022-50426
In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_dsp_rproc: Add mutex protection for workqueue The workqueue may execute late even after remoteproc is stopped or stopping, some resources (rpmsg device and endpoint) have been released in rproc_stop_subdevices(), then rproc_vq_interrupt() accessing these resources will cause kennel dump. Call trace: virtqueue_add_split+0x1ac/0x560 virtqueue_add_inbuf+0x4c/0x60 rpmsg_recv_done+0x15c/0x294 vring_interrupt+0x6c/0xa4 rproc_vq_interrupt+0x30/0x50 imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc] process_one_work+0x1d0/0x354 worker_thread+0x13c/0x470 kthread+0x154/0x160 ret_from_fork+0x10/0x20 Add mutex protection in imx_dsp_rproc_vq_work(), if the state is not running, then just skip calling rproc_vq_interrupt(). Also the flush workqueue operation can't be added in rproc stop for the same reason. The call sequence is rproc_shutdown -> rproc_stop ->rproc_stop_subdevices ->rproc->ops->stop() ->imx_dsp_rproc_stop ->flush_work -> rproc_vq_interrupt The resource needed by rproc_vq_interrupt has been released in rproc_stop_subdevices, so flush_work is not safe to be called in imx_dsp_rproc_stop.
Modified: 2026-01-20
CVE-2022-50428
In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one errors in fast-commit block filling Due to several different off-by-one errors, or perhaps due to a late change in design that wasn't fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries: - tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn't seem to happen currently.) - tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks. Also, strangely these constraints don't apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...). Given that this all seems to be a bug, let's fix it by just filling blocks with tlv entries in the natural way. Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.
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-20
CVE-2022-50442
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate buffer length while parsing index
indx_read is called when we have some NTFS directory operations that
need more information from the index buffers. This adds a sanity check
to make sure the returned index buffer length is legit, or we may have
some out-of-bound memory accesses.
[ 560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320
[ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245
[ 560.898760]
[ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37
[ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 560.900170] Call Trace:
[ 560.900407]
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-50447
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Fix crash on hci_create_cis_sync
When attempting to connect multiple ISO sockets without using
DEFER_SETUP may result in the following crash:
BUG: KASAN: null-ptr-deref in hci_create_cis_sync+0x18b/0x2b0
Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50
CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted
6.0.0-rc7-02243-gb84a13ff4eda #4373
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS 1.16.0-1.fc36 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
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-50451
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix memory leak on ntfs_fill_super() error path
syzbot reported kmemleak as below:
BUG: memory leak
unreferenced object 0xffff8880122f1540 (size 32):
comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 ed ff ed ff 00 00 00 00 ................
backtrace:
[
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-50457
In the Linux kernel, the following vulnerability has been resolved:
mtd: core: Fix refcount error in del_mtd_device()
del_mtd_device() will call of_node_put() to mtd_get_of_node(mtd), which
is mtd->dev.of_node. However, memset(&mtd->dev, 0) is called before
of_node_put(). As the result, of_node_put() won't do anything in
del_mtd_device(), and causes the refcount leak.
del_mtd_device()
memset(&mtd->dev, 0, sizeof(mtd->dev) # clear mtd->dev
of_node_put()
mtd_get_of_node(mtd) # mtd->dev is cleared, can't locate of_node
# of_node_put(NULL) won't do anything
Fix the error by caching the pointer of the device_node.
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry: attach
overlay node /spi/spi-sram@0
CPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54
0d8a1edddf51f172ff5226989a7565c6313b08e2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
Call Trace:
Modified: 2026-01-16
CVE-2022-50461
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: Fix PM runtime leakage in am65_cpsw_nuss_ndo_slave_open() Ensure pm_runtime_put() is issued in error path.
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-50464
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2() As comment of pci_get_device() says, it returns a pci_device with its refcount increased. We need to call pci_dev_put() to decrease the refcount. Save the return value of pci_get_device() and call pci_dev_put() to decrease the refcount.
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-50472
In the Linux kernel, the following vulnerability has been resolved: IB/mad: Don't call to function that might sleep while in atomic context Tracepoints are not allowed to sleep, as such the following splat is generated due to call to ib_query_pkey() in atomic context. WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220 CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core] ib_mad_recv_done+0x48b/0xc10 [ib_core] ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core] __ib_process_cq+0x91/0x1c0 [ib_core] ib_cq_poll_work+0x26/0x80 [ib_core] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 78ba8509d3830a16 ]---
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-50475
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Make sure "ib_port" is valid when access sysfs node The "ib_port" structure must be set before adding the sysfs kobject, and reset after removing it, otherwise it may crash when accessing the sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr : port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27: ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 : ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8 __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861)
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-50477
In the Linux kernel, the following vulnerability has been resolved: rtc: class: Fix potential memleak in devm_rtc_allocate_device() devm_rtc_allocate_device() will alloc a rtc_device first, and then run dev_set_name(). If dev_set_name() failed, the rtc_device will memleak. Move devm_add_action_or_reset() in front of dev_set_name() to prevent memleak. unreferenced object 0xffff888110a53000 (size 2048): comm "python3", pid 470, jiffies 4296078308 (age 58.882s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0...... 08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0.............. backtrace: [<000000004aac0364>] kmalloc_trace+0x21/0x110 [<000000000ff02202>] devm_rtc_allocate_device+0xd4/0x400 [<000000001bdf5639>] devm_rtc_device_register+0x1a/0x80 [<00000000351bf81c>] rx4581_probe+0xdd/0x110 [rtc_rx4581] [<00000000f0eba0ae>] spi_probe+0xde/0x130 [<00000000bff89ee8>] really_probe+0x175/0x3f0 [<00000000128e8d84>] __driver_probe_device+0xe6/0x170 [<00000000ee5bf913>] device_driver_attach+0x32/0x80 [<00000000f3f28f92>] bind_store+0x10b/0x1a0 [<000000009ff812d8>] drv_attr_store+0x49/0x70 [<000000008139c323>] sysfs_kf_write+0x8d/0xb0 [<00000000b6146e01>] kernfs_fop_write_iter+0x214/0x2d0 [<00000000ecbe3895>] vfs_write+0x61a/0x7d0 [<00000000aa2196ea>] ksys_write+0xc8/0x190 [<0000000046a600f5>] do_syscall_64+0x37/0x90 [<00000000541a336f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
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-01-23
CVE-2022-50483
In the Linux kernel, the following vulnerability has been resolved: net: enetc: avoid buffer leaks on xdp_do_redirect() failure Before enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software BD in the RX ring between index orig_i and i can have one of 2 refcount values on its page. We are the owner of the current buffer that is being processed, so the refcount will be at least 1. If the current owner of the buffer at the diametrically opposed index in the RX ring (i.o.w, the other half of this page) has not yet called kfree(), this page's refcount could even be 2. enetc_page_reusable() in enetc_flip_rx_buff() tests for the page refcount against 1, and [ if it's 2 ] does not attempt to reuse it. But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call, the page refcount can have one of 3 values. It can also be 0, if there is no owner of the other page half, and xdp_do_redirect() for this buffer ran so far that it triggered a flush of the devmap/cpumap bulk queue, and the consumers of those bulk queues also freed the buffer, all by the time xdp_do_redirect() returns the execution back to enetc. This is the reason why enetc_flip_rx_buff() is called before xdp_do_redirect(), but there is a big flaw with that reasoning: enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the enetc_page_reusable() branch, and if xdp_do_redirect() returns an error, we call enetc_xdp_free(), which does not deal gracefully with that. In fact, what happens is quite special. The page refcounts start as 1. enetc_flip_rx_buff() figures they're reusable, transfers these rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and bumps the refcount to 2. When xdp_do_redirect() later returns an error, we call the no-op enetc_xdp_free(), but we still haven't lost the reference to that page. A copy of it is still at rx_ring->next_to_alloc, but that has refcount 2 (and there are no concurrent owners of it in flight, to drop the refcount). What really kills the system is when we'll flip the rx_swbd->page the second time around. With an updated refcount of 2, the page will not be reusable and we'll really leak it. Then enetc_new_page() will have to allocate more pages, which will then eventually leak again on further errors from xdp_do_redirect(). The problem, summarized, is that we zeroize rx_swbd->page before we're completely done with it, and this makes it impossible for the error path to do something with it. Since the packet is potentially multi-buffer and therefore the rx_swbd->page is potentially an array, manual passing of the old pointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit difficult. For the sake of going with a simple solution, we accept the possibility of racing with xdp_do_redirect(), and we move the flip procedure to execute only on the redirect success path. By racing, I mean that the page may be deemed as not reusable by enetc (having a refcount of 0), but there will be no leak in that case, either. Once we accept that, we have something better to do with buffers on XDP_REDIRECT failure. Since we haven't performed half-page flipping yet, we won't, either (and this way, we can avoid enetc_xdp_free() completely, which gives the entire page to the slab allocator). Instead, we'll call enetc_xdp_drop(), which will recycle this half of the buffer back to the RX ring.
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-03-25
CVE-2022-50488
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10: ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | Λ | Λ | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | Λ | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) Λ |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic.
- https://git.kernel.org/stable/c/094f3d9314d67691cb21ba091c1b528f6e3c4893
- https://git.kernel.org/stable/c/5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a
- https://git.kernel.org/stable/c/64dc8c732f5c2b406cc752e6aaa1bd5471159cab
- https://git.kernel.org/stable/c/761564d93c8265f65543acf0a576b32d66bfa26a
- https://git.kernel.org/stable/c/b22fd72bfebda3956efc4431b60ddfc0a51e03e0
Modified: 2026-01-23
CVE-2022-50493
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash when I/O abort times out While performing CPU hotplug, a crash with the following stack was seen: Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0 On abort timeout, completion was called without checking if the I/O was already completed. Verify that I/O and abort request are indeed outstanding before attempting completion.
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-25
CVE-2022-50507
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate data run offset
This adds sanity checks for data run offset. We should make sure data
run offset is legit before trying to unpack them, otherwise we may
encounter use-after-free or some unexpected memory access behaviors.
[ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570
[ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240
[ 82.941670]
[ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15
[ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 82.943720] Call Trace:
[ 82.944204]
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-50518
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix locking in pdc_iodc_print() firmware call Utilize pdc_lock spinlock to protect parallel modifications of the iodc_dbuf[] buffer, check length to prevent buffer overflow of iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong indentings.
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-50524
In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Check return value after calling platform_get_resource() platform_get_resource() may return NULL pointer, we need check its return value to avoid null-ptr-deref in resource_size().
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-50527
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix size validation for non-exclusive domains (v4) Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for the requested memory exists, else we get a kernel oops when dereferencing "man". v2: Make the patch standalone, i.e. not dependent on local patches. v3: Preserve old behaviour and just check that the manager pointer is not NULL. v4: Complain if GTT domain requested and it is uninitialized--most likely a bug.
Modified: 2026-03-17
CVE-2022-50528
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix memory leakage This patch fixes potential memory leakage and seg fault in _gpuvm_import_dmabuf() function
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-50533
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: mlme: fix null-ptr deref on failed assoc If association to an AP without a link 0 fails, then we crash in tracing because it assumes that either ap_mld_addr or link 0 BSS is valid, since we clear sdata->vif.valid_links and then don't add the ap_mld_addr to the struct. Since we clear also sdata->vif.cfg.ap_addr, keep a local copy of it and assign it earlier, before clearing valid_links, to fix this.
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-03-17
CVE-2022-50535
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential null-deref in dm_resume [Why] Fixing smatch error: dm_resume() error: we previously assumed 'aconnector->dc_link' could be null [How] Check if dc_link null at the beginning of the loop, so further checks can be dropped.
- https://git.kernel.org/stable/c/00b655fa96b4e941351cc4bf5ca755a65ae94a8e
- https://git.kernel.org/stable/c/7a7175a2cd84b7874bebbf8e59f134557a34161b
- https://git.kernel.org/stable/c/8e365f1bd672cc9320a936f6ae6f8087aa40e9bc
- https://git.kernel.org/stable/c/9f73793b81637c60ccc83cc508645310b8ab7d80
- https://git.kernel.org/stable/c/bb9a5562beb982aa5ebb73c521c49596ff8b8030
- https://git.kernel.org/stable/c/d236103782de25736996a45bd36ac2a89bdc93c6
- https://git.kernel.org/stable/c/fd79b61af2782f8875c78f50cdb8630ec43e2990
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-50539
In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: omap4-common: Fix refcount leak bug In omap4_sram_init(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
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-50543
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix mr->map double free
rxe_mr_cleanup() which tries to free mr->map again will be called when
rxe_mr_init_user() fails:
CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
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-50546
In the Linux kernel, the following vulnerability has been resolved: ext4: fix uninititialized value in 'ext4_evict_inode' Syzbot found the following issue: ===================================================== BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c:664 iput_final fs/inode.c:1747 [inline] iput+0x985/0xdd0 fs/inode.c:1773 __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa0 __do_sys_mknodat fs/namei.c:3992 [inline] __se_sys_mknodat fs/namei.c:3989 [inline] __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c:1992 [inline] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [inline] slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [inline] ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode+0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/inode.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+0x62a/0x870 fs/namei.c:4035 do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [inline] __se_sys_mkdirat fs/namei.c:4073 [inline] __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 ===================================================== Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed before set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after 6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' which will lead to access uninit-value. To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'.
- https://git.kernel.org/stable/c/091f85db4c3fb1734a6d7fb4777a2b2831da6631
- https://git.kernel.org/stable/c/3c31d8d3ad95aef8cc17a4fcf317e46217148439
- https://git.kernel.org/stable/c/56491d60ddca9c697d885394cb0173675b9ab81f
- https://git.kernel.org/stable/c/7ea71af94eaaaf6d9aed24bc94a05b977a741cb9
- https://git.kernel.org/stable/c/9f966e021c20caae639dd0e404c8761e8281a2c4
- https://git.kernel.org/stable/c/e431b4fb1fb8c2654b808086e9747a000adb9655
- https://git.kernel.org/stable/c/f0bffdcc7cb14598af2aa706f1e0f2a9054154ba
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-50548
In the Linux kernel, the following vulnerability has been resolved: media: i2c: hi846: Fix memory leak in hi846_parse_dt() If any of the checks related to the supported link frequencies fail, then the V4L2 fwnode resources don't get released before returning, which leads to a memleak. Fix this by properly freeing the V4L2 fwnode data in a designated label.
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-50550
In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on add_disk() failures When a gendisk is successfully initialized but add_disk() fails such as when a loop device has invalid number of minor device numbers specified, blkcg_init_disk() is called during init and then blkcg_exit_disk() during error handling. Unfortunately, iolatency gets initialized in the former but doesn't get cleaned up in the latter. This is because, in non-error cases, the cleanup is performed by del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos policies, iolatency being one of them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt and iocost, but not so for iolatency as it gets initialized before add_disk() is called. It is desirable to lazy-init rq_qos policies because they are optional features and add to hot path overhead once initialized - each IO has to walk all the registered rq_qos policies. So, we want to switch iolatency to lazy init too. However, that's a bigger change. As a fix for the immediate problem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk(). This is safe because duplicate calls to rq_qos_exit() become noop's.
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: 2026-02-06
CVE-2022-50554
In the Linux kernel, the following vulnerability has been resolved: blk-mq: avoid double ->queue_rq() because of early timeout David Jeffery found one double ->queue_rq() issue, so far it can be triggered in VM use case because of long vmexit latency or preempt latency of vCPU pthread or long page fault in vCPU pthread, then block IO req could be timed out before queuing the request to hardware but after calling blk_mq_start_request() during ->queue_rq(), then timeout handler may handle it by requeue, then double ->queue_rq() is caused, and kernel panic. So far, it is driver's responsibility to cover the race between timeout and completion, so it seems supposed to be solved in driver in theory, given driver has enough knowledge. But it is really one common problem, lots of driver could have similar issue, and could be hard to fix all affected drivers, even it isn't easy for driver to handle the race. So David suggests this patch by draining in-progress ->queue_rq() for solving this issue.
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: 2024-11-21
CVE-2023-0210
A bug affects the Linux kernel’s ksmbd NTLMv2 authentication and is known to crash the OS immediately in Linux-based systems.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707
- https://github.com/cifsd-team/ksmbd/commit/8824b7af409f51f1316e92e9887c2fd48c0b26d6
- https://security.netapp.com/advisory/ntap-20230517-0002/
- https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/
- https://www.openwall.com/lists/oss-security/2023/01/04/1
- https://www.openwall.com/lists/oss-security/2023/01/11/1
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707
- https://github.com/cifsd-team/ksmbd/commit/8824b7af409f51f1316e92e9887c2fd48c0b26d6
- https://security.netapp.com/advisory/ntap-20230517-0002/
- https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/
- https://www.openwall.com/lists/oss-security/2023/01/04/1
- https://www.openwall.com/lists/oss-security/2023/01/11/1
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: 2025-11-04
CVE-2023-0386
A flaw was found in the Linux kernel, where unauthorized access to the execution of the setuid file with capabilities was found in the Linux kernel’s OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid mapping bug allows a local user to escalate their privileges on the system.
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20230420-0004/
- https://www.debian.org/security/2023/dsa-5402
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20230420-0004/
- https://www.debian.org/security/2023/dsa-5402
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-0386
Modified: 2024-11-21
CVE-2023-0458
A speculative pointer dereference problem exists in the Linux Kernel on the do_prlimit() function. The resource argument value is controlled and is used in pointer arithmetic for the 'rlim' variable and can be used to leak the contents. We recommend upgrading past version 6.1.8 or commit 739790605705ddcf18f21782b9c99ad7d53a8c11
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/kernel/sys.c?id=v6.1.8&id2=v6.1.7
- https://github.com/torvalds/linux/commit/739790605705ddcf18f21782b9c99ad7d53a8c11
- 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/stable/linux.git/diff/kernel/sys.c?id=v6.1.8&id2=v6.1.7
- https://github.com/torvalds/linux/commit/739790605705ddcf18f21782b9c99ad7d53a8c11
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
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: 2024-11-21
CVE-2023-1077
In the Linux kernel, pick_next_rt_entity() may return a type confused entry, not detected by the BUG_ON condition, as the confused entry will not be NULL, but list_head.The buggy error condition would lead to a type confused entry with the list head,which would then be used as a type confused sched_rt_entity,causing memory corruption.
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230511-0002/
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230511-0002/
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-04-23
CVE-2023-1118
A flaw use after free in the Linux kernel integrated infrared receiver/transceiver driver was found in the way user detaching rc device. A local user could use this flaw to crash the system or potentially escalate their privileges on the system.
- https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17
- 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-20230413-0003/
- https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17
- 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-20230413-0003/
Modified: 2025-03-20
CVE-2023-1194
An out-of-bounds (OOB) memory read flaw was found in parse_lease_state in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. When an attacker sends the CREATE command with a malformed payload to KSMBD, due to a missing check of `NameOffset` in the `parse_lease_state()` function, the `create_context` object can access invalid memory.
- https://access.redhat.com/security/cve/CVE-2023-1194
- https://bugzilla.redhat.com/show_bug.cgi?id=2154176
- https://security.netapp.com/advisory/ntap-20231221-0006/
- https://www.spinics.net/lists/stable-commits/msg303065.html
- https://access.redhat.com/security/cve/CVE-2023-1194
- https://bugzilla.redhat.com/show_bug.cgi?id=2154176
- https://security.netapp.com/advisory/ntap-20231221-0006/
- https://www.spinics.net/lists/stable-commits/msg303065.html
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-1380
A slab-out-of-bound read problem was found in brcmf_get_assoc_ies in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when assoc_info->req_len data is bigger than the size of the buffer, defined as WL_EXTRA_BUF_MAX, leading to a denial of service.
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2177883
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/linux-wireless/20230309104457.22628-1-jisoo.jang%40yonsei.ac.kr/T/#u
- https://security.netapp.com/advisory/ntap-20230511-0001/
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/03/14/1
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2177883
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/linux-wireless/20230309104457.22628-1-jisoo.jang%40yonsei.ac.kr/T/#u
- https://security.netapp.com/advisory/ntap-20230511-0001/
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/03/14/1
Modified: 2025-02-20
CVE-2023-1583
A NULL pointer dereference was found in io_file_bitmap_get in io_uring/filetable.c in the io_uring sub-component in the Linux Kernel. When fixed files are unregistered, some context information (file_alloc_{start,end} and alloc_hint) is not cleared. A subsequent request that has auto index selection enabled via IORING_FILE_INDEX_ALLOC can cause a NULL pointer dereference. An unprivileged user can use the flaw to cause a system crash.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=02a4d923e4400a36d340ea12d8058f69ebf3a383
- https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=io_uring-6.3&id=761efd55a0227aca3a69deacdaa112fffd44fe37
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=02a4d923e4400a36d340ea12d8058f69ebf3a383
- https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=io_uring-6.3&id=761efd55a0227aca3a69deacdaa112fffd44fe37
Modified: 2025-02-13
CVE-2023-1611
A use-after-free flaw was found in btrfs_search_slot in fs/btrfs/ctree.c in btrfs in the Linux Kernel.This flaw allows an attacker to crash the system and possibly cause a kernel information lea
- https://bugzilla.redhat.com/show_bug.cgi?id=2181342
- https://github.com/torvalds/linux/commit/2f1a6be12ab6c8470d5776e68644726c94257c54
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5QCM6XO4HSPLGR3DFYWFRIA3GCBIHZR4/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZWECAZ7V7EPSXMINO6Q6KWNKDY2CO6ZW/
- https://lore.kernel.org/linux-btrfs/35b9a70650ea947387cf352914a8774b4f7e8a6f.1679481128.git.fdmanana%40suse.com/
- https://bugzilla.redhat.com/show_bug.cgi?id=2181342
- https://github.com/torvalds/linux/commit/2f1a6be12ab6c8470d5776e68644726c94257c54
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5QCM6XO4HSPLGR3DFYWFRIA3GCBIHZR4/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZWECAZ7V7EPSXMINO6Q6KWNKDY2CO6ZW/
- https://lore.kernel.org/linux-btrfs/35b9a70650ea947387cf352914a8774b4f7e8a6f.1679481128.git.fdmanana%40suse.com/
Modified: 2025-02-18
CVE-2023-1652
A use-after-free flaw was found in nfsd4_ssc_setup_dul in fs/nfsd/nfs4proc.c in the NFS filesystem in the Linux Kernel. This issue could allow a local attacker to crash the system or it may lead to a kernel information leak problem.
Modified: 2025-02-14
CVE-2023-1670
A flaw use after free in the Linux kernel Xircom 16-bit PCMCIA (PC-card) Ethernet driver was found.A local user could use this flaw to crash the system or potentially escalate their privileges on the system.
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/all/20230316161526.1568982-1-zyytlz.wz%40163.com/
- https://security.netapp.com/advisory/ntap-20230526-0010/
- 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/20230316161526.1568982-1-zyytlz.wz%40163.com/
- https://security.netapp.com/advisory/ntap-20230526-0010/
Modified: 2025-02-13
CVE-2023-1829
A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation. The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure. A local attacker user can use this vulnerability to elevate its privileges to root. We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- 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-20230601-0001/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- 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-20230601-0001/
Modified: 2024-11-21
CVE-2023-1989
A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. In this flaw, a call to btsdio_remove with an unfinished job, may cause a race problem leading to a UAF on hdev devices.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=f132c2d13088
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230601-0004/
- https://www.debian.org/security/2023/dsa-5492
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=f132c2d13088
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230601-0004/
- https://www.debian.org/security/2023/dsa-5492
Modified: 2024-11-21
CVE-2023-2156
A flaw was found in the networking subsystem of the Linux kernel within the handling of the RPL protocol. This issue results from the lack of proper handling of user-supplied data, which can lead to an assertion failure. This may allow an unauthenticated remote attacker to create a denial of service condition on the system.
- http://www.openwall.com/lists/oss-security/2023/05/17/8
- http://www.openwall.com/lists/oss-security/2023/05/17/9
- http://www.openwall.com/lists/oss-security/2023/05/18/1
- http://www.openwall.com/lists/oss-security/2023/05/19/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2196292
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://security.netapp.com/advisory/ntap-20230622-0001/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5453
- https://www.zerodayinitiative.com/advisories/ZDI-23-547/
- http://www.openwall.com/lists/oss-security/2023/05/17/8
- http://www.openwall.com/lists/oss-security/2023/05/17/9
- http://www.openwall.com/lists/oss-security/2023/05/18/1
- http://www.openwall.com/lists/oss-security/2023/05/19/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2196292
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://security.netapp.com/advisory/ntap-20230622-0001/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5453
- https://www.zerodayinitiative.com/advisories/ZDI-23-547/
Modified: 2024-11-21
CVE-2023-2163
Incorrect verifier pruning in BPF in Linux Kernel >=5.4 leads to unsafe code paths being incorrectly marked as safe, resulting in arbitrary read/write in kernel memory, lateral privilege escalation, and container escape.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71b547f561247897a0a14f3082730156c0533fed
- https://bughunters.google.com/blog/6303226026131456/a-deep-dive-into-cve-2023-2163-how-we-found-and-fixed-an-ebpf-linux-kernel-vulnerability
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71b547f561247897a0a14f3082730156c0533fed
Modified: 2024-11-21
CVE-2023-2235
A use-after-free vulnerability in the Linux Kernel Performance Events system can be exploited to achieve local privilege escalation. The perf_group_detach function did not check the event's siblings' attach_state before calling add_event_to_groups(), but remove_on_exec made it possible to call list_del_event() on before detaching from their group, making it possible to use a dangling pointer causing a use-after-free vulnerability. We recommend upgrading past commit fd0815f632c24878e325821943edccc7fde947a2.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd0815f632c24878e325821943edccc7fde947a2
- https://kernel.dance/fd0815f632c24878e325821943edccc7fde947a2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd0815f632c24878e325821943edccc7fde947a2
- https://kernel.dance/fd0815f632c24878e325821943edccc7fde947a2
- https://security.netapp.com/advisory/ntap-20230609-0002/
Modified: 2025-03-20
CVE-2023-22997
In the Linux kernel before 6.1.2, kernel/module/decompress.c misinterprets the module_get_next_page return value (expects it to be NULL in the error case, whereas it is actually an error pointer).
Modified: 2025-03-20
CVE-2023-23454
cbq_classify in net/sched/sch_cbq.c in the Linux kernel through 6.1.4 allows attackers to cause a denial of service (slab-out-of-bounds read) because of type confusion (non-negative numbers can sometimes indicate a TC_ACT_SHOT condition rather than valid classification results).
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.debian.org/security/2023/dsa-5324
- https://www.openwall.com/lists/oss-security/2023/01/10/1
- https://www.openwall.com/lists/oss-security/2023/01/10/4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.debian.org/security/2023/dsa-5324
- https://www.openwall.com/lists/oss-security/2023/01/10/1
- https://www.openwall.com/lists/oss-security/2023/01/10/4
Modified: 2025-03-20
CVE-2023-23455
atm_tc_enqueue in net/sched/sch_atm.c in the Linux kernel through 6.1.4 allows attackers to cause a denial of service because of type confusion (non-negative numbers can sometimes indicate a TC_ACT_SHOT condition rather than valid classification results).
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a2965c7be0522eaa18808684b7b82b248515511b
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.debian.org/security/2023/dsa-5324
- https://www.openwall.com/lists/oss-security/2023/01/10/1
- https://www.openwall.com/lists/oss-security/2023/01/10/4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a2965c7be0522eaa18808684b7b82b248515511b
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.debian.org/security/2023/dsa-5324
- https://www.openwall.com/lists/oss-security/2023/01/10/1
- https://www.openwall.com/lists/oss-security/2023/01/10/4
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: 2025-05-05
CVE-2023-25012
The Linux kernel through 6.1.9 has a Use-After-Free in bigben_remove in drivers/hid/hid-bigbenff.c via a crafted USB device because the LED controllers remain registered for too long.
- http://www.openwall.com/lists/oss-security/2023/02/02/1
- http://www.openwall.com/lists/oss-security/2023/11/05/1
- https://bugzilla.suse.com/show_bug.cgi?id=1207560
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d2a2fd844ec7da70d19fabb482304fd1e0595b
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=76ca8da989c7d97a7f76c75d475fe95a584439d7
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9fefb6201c4f8dd9f58c581b2a66e5cde2895ea2
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lore.kernel.org/all/20230125-hid-unregister-leds-v1-1-9a5192dcef16%40diag.uniroma1.it/
- https://seclists.org/oss-sec/2023/q1/53
- http://www.openwall.com/lists/oss-security/2023/02/02/1
- http://www.openwall.com/lists/oss-security/2023/11/05/1
- https://bugzilla.suse.com/show_bug.cgi?id=1207560
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d2a2fd844ec7da70d19fabb482304fd1e0595b
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=76ca8da989c7d97a7f76c75d475fe95a584439d7
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9fefb6201c4f8dd9f58c581b2a66e5cde2895ea2
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lore.kernel.org/all/20230125-hid-unregister-leds-v1-1-9a5192dcef16%40diag.uniroma1.it/
- https://seclists.org/oss-sec/2023/q1/53
Modified: 2025-05-05
CVE-2023-26242
afu_mmio_region_get_by_offset in drivers/fpga/dfl-afu-region.c in the Linux kernel through 6.1.12 has an integer overflow.
- https://bugzilla.suse.com/show_bug.cgi?id=1208518
- https://patchwork.kernel.org/project/linux-fpga/patch/20230206054326.89323-1-k1rh4.lee%40gmail.com
- https://security.netapp.com/advisory/ntap-20230406-0002/
- https://bugzilla.suse.com/show_bug.cgi?id=1208518
- https://patchwork.kernel.org/project/linux-fpga/patch/20230206054326.89323-1-k1rh4.lee%40gmail.com
- https://security.netapp.com/advisory/ntap-20230406-0002/
Modified: 2025-05-05
CVE-2023-26544
In the Linux kernel 6.0.8, there is a use-after-free in run_unpack in fs/ntfs3/run.c, related to a difference between NTFS sector size and media sector size.
- https://bugzilla.suse.com/show_bug.cgi?id=1208697
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=887bfc546097fbe8071dac13b2fef73b77920899
- https://lkml.org/lkml/2023/2/20/128
- https://security.netapp.com/advisory/ntap-20230316-0010/
- https://bugzilla.suse.com/show_bug.cgi?id=1208697
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=887bfc546097fbe8071dac13b2fef73b77920899
- https://lkml.org/lkml/2023/2/20/128
- https://security.netapp.com/advisory/ntap-20230316-0010/
Modified: 2025-06-25
CVE-2023-26545
In the Linux kernel before 6.1.13, there is a double free in net/mpls/af_mpls.c upon an allocation failure (for registering the sysctl table under a new location) during the renaming of a device.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.13
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fda6c89fe3d9aca073495a664e1d5aea28cd4377
- https://github.com/torvalds/linux/commit/fda6c89fe3d9aca073495a664e1d5aea28cd4377
- 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-20230316-0009/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.13
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fda6c89fe3d9aca073495a664e1d5aea28cd4377
- https://github.com/torvalds/linux/commit/fda6c89fe3d9aca073495a664e1d5aea28cd4377
- 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-20230316-0009/
Modified: 2025-05-05
CVE-2023-26606
In the Linux kernel 6.0.8, there is a use-after-free in ntfs_trim_fs in fs/ntfs3/bitmap.c.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=557d19675a470bb0a98beccec38c5dc3735c20fa
- https://lkml.org/lkml/2023/2/20/860
- https://security.netapp.com/advisory/ntap-20230316-0010/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=557d19675a470bb0a98beccec38c5dc3735c20fa
- https://lkml.org/lkml/2023/2/20/860
- https://security.netapp.com/advisory/ntap-20230316-0010/
Modified: 2025-05-05
CVE-2023-28466
do_tls_getsockopt in net/tls/tls_main.c in the Linux kernel through 6.2.6 lacks a lock_sock call, leading to a race condition (with a resultant use-after-free or NULL pointer dereference).
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=49c47cc21b5b7a3d8deb18fc57b0aa2ab1286962
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://security.netapp.com/advisory/ntap-20230427-0006/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=49c47cc21b5b7a3d8deb18fc57b0aa2ab1286962
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://security.netapp.com/advisory/ntap-20230427-0006/
Modified: 2025-02-13
CVE-2023-3090
A heap out-of-bounds write vulnerability in the Linux Kernel ipvlan network driver can be exploited to achieve local privilege escalation. The out-of-bounds write is caused by missing skb->cb initialization in the ipvlan network driver. The vulnerability is reachable if CONFIG_IPVLAN is enabled. We recommend upgrading past commit 90cbed5247439a966b645b34eb0a2e037836ea8e.
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbed5247439a966b645b34eb0a2e037836ea8e
- https://kernel.dance/90cbed5247439a966b645b34eb0a2e037836ea8e
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230731-0002/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbed5247439a966b645b34eb0a2e037836ea8e
- https://kernel.dance/90cbed5247439a966b645b34eb0a2e037836ea8e
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230731-0002/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
Modified: 2024-11-21
CVE-2023-31248
Linux Kernel nftables Use-After-Free Local Privilege Escalation Vulnerability; `nft_chain_lookup_byid()` failed to check whether a chain was active and CAP_NET_ADMIN is in any user or network namespace
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://www.openwall.com/lists/oss-security/2023/07/05/2
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/
- https://lore.kernel.org/netfilter-devel/20230705121627.GC19489@breakpoint.cc/T/
- https://security.netapp.com/advisory/ntap-20240201-0001/
- https://www.debian.org/security/2023/dsa-5453
- https://www.openwall.com/lists/oss-security/2023/07/05/2
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://www.openwall.com/lists/oss-security/2023/07/05/2
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/
- https://lore.kernel.org/netfilter-devel/20230705121627.GC19489@breakpoint.cc/T/
- https://security.netapp.com/advisory/ntap-20240201-0001/
- https://www.debian.org/security/2023/dsa-5453
- https://www.openwall.com/lists/oss-security/2023/07/05/2
Modified: 2025-03-11
CVE-2023-3141
A use-after-free flaw was found in r592_remove in drivers/memstick/host/r592.c in media access in the Linux Kernel. This flaw allows a local attacker to crash the system at device disconnect, possibly leading to a kernel information leak.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63264422785021704c39b38f65a78ab9e4a186d7
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/lkml/CAPDyKFoV9aZObZ5GBm0U_-UVeVkBN_rAG-kH3BKoP4EXdYM4bw%40mail.gmail.com/t/
- https://security.netapp.com/advisory/ntap-20230706-0004/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63264422785021704c39b38f65a78ab9e4a186d7
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/lkml/CAPDyKFoV9aZObZ5GBm0U_-UVeVkBN_rAG-kH3BKoP4EXdYM4bw%40mail.gmail.com/t/
- https://security.netapp.com/advisory/ntap-20230706-0004/
Modified: 2024-11-21
CVE-2023-31436
qfq_change_class in net/sched/sch_qfq.c in the Linux kernel before 6.2.13 allows an out-of-bounds write because lmax can exceed QFQ_MIN_LMAX.
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13
- https://github.com/torvalds/linux/commit/3037933448f60f9acb705997eae62013ecb81e0d
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://security.netapp.com/advisory/ntap-20230609-0001/
- https://www.debian.org/security/2023/dsa-5402
- https://www.spinics.net/lists/stable-commits/msg294885.html
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13
- https://github.com/torvalds/linux/commit/3037933448f60f9acb705997eae62013ecb81e0d
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://security.netapp.com/advisory/ntap-20230609-0001/
- https://www.debian.org/security/2023/dsa-5402
- https://www.spinics.net/lists/stable-commits/msg294885.html
Modified: 2025-05-05
CVE-2023-32233
In the Linux kernel through 6.3.1, a use-after-free in Netfilter nf_tables when processing batch requests can be abused to perform arbitrary read and write operations on kernel memory. Unprivileged local users can obtain root privileges. This occurs because anonymous sets are mishandled.
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://www.openwall.com/lists/oss-security/2023/05/15/5
- https://bugzilla.redhat.com/show_bug.cgi?id=2196105
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1592a89942e9678f7d9c8030efa777c0d57edab
- https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://news.ycombinator.com/item?id=35879660
- https://security.netapp.com/advisory/ntap-20230616-0002/
- https://www.debian.org/security/2023/dsa-5402
- https://www.openwall.com/lists/oss-security/2023/05/08/4
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://www.openwall.com/lists/oss-security/2023/05/15/5
- https://bugzilla.redhat.com/show_bug.cgi?id=2196105
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1592a89942e9678f7d9c8030efa777c0d57edab
- https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://news.ycombinator.com/item?id=35879660
- https://security.netapp.com/advisory/ntap-20230616-0002/
- https://www.debian.org/security/2023/dsa-5402
- https://www.openwall.com/lists/oss-security/2023/05/08/4
Modified: 2025-11-18
CVE-2023-32246
In the Linux kernel, the following vulnerability has been resolved: ksmbd: call rcu_barrier() in ksmbd_server_exit() racy issue is triggered the bug by racing between closing a connection and rmmod. In ksmbd, rcu_barrier() is not called at module unload time, so nothing prevents ksmbd from getting unloaded while it still has RCU callbacks pending. It leads to trigger unintended execution of kernel code locally and use to defeat protections such as Kernel Lockdown
- https://git.kernel.org/stable/c/5a7090ccc242ab009ee7769e9d7fad6644dbe9bd
- https://git.kernel.org/stable/c/b80422474ffe44cb5e813cd6da1f1c6bc50fd9d2
- https://git.kernel.org/stable/c/c053e389db0d892e2ff5a60ec5e533b976503795
- https://git.kernel.org/stable/c/d4174505016a3b2996eb7ff1530dcabbf15d47b6
- https://git.kernel.org/stable/c/eb307d09fe15844fdaebeb8cc8c9b9e925430aa5
Modified: 2024-11-21
CVE-2023-32247
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_SESSION_SETUP commands. The issue results from the lack of control of resource consumption. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.
- https://access.redhat.com/security/cve/CVE-2023-32247
- https://bugzilla.redhat.com/show_bug.cgi?id=2219803
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20478/
- https://access.redhat.com/security/cve/CVE-2023-32247
- https://bugzilla.redhat.com/show_bug.cgi?id=2219803
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20478/
Modified: 2024-11-21
CVE-2023-32248
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_TREE_CONNECT and SMB2_QUERY_INFO commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.
- https://access.redhat.com/security/cve/CVE-2023-32248
- https://bugzilla.redhat.com/show_bug.cgi?id=2219818
- https://security.netapp.com/advisory/ntap-20230915-0006/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20479/
- https://access.redhat.com/security/cve/CVE-2023-32248
- https://bugzilla.redhat.com/show_bug.cgi?id=2219818
- https://security.netapp.com/advisory/ntap-20230915-0006/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20479/
Modified: 2025-11-18
CVE-2023-32249
In the Linux kernel, the following vulnerability has been resolved: ksmbd: not allow guest user on multichannel This patch return STATUS_NOT_SUPPORTED if binding session is guest.
- https://git.kernel.org/stable/c/088131b7b01099720a528a72005ff17868705d40
- https://git.kernel.org/stable/c/1f0490586544455e5be698be2e6c30077b4ec461
- https://git.kernel.org/stable/c/3353ab2df5f68dab7da8d5ebb427a2d265a1f2b2
- https://git.kernel.org/stable/c/4a98e859c4673013385a54084e0cd865695ca072
- https://git.kernel.org/stable/c/ed76d3a8910be06cd4e4ba63bf6075bf903945a1
Modified: 2024-11-21
CVE-2023-32250
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.
- https://access.redhat.com/security/cve/CVE-2023-32250
- https://bugzilla.redhat.com/show_bug.cgi?id=2208849
- https://security.netapp.com/advisory/ntap-20230824-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-698/
- https://access.redhat.com/security/cve/CVE-2023-32250
- https://bugzilla.redhat.com/show_bug.cgi?id=2208849
- https://security.netapp.com/advisory/ntap-20230824-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-698/
Modified: 2024-11-21
CVE-2023-32252
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_LOGOFF commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.
- https://access.redhat.com/security/cve/CVE-2023-32252
- https://bugzilla.redhat.com/show_bug.cgi?id=2219815
- https://security.netapp.com/advisory/ntap-20231124-0001/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20590/
- https://access.redhat.com/security/cve/CVE-2023-32252
- https://bugzilla.redhat.com/show_bug.cgi?id=2219815
- https://security.netapp.com/advisory/ntap-20231124-0001/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20590/
Modified: 2024-11-21
CVE-2023-32254
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_TREE_DISCONNECT commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.
- https://access.redhat.com/security/cve/CVE-2023-32254
- https://bugzilla.redhat.com/show_bug.cgi?id=2191658
- https://security.netapp.com/advisory/ntap-20230824-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-702/
- https://access.redhat.com/security/cve/CVE-2023-32254
- https://bugzilla.redhat.com/show_bug.cgi?id=2191658
- https://security.netapp.com/advisory/ntap-20230824-0004/
- https://www.zerodayinitiative.com/advisories/ZDI-23-702/
Modified: 2024-11-21
CVE-2023-32257
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP and SMB2_LOGOFF commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.
- https://access.redhat.com/security/cve/CVE-2023-32257
- https://bugzilla.redhat.com/show_bug.cgi?id=2219806
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20596/
- https://access.redhat.com/security/cve/CVE-2023-32257
- https://bugzilla.redhat.com/show_bug.cgi?id=2219806
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20596/
Modified: 2024-11-21
CVE-2023-32258
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_LOGOFF and SMB2_CLOSE commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.
- https://access.redhat.com/security/cve/CVE-2023-32258
- https://bugzilla.redhat.com/show_bug.cgi?id=2219809
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20796/
- https://access.redhat.com/security/cve/CVE-2023-32258
- https://bugzilla.redhat.com/show_bug.cgi?id=2219809
- https://security.netapp.com/advisory/ntap-20230915-0011/
- https://www.zerodayinitiative.com/advisories/ZDI-CAN-20796/
Modified: 2025-05-05
CVE-2023-32269
An issue was discovered in the Linux kernel before 6.1.11. In net/netrom/af_netrom.c, there is a use-after-free because accept is also allowed for a successfully connected AF_NETROM socket. However, in order for an attacker to exploit this, the system must have netrom routing configured or the attacker must have the CAP_NET_ADMIN capability.
Modified: 2024-11-21
CVE-2023-3269
A vulnerability exists in the memory management subsystem of the Linux kernel. The lock handling for accessing and updating virtual memory areas (VMAs) is incorrect, leading to use-after-free problems. This issue can be successfully exploited to execute arbitrary kernel code, escalate containers, and gain root privileges.
- http://seclists.org/fulldisclosure/2023/Jul/43
- http://www.openwall.com/lists/oss-security/2023/07/28/1
- http://www.openwall.com/lists/oss-security/2023/08/25/1
- http://www.openwall.com/lists/oss-security/2023/08/25/4
- https://access.redhat.com/security/cve/CVE-2023-3269
- https://bugzilla.redhat.com/show_bug.cgi?id=2215268
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U6AAA64CUPSMBW6XDTXPQJ3KQWYQ4K7L/
- https://security.netapp.com/advisory/ntap-20230908-0001/
- https://www.openwall.com/lists/oss-security/2023/07/05/1
- http://seclists.org/fulldisclosure/2023/Jul/43
- http://www.openwall.com/lists/oss-security/2023/07/28/1
- http://www.openwall.com/lists/oss-security/2023/08/25/1
- http://www.openwall.com/lists/oss-security/2023/08/25/4
- https://access.redhat.com/security/cve/CVE-2023-3269
- https://bugzilla.redhat.com/show_bug.cgi?id=2215268
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U6AAA64CUPSMBW6XDTXPQJ3KQWYQ4K7L/
- https://security.netapp.com/advisory/ntap-20230908-0001/
- https://www.openwall.com/lists/oss-security/2023/07/05/1
Modified: 2024-11-21
CVE-2023-3390
A use-after-free vulnerability was found in the Linux kernel's netfilter subsystem in net/netfilter/nf_tables_api.c. Mishandled error handling with NFT_MSG_NEWRULE makes it possible to use a dangling pointer in the same transaction causing a use-after-free vulnerability. This flaw allows a local attacker with user access to cause a privilege escalation issue. We recommend upgrading past commit 1240eb93f0616b21c675416516ff3d74798fdc97.
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1240eb93f0616b21c675416516ff3d74798fdc97
- https://kernel.dance/1240eb93f0616b21c675416516ff3d74798fdc97
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230818-0004/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5461
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1240eb93f0616b21c675416516ff3d74798fdc97
- https://kernel.dance/1240eb93f0616b21c675416516ff3d74798fdc97
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230818-0004/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5461
Modified: 2024-11-21
CVE-2023-35001
Linux Kernel nftables Out-Of-Bounds Read/Write Vulnerability; nft_byteorder poorly handled vm register contents when CAP_NET_ADMIN is in any user or network namespace
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://www.openwall.com/lists/oss-security/2023/07/05/3
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/
- https://lore.kernel.org/netfilter-devel/20230705121515.747251-1-cascardo@canonical.com/T/
- https://security.netapp.com/advisory/ntap-20230824-0007/
- https://www.debian.org/security/2023/dsa-5453
- https://www.openwall.com/lists/oss-security/2023/07/05/3
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://www.openwall.com/lists/oss-security/2023/07/05/3
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/
- https://lore.kernel.org/netfilter-devel/20230705121515.747251-1-cascardo@canonical.com/T/
- https://security.netapp.com/advisory/ntap-20230824-0007/
- https://www.debian.org/security/2023/dsa-5453
- https://www.openwall.com/lists/oss-security/2023/07/05/3
Modified: 2025-05-05
CVE-2023-35788
An issue was discovered in fl_set_geneve_opt in net/sched/cls_flower.c in the Linux kernel before 6.3.7. It allows an out-of-bounds write in the flower classifier code via TCA_FLOWER_KEY_ENC_OPTS_GENEVE packets. This may result in denial of service or privilege escalation.
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://www.openwall.com/lists/oss-security/2023/06/17/1
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.7
- https://git.kernel.org/linus/4d56304e5827c8cc8cc18c75343d283af7c4825c
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230714-0002/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/06/07/1
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://www.openwall.com/lists/oss-security/2023/06/17/1
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.7
- https://git.kernel.org/linus/4d56304e5827c8cc8cc18c75343d283af7c4825c
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230714-0002/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/06/07/1
Modified: 2024-11-21
CVE-2023-35826
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in cedrus_remove in drivers/staging/media/sunxi/cedrus/cedrus.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50d0a7aea4809cef87979d4669911276aa23b71f
- https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/
- https://lore.kernel.org/linux-arm-kernel/20230308032333.1893394-1-zyytlz.wz%40163.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50d0a7aea4809cef87979d4669911276aa23b71f
- https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/
- https://lore.kernel.org/linux-arm-kernel/20230308032333.1893394-1-zyytlz.wz%40163.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
Modified: 2024-11-21
CVE-2023-35828
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in renesas_usb3_remove in drivers/usb/gadget/udc/renesas_usb3.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au/
- https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au/
- https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
Modified: 2024-11-21
CVE-2023-35829
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in rkvdec_remove in drivers/staging/media/rkvdec/rkvdec.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3228cec23b8b29215e18090c6ba635840190993d
- https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/
- https://lore.kernel.org/lkml/20230307173900.1299387-1-zyytlz.wz%40163.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3228cec23b8b29215e18090c6ba635840190993d
- https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/
- https://lore.kernel.org/lkml/20230307173900.1299387-1-zyytlz.wz%40163.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
Modified: 2025-02-13
CVE-2023-3610
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. Flaw in the error handling of bound chains causes a use-after-free in the abort path of NFT_MSG_NEWRULE. The vulnerability requires CAP_NET_ADMIN to be triggered. We recommend upgrading past commit 4bedf9eee016286c835e3d8fa981ddece5338795.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4bedf9eee016286c835e3d8fa981ddece5338795
- https://kernel.dance/4bedf9eee016286c835e3d8fa981ddece5338795
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://security.netapp.com/advisory/ntap-20230818-0005/
- https://www.debian.org/security/2023/dsa-5461
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4bedf9eee016286c835e3d8fa981ddece5338795
- https://kernel.dance/4bedf9eee016286c835e3d8fa981ddece5338795
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://security.netapp.com/advisory/ntap-20230818-0005/
- https://www.debian.org/security/2023/dsa-5461
Modified: 2025-02-13
CVE-2023-3611
An out-of-bounds write vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation. The qfq_change_agg() function in net/sched/sch_qfq.c allows an out-of-bounds write because lmax is updated according to packet sizes without bounds checks. We recommend upgrading past commit 3e337087c3b5805fe0b8a46ba622a962880b5d64.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64
- https://kernel.dance/3e337087c3b5805fe0b8a46ba622a962880b5d64
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230908-0002/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64
- https://kernel.dance/3e337087c3b5805fe0b8a46ba622a962880b5d64
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230908-0002/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-02-13
CVE-2023-3776
A use-after-free vulnerability in the Linux kernel's net/sched: cls_fw component can be exploited to achieve local privilege escalation. If tcf_change_indev() fails, fw_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability. We recommend upgrading past commit 0323bce598eea038714f941ce2b22541c46d488f.
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=0323bce598eea038714f941ce2b22541c46d488f
- https://kernel.dance/0323bce598eea038714f941ce2b22541c46d488f
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20240202-0003/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=0323bce598eea038714f941ce2b22541c46d488f
- https://kernel.dance/0323bce598eea038714f941ce2b22541c46d488f
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20240202-0003/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-03-20
CVE-2023-3777
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. When nf_tables_delrule() is flushing table rules, it is not checked whether the chain is bound and the chain's owner rule can also release the objects in certain circumstances. We recommend upgrading past commit 6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8.
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8
- https://kernel.dance/6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8
- https://www.debian.org/security/2023/dsa-5492
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8
- https://kernel.dance/6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8
- https://www.debian.org/security/2023/dsa-5492
Modified: 2024-11-21
CVE-2023-38426
An issue was discovered in the Linux kernel before 6.3.4. ksmbd has an out-of-bounds read in smb2_find_context_vals when create_context's name_len is larger than the tag length.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=02f76c401d17e409ed45bf7887148fcc22c93c85
- https://security.netapp.com/advisory/ntap-20230915-0010/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=02f76c401d17e409ed45bf7887148fcc22c93c85
- https://security.netapp.com/advisory/ntap-20230915-0010/
Modified: 2025-05-05
CVE-2023-38427
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/smb2pdu.c in ksmbd has an integer underflow and out-of-bounds read in deassemble_neg_contexts.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b
- https://security.netapp.com/advisory/ntap-20230824-0011/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b
- https://security.netapp.com/advisory/ntap-20230824-0011/
Modified: 2024-11-21
CVE-2023-38428
An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/smb2pdu.c in ksmbd does not properly check the UserName value because it does not consider the address of security buffer, leading to an out-of-bounds read.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=f0a96d1aafd8964e1f9955c830a3e5cb3c60a90f
- https://security.netapp.com/advisory/ntap-20230831-0001/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=f0a96d1aafd8964e1f9955c830a3e5cb3c60a90f
- https://security.netapp.com/advisory/ntap-20230831-0001/
Modified: 2025-01-03
CVE-2023-38429
An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/connection.c in ksmbd has an off-by-one error in memory allocation (because of ksmbd_smb2_check_message) that may lead to out-of-bounds access.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=443d61d1fa9faa60ef925513d83742902390100f
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=443d61d1fa9faa60ef925513d83742902390100f
- https://security.netapp.com/advisory/ntap-20250103-0009/
Modified: 2024-11-21
CVE-2023-38430
An issue was discovered in the Linux kernel before 6.3.9. ksmbd does not validate the SMB request protocol ID, leading to an out-of-bounds read.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.9
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=1c1bcf2d3ea061613119b534f57507c377df20f9
- https://security.netapp.com/advisory/ntap-20230831-0003/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.9
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=1c1bcf2d3ea061613119b534f57507c377df20f9
- https://security.netapp.com/advisory/ntap-20230831-0003/
Modified: 2024-11-21
CVE-2023-38431
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/connection.c in ksmbd does not validate the relationship between the NetBIOS header's length field and the SMB header sizes, via pdu_size in ksmbd_conn_handler_loop, leading to an out-of-bounds read.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=368ba06881c395f1c9a7ba22203cf8d78b4addc0
- https://security.netapp.com/advisory/ntap-20230824-0011/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=368ba06881c395f1c9a7ba22203cf8d78b4addc0
- https://security.netapp.com/advisory/ntap-20230824-0011/
Modified: 2024-11-21
CVE-2023-38432
An issue was discovered in the Linux kernel before 6.3.10. fs/smb/server/smb2misc.c in ksmbd does not validate the relationship between the command payload size and the RFC1002 length specification, leading to an out-of-bounds read.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.10
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=2b9b8f3b68edb3d67d79962f02e26dbb5ae3808d
- https://security.netapp.com/advisory/ntap-20230831-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.10
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=2b9b8f3b68edb3d67d79962f02e26dbb5ae3808d
- https://security.netapp.com/advisory/ntap-20230831-0002/
Modified: 2025-11-18
CVE-2023-3865
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bound read in smb2_write ksmbd_smb2_check_message doesn't validate hdr->NextCommand. If ->NextCommand is bigger than Offset + Length of smb2 write, It will allow oversized smb2 write length. It will cause OOB read in smb2_write.
Modified: 2025-11-18
CVE-2023-3866
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate session id and tree id in the compound request This patch validate session id and tree id in compound request. If first operation in the compound is SMB2 ECHO request, ksmbd bypass session and tree validation. So work->sess and work->tcon could be NULL. If secound request in the compound access work->sess or tcon, It cause NULL pointer dereferecing error.
Modified: 2025-11-18
CVE-2023-3867
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out of bounds read in smb2_sess_setup ksmbd does not consider the case of that smb2 session setup is in compound request. If this is the second payload of the compound, OOB read issue occurs while processing the first payload in the smb2_sess_setup().
Modified: 2024-11-21
CVE-2023-39197
An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol.
Modified: 2024-11-21
CVE-2023-4004
A use-after-free flaw was found in the Linux kernel's netfilter in the way a user triggers the nft_pipapo_remove function with the element, without a NFT_SET_EXT_KEY_END. This issue could allow a local user to crash the system or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:4961
- https://access.redhat.com/errata/RHSA-2023:4962
- https://access.redhat.com/errata/RHSA-2023:4967
- https://access.redhat.com/errata/RHSA-2023:5069
- https://access.redhat.com/errata/RHSA-2023:5091
- https://access.redhat.com/errata/RHSA-2023:5093
- https://access.redhat.com/errata/RHSA-2023:5221
- https://access.redhat.com/errata/RHSA-2023:5244
- https://access.redhat.com/errata/RHSA-2023:5255
- https://access.redhat.com/errata/RHSA-2023:5548
- https://access.redhat.com/errata/RHSA-2023:5627
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7417
- https://access.redhat.com/errata/RHSA-2023:7431
- https://access.redhat.com/errata/RHSA-2023:7434
- https://access.redhat.com/security/cve/CVE-2023-4004
- https://bugzilla.redhat.com/show_bug.cgi?id=2225275
- https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230719190824.21196-1-fw@strlen.de/
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://access.redhat.com/errata/RHSA-2023:4961
- https://access.redhat.com/errata/RHSA-2023:4962
- https://access.redhat.com/errata/RHSA-2023:4967
- https://access.redhat.com/errata/RHSA-2023:5069
- https://access.redhat.com/errata/RHSA-2023:5091
- https://access.redhat.com/errata/RHSA-2023:5093
- https://access.redhat.com/errata/RHSA-2023:5221
- https://access.redhat.com/errata/RHSA-2023:5244
- https://access.redhat.com/errata/RHSA-2023:5255
- https://access.redhat.com/errata/RHSA-2023:5548
- https://access.redhat.com/errata/RHSA-2023:5627
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7417
- https://access.redhat.com/errata/RHSA-2023:7431
- https://access.redhat.com/errata/RHSA-2023:7434
- https://access.redhat.com/security/cve/CVE-2023-4004
- https://bugzilla.redhat.com/show_bug.cgi?id=2225275
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230719190824.21196-1-fw@strlen.de/
- https://security.netapp.com/advisory/ntap-20231027-0001/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-02-13
CVE-2023-4015
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. On an error when building a nftables rule, deactivating immediate expressions in nft_immediate_deactivate() can lead unbinding the chain and objects be deactivated but later used. We recommend upgrading past commit 0a771f7b266b02d262900c75f1e175c7fe76fec2.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a771f7b266b02d262900c75f1e175c7fe76fec2
- https://kernel.dance/0a771f7b266b02d262900c75f1e175c7fe76fec2
- https://www.debian.org/security/2023/dsa-5492
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a771f7b266b02d262900c75f1e175c7fe76fec2
- https://kernel.dance/0a771f7b266b02d262900c75f1e175c7fe76fec2
- https://www.debian.org/security/2023/dsa-5492
Modified: 2026-02-25
CVE-2023-40283
An issue was discovered in l2cap_sock_release in net/bluetooth/l2cap_sock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled.
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.10
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1728137b33c00d5a2b5110ed7aafb42e7c32e4a1
- https://github.com/torvalds/linux/commit/1728137b33c00d5a2b5110ed7aafb42e7c32e4a1
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20231020-0007/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.10
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1728137b33c00d5a2b5110ed7aafb42e7c32e4a1
- https://github.com/torvalds/linux/commit/1728137b33c00d5a2b5110ed7aafb42e7c32e4a1
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20231020-0007/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-11-18
CVE-2023-4130
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix wrong next length validation of ea buffer in smb2_set_ea() There are multiple smb2_ea_info buffers in FILE_FULL_EA_INFORMATION request from client. ksmbd find next smb2_ea_info using ->NextEntryOffset of current smb2_ea_info. ksmbd need to validate buffer length Before accessing the next ea. ksmbd should check buffer length using buf_len, not next variable. next is the start offset of current ea that got from previous ea.
Modified: 2024-11-21
CVE-2023-4147
A use-after-free flaw was found in the Linux kernel’s Netfilter functionality when adding a rule with NFTA_RULE_CHAIN_ID. This flaw allows a local user to crash or escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:5069
- https://access.redhat.com/errata/RHSA-2023:5091
- https://access.redhat.com/errata/RHSA-2023:5093
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/security/cve/CVE-2023-4147
- https://bugzilla.redhat.com/show_bug.cgi?id=2225239
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ebc1064e4874d5987722a2ddbc18f94aa53b211
- https://www.spinics.net/lists/stable/msg671573.html
- https://access.redhat.com/errata/RHSA-2023:5069
- https://access.redhat.com/errata/RHSA-2023:5091
- https://access.redhat.com/errata/RHSA-2023:5093
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/security/cve/CVE-2023-4147
- https://bugzilla.redhat.com/show_bug.cgi?id=2225239
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ebc1064e4874d5987722a2ddbc18f94aa53b211
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20231020-0006/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
- https://www.spinics.net/lists/stable/msg671573.html
Modified: 2025-02-13
CVE-2023-4206
A use-after-free vulnerability in the Linux kernel's net/sched: cls_route component can be exploited to achieve local privilege escalation. When route4_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. We recommend upgrading past commit b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8
- https://kernel.dance/b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8
- https://kernel.dance/b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-02-13
CVE-2023-4207
A use-after-free vulnerability in the Linux kernel's net/sched: cls_fw component can be exploited to achieve local privilege escalation. When fw_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. We recommend upgrading past commit 76e42ae831991c828cffa8c37736ebfb831ad5ec.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76e42ae831991c828cffa8c37736ebfb831ad5ec
- https://kernel.dance/76e42ae831991c828cffa8c37736ebfb831ad5ec
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76e42ae831991c828cffa8c37736ebfb831ad5ec
- https://kernel.dance/76e42ae831991c828cffa8c37736ebfb831ad5ec
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-02-13
CVE-2023-4208
A use-after-free vulnerability in the Linux kernel's net/sched: cls_u32 component can be exploited to achieve local privilege escalation. When u32_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. We recommend upgrading past commit 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81
- https://kernel.dance/3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81
- https://kernel.dance/3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
Modified: 2024-11-21
CVE-2023-42753
An array indexing vulnerability was found in the netfilter subsystem of the Linux kernel. A missing macro could lead to a miscalculation of the `h->nets` array offset, providing attackers with the primitive to arbitrarily increment/decrement a memory buffer out-of-bound. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7539
- https://access.redhat.com/errata/RHSA-2023:7558
- https://access.redhat.com/errata/RHSA-2024:0089
- https://access.redhat.com/errata/RHSA-2024:0113
- https://access.redhat.com/errata/RHSA-2024:0134
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0346
- https://access.redhat.com/errata/RHSA-2024:0347
- https://access.redhat.com/errata/RHSA-2024:0371
- https://access.redhat.com/errata/RHSA-2024:0376
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0402
- https://access.redhat.com/errata/RHSA-2024:0403
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:0999
- https://access.redhat.com/security/cve/CVE-2023-42753
- https://bugzilla.redhat.com/show_bug.cgi?id=2239843
- https://seclists.org/oss-sec/2023/q3/216
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7539
- https://access.redhat.com/errata/RHSA-2023:7558
- https://access.redhat.com/errata/RHSA-2024:0089
- https://access.redhat.com/errata/RHSA-2024:0113
- https://access.redhat.com/errata/RHSA-2024:0134
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0346
- https://access.redhat.com/errata/RHSA-2024:0347
- https://access.redhat.com/errata/RHSA-2024:0371
- https://access.redhat.com/errata/RHSA-2024:0376
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0402
- https://access.redhat.com/errata/RHSA-2024:0403
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:0999
- https://access.redhat.com/security/cve/CVE-2023-42753
- https://bugzilla.redhat.com/show_bug.cgi?id=2239843
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://seclists.org/oss-sec/2023/q3/216
- https://www.openwall.com/lists/oss-security/2023/09/22/10
Modified: 2025-05-23
CVE-2023-44466
An issue was discovered in net/ceph/messenger_v2.c in the Linux kernel before 6.4.5. There is an integer signedness error, leading to a buffer overflow and remote code execution via HELLO or one of the AUTH frames. This occurs because of an untrusted length taken from a TCP packet in ceph_decode_32.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a282a2f10539dce2aa619e71e1817570d557fc97
- https://github.com/google/security-research/security/advisories/GHSA-jg27-jx6w-xwph
- https://github.com/torvalds/linux/commit/a282a2f10539dce2aa619e71e1817570d557fc97
- https://security.netapp.com/advisory/ntap-20231116-0003/
- https://www.spinics.net/lists/ceph-devel/msg57909.html
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a282a2f10539dce2aa619e71e1817570d557fc97
- https://github.com/google/security-research/security/advisories/GHSA-jg27-jx6w-xwph
- https://github.com/torvalds/linux/commit/a282a2f10539dce2aa619e71e1817570d557fc97
- https://security.netapp.com/advisory/ntap-20231116-0003/
- https://www.spinics.net/lists/ceph-devel/msg57909.html
Modified: 2025-05-05
CVE-2023-45871
An issue was discovered in drivers/net/ethernet/intel/igb/igb_main.c in the IGB driver in the Linux kernel before 6.5.3. A buffer size may not be adequate for frames larger than the MTU.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.3
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb5ed01cd2428cd25b1c88a3a9cba87055eb289f
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20231110-0001/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.3
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb5ed01cd2428cd25b1c88a3a9cba87055eb289f
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20231110-0001/
Modified: 2025-02-13
CVE-2023-4622
A use-after-free vulnerability in the Linux kernel's af_unix component can be exploited to achieve local privilege escalation. The unix_stream_sendpage() function tries to add data to the last skb in the peer's recv queue without locking the queue. Thus there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free. We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c.
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=790c2f9d15b594350ae9bca7b236f2b1859de02c
- https://kernel.dance/790c2f9d15b594350ae9bca7b236f2b1859de02c
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=790c2f9d15b594350ae9bca7b236f2b1859de02c
- https://kernel.dance/790c2f9d15b594350ae9bca7b236f2b1859de02c
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-03-20
CVE-2023-4623
A use-after-free vulnerability in the Linux kernel's net/sched: sch_hfsc (HFSC qdisc traffic control) component can be exploited to achieve local privilege escalation. If a class with a link-sharing curve (i.e. with the HFSC_FSC flag set) has a parent without a link-sharing curve, then init_vf() will call vttree_insert() on the parent, but vttree_remove() will be skipped in update_vf(). This leaves a dangling pointer that can cause a use-after-free. We recommend upgrading past commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f.
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d26c5702c7d6c45456326e56d2ccf3f103e60f
- https://kernel.dance/b3d26c5702c7d6c45456326e56d2ccf3f103e60f
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d26c5702c7d6c45456326e56d2ccf3f103e60f
- https://kernel.dance/b3d26c5702c7d6c45456326e56d2ccf3f103e60f
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
Modified: 2025-11-04
CVE-2023-46838
Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides a certain initial portion of the to be transferred data, these parts are directly translated into what Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of length zero, lead to a de-reference of NULL in core networking code.
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://xenbits.xenproject.org/xsa/advisory-448.html
- http://xenbits.xen.org/xsa/advisory-448.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://xenbits.xenproject.org/xsa/advisory-448.html
Modified: 2025-02-13
CVE-2023-4921
A use-after-free vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation. When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in agg_dequeue(). We recommend upgrading past commit 8fc134fee27f2263988ae38920bc03da416b03d8.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8fc134fee27f2263988ae38920bc03da416b03d8
- https://kernel.dance/8fc134fee27f2263988ae38920bc03da416b03d8
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8fc134fee27f2263988ae38920bc03da416b03d8
- https://kernel.dance/8fc134fee27f2263988ae38920bc03da416b03d8
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
Modified: 2026-03-24
CVE-2023-5178
A use-after-free vulnerability was found in drivers/nvme/target/tcp.c` in `nvmet_tcp_free_crypto` due to a logical bug in the NVMe/TCP subsystem in the Linux kernel. This issue may allow a malicious user to cause a use-after-free and double-free problem, which may permit remote code execution or lead to local privilege escalation.
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7551
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2023:7557
- https://access.redhat.com/errata/RHSA-2023:7559
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0386
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0431
- https://access.redhat.com/errata/RHSA-2024:0432
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:1268
- https://access.redhat.com/errata/RHSA-2024:1269
- https://access.redhat.com/errata/RHSA-2024:1278
- https://access.redhat.com/security/cve/CVE-2023-5178
- https://bugzilla.redhat.com/show_bug.cgi?id=2241924
- https://lore.kernel.org/linux-nvme/20231002105428.226515-1-sagi@grimberg.me/
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7551
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2023:7557
- https://access.redhat.com/errata/RHSA-2023:7559
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0386
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0431
- https://access.redhat.com/errata/RHSA-2024:0432
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:1268
- https://access.redhat.com/errata/RHSA-2024:1269
- https://access.redhat.com/errata/RHSA-2024:1278
- https://access.redhat.com/security/cve/CVE-2023-5178
- https://bugzilla.redhat.com/show_bug.cgi?id=2241924
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://lore.kernel.org/linux-nvme/20231002105428.226515-1-sagi@grimberg.me/
- https://security.netapp.com/advisory/ntap-20231208-0004/
Modified: 2025-12-11
CVE-2023-5197
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free. We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325.
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f15f29fd4779be8a418b66e9d52979bb6d6c2325
- https://kernel.dance/f15f29fd4779be8a418b66e9d52979bb6d6c2325
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f15f29fd4779be8a418b66e9d52979bb6d6c2325
- https://kernel.dance/f15f29fd4779be8a418b66e9d52979bb6d6c2325
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2024-11-21
CVE-2023-52436
In the Linux kernel, the following vulnerability has been resolved: f2fs: explicitly null-terminate the xattr list When setting an xattr, explicitly null-terminate the xattr list. This eliminates the fragile assumption that the unused xattr space is always zeroed.
- https://git.kernel.org/stable/c/12cf91e23b126718a96b914f949f2cdfeadc7b2a
- https://git.kernel.org/stable/c/16ae3132ff7746894894927c1892493693b89135
- https://git.kernel.org/stable/c/2525d1ba225b5c167162fa344013c408e8b4de36
- https://git.kernel.org/stable/c/32a6cfc67675ee96fe107aeed5af9776fec63f11
- https://git.kernel.org/stable/c/3e47740091b05ac8d7836a33afd8646b6863ca52
- https://git.kernel.org/stable/c/5de9e9dd1828db9b8b962f7ca42548bd596deb8a
- https://git.kernel.org/stable/c/e26b6d39270f5eab0087453d9b544189a38c8564
- https://git.kernel.org/stable/c/f6c30bfe5a49bc38cae985083a11016800708fea
- https://git.kernel.org/stable/c/12cf91e23b126718a96b914f949f2cdfeadc7b2a
- https://git.kernel.org/stable/c/16ae3132ff7746894894927c1892493693b89135
- https://git.kernel.org/stable/c/2525d1ba225b5c167162fa344013c408e8b4de36
- https://git.kernel.org/stable/c/32a6cfc67675ee96fe107aeed5af9776fec63f11
- https://git.kernel.org/stable/c/3e47740091b05ac8d7836a33afd8646b6863ca52
- https://git.kernel.org/stable/c/5de9e9dd1828db9b8b962f7ca42548bd596deb8a
- https://git.kernel.org/stable/c/e26b6d39270f5eab0087453d9b544189a38c8564
- https://git.kernel.org/stable/c/f6c30bfe5a49bc38cae985083a11016800708fea
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52438
In the Linux kernel, the following vulnerability has been resolved: binder: fix use-after-free in shinker's callback The mmap read lock is used during the shrinker's callback, which means that using alloc->vma pointer isn't safe as it can race with munmap(). As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") the mmap lock is downgraded after the vma has been isolated. I was able to reproduce this issue by manually adding some delays and triggering page reclaiming through the shrinker's debug sysfs. The following KASAN report confirms the UAF: ================================================================== BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8 Read of size 8 at addr ffff356ed50e50f0 by task bash/478 CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 Hardware name: linux,dummy-virt (DT) Call trace: zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c Allocated by task 492: kmem_cache_alloc+0x130/0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 Freed by task 491: kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 Last potentially related work creation: __call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c Fix this issue by performing instead a vma_lookup() which will fail to find the vma that was isolated before the mmap lock downgrade. Note that this option has better performance than upgrading to a mmap write lock which would increase contention. Plus, mmap_write_trylock() has been recently removed anyway.
- https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906
- https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6
- https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56
- https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869
- https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3
- https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c
- https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727
- https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906
- https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6
- https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56
- https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869
- https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3
- https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c
- https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-12-27
CVE-2023-52439
In the Linux kernel, the following vulnerability has been resolved: uio: Fix use-after-free in uio_open core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock.
- https://git.kernel.org/stable/c/0c9ae0b8605078eafc3bea053cc78791e97ba2e2
- https://git.kernel.org/stable/c/17a8519cb359c3b483fb5c7367efa9a8a508bdea
- https://git.kernel.org/stable/c/3174e0f7de1ba392dc191625da83df02d695b60c
- https://git.kernel.org/stable/c/35f102607054faafe78d2a6994b18d5d9d6e92ad
- https://git.kernel.org/stable/c/5cf604ee538ed0c467abe3b4cda5308a6398f0f7
- https://git.kernel.org/stable/c/5e0be1229ae199ebb90b33102f74a0f22d152570
- https://git.kernel.org/stable/c/913205930da6213305616ac539447702eaa85e41
- https://git.kernel.org/stable/c/e93da893d52d82d57fc0db2ca566024e0f26ff50
- https://git.kernel.org/stable/c/0c9ae0b8605078eafc3bea053cc78791e97ba2e2
- https://git.kernel.org/stable/c/17a8519cb359c3b483fb5c7367efa9a8a508bdea
- https://git.kernel.org/stable/c/3174e0f7de1ba392dc191625da83df02d695b60c
- https://git.kernel.org/stable/c/35f102607054faafe78d2a6994b18d5d9d6e92ad
- https://git.kernel.org/stable/c/5cf604ee538ed0c467abe3b4cda5308a6398f0f7
- https://git.kernel.org/stable/c/5e0be1229ae199ebb90b33102f74a0f22d152570
- https://git.kernel.org/stable/c/913205930da6213305616ac539447702eaa85e41
- https://git.kernel.org/stable/c/e93da893d52d82d57fc0db2ca566024e0f26ff50
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241227-0006/
Modified: 2024-11-21
CVE-2023-52440
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slub overflow in ksmbd_decode_ntlmssp_auth_blob() If authblob->SessionKey.Length is bigger than session key size(CIFS_KEY_SIZE), slub overflow can happen in key exchange codes. cifs_arc4_crypt copy to session key array from SessionKey from client.
- https://git.kernel.org/stable/c/30fd6521b2fbd9b767e438e31945e5ea3e3a2fba
- https://git.kernel.org/stable/c/4b081ce0d830b684fdf967abc3696d1261387254
- https://git.kernel.org/stable/c/7f1d6cb0eb6af3a8088dc24b7ddee9a9711538c4
- https://git.kernel.org/stable/c/bd554ed4fdc3d38404a1c43d428432577573e809
- https://git.kernel.org/stable/c/ecd7e1c562cb08e41957fcd4b0e404de5ab38e20
- https://git.kernel.org/stable/c/30fd6521b2fbd9b767e438e31945e5ea3e3a2fba
- https://git.kernel.org/stable/c/4b081ce0d830b684fdf967abc3696d1261387254
- https://git.kernel.org/stable/c/7f1d6cb0eb6af3a8088dc24b7ddee9a9711538c4
- https://git.kernel.org/stable/c/bd554ed4fdc3d38404a1c43d428432577573e809
- https://git.kernel.org/stable/c/ecd7e1c562cb08e41957fcd4b0e404de5ab38e20
Modified: 2024-11-21
CVE-2023-52441
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out of bounds in init_smb2_rsp_hdr() If client send smb2 negotiate request and then send smb1 negotiate request, init_smb2_rsp_hdr is called for smb1 negotiate request since need_neg is set to false. This patch ignore smb1 packets after ->need_neg is set to false.
- https://git.kernel.org/stable/c/330d900620dfc9893011d725b3620cd2ee0bc2bc
- https://git.kernel.org/stable/c/536bb492d39bb6c080c92f31e8a55fe9934f452b
- https://git.kernel.org/stable/c/5c0df9d30c289d6b9d7d44e2a450de2f8e3cf40b
- https://git.kernel.org/stable/c/aa669ef229ae8dd779da9caa24e254964545895f
- https://git.kernel.org/stable/c/330d900620dfc9893011d725b3620cd2ee0bc2bc
- https://git.kernel.org/stable/c/536bb492d39bb6c080c92f31e8a55fe9934f452b
- https://git.kernel.org/stable/c/5c0df9d30c289d6b9d7d44e2a450de2f8e3cf40b
- https://git.kernel.org/stable/c/aa669ef229ae8dd779da9caa24e254964545895f
Modified: 2025-10-01
CVE-2023-52442
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate session id and tree id in compound request `smb2_get_msg()` in smb2_get_ksmbd_tcon() and smb2_check_user_session() will always return the first request smb2 header in a compound request. if `SMB2_TREE_CONNECT_HE` is the first command in compound request, will return 0, i.e. The tree id check is skipped. This patch use ksmbd_req_buf_next() to get current command in compound.
- https://git.kernel.org/stable/c/017d85c94f02090a87f4a473dbe0d6ee0da72693
- https://git.kernel.org/stable/c/3df0411e132ee74a87aa13142dfd2b190275332e
- https://git.kernel.org/stable/c/4c2b350b2e269e3fd17bbfa42de1b42775b777ac
- https://git.kernel.org/stable/c/becb5191d1d5fdfca0198a2e37457bbbf4fe266f
- https://git.kernel.org/stable/c/017d85c94f02090a87f4a473dbe0d6ee0da72693
- https://git.kernel.org/stable/c/3df0411e132ee74a87aa13142dfd2b190275332e
- https://git.kernel.org/stable/c/4c2b350b2e269e3fd17bbfa42de1b42775b777ac
- https://git.kernel.org/stable/c/becb5191d1d5fdfca0198a2e37457bbbf4fe266f
Modified: 2024-11-21
CVE-2023-52443
In the Linux kernel, the following vulnerability has been resolved:
apparmor: avoid crash when parsed profile name is empty
When processing a packed profile in unpack_profile() described like
"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"
a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
passed to aa_splitn_fqname().
aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now.
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
- https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4
- https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf
- https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200
- https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203
- https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87
- https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e
- https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e
- https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45
- https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4
- https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf
- https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200
- https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203
- https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87
- https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e
- https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e
- https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52444
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail]
- https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46
- https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862
- https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28
- https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024
- https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310
- https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728
- https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7
- https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77
- https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46
- https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862
- https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28
- https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024
- https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310
- https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728
- https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7
- https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52445
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack.
- https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795
- https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e
- https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb
- https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c
- https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d
- https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1
- https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08
- https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab
- https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795
- https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e
- https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb
- https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c
- https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d
- https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1
- https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08
- https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52447
In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map.
- https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6
- https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0
- https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368
- https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2
- https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5
- https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee
- https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6
- https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0
- https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368
- https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2
- https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5
- https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2023-52448
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that.
- https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05
- https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37
- https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa
- https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a
- https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a
- https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178
- https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde
- https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05
- https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37
- https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa
- https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a
- https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a
- https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178
- https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52449
In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME.
- https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8
- https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745
- https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5
- https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6
- https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022
- https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc
- https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65
- https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c
- https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8
- https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745
- https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5
- https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6
- https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022
- https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc
- https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65
- https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52451
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry.
- https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0
- https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc
- https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d
- https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7
- https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e
- https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c
- https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5
- https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e
- https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0
- https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc
- https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d
- https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7
- https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e
- https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c
- https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5
- https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52454
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length If the host sends an H2CData command with an invalid DATAL, the kernel may crash in nvmet_tcp_build_pdu_iovec(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Call trace: process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 Fix the bug by raising a fatal error if DATAL isn't coherent with the packet size. Also, the PDU length should never exceed the MAXH2CDATA parameter which has been communicated to the host in nvmet_tcp_handle_icreq().
- https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88
- https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42
- https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d
- https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68
- https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d
- https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be
- https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510
- https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88
- https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42
- https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d
- https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68
- https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d
- https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be
- https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52456
In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND.
- https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06
- https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda
- https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181
- https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0
- https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b
- https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19
- https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06
- https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda
- https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181
- https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0
- https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b
- https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52457
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup.
- https://git.kernel.org/stable/c/828cd829483f0cda920710997aed79130b0af690
- https://git.kernel.org/stable/c/887a558d0298d36297daea039954c39940228d9b
- https://git.kernel.org/stable/c/95e4e0031effad9837af557ecbfd4294a4d8aeee
- https://git.kernel.org/stable/c/ad90d0358bd3b4554f243a425168fc7cebe7d04e
- https://git.kernel.org/stable/c/b502fb43f7fb55aaf07f6092ab44657595214b93
- https://git.kernel.org/stable/c/bc57f3ef8a9eb0180606696f586a6dcfaa175ed0
- https://git.kernel.org/stable/c/d74173bda29aba58f822175d983d07c8ed335494
- https://git.kernel.org/stable/c/828cd829483f0cda920710997aed79130b0af690
- https://git.kernel.org/stable/c/887a558d0298d36297daea039954c39940228d9b
- https://git.kernel.org/stable/c/95e4e0031effad9837af557ecbfd4294a4d8aeee
- https://git.kernel.org/stable/c/ad90d0358bd3b4554f243a425168fc7cebe7d04e
- https://git.kernel.org/stable/c/b502fb43f7fb55aaf07f6092ab44657595214b93
- https://git.kernel.org/stable/c/bc57f3ef8a9eb0180606696f586a6dcfaa175ed0
- https://git.kernel.org/stable/c/d74173bda29aba58f822175d983d07c8ed335494
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52458
In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free.
- https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503
- https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016
- https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62
- https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5
- https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8
- https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8
- https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503
- https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016
- https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62
- https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5
- https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8
- https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-11-21
CVE-2023-52462
In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, just use is_spilled_reg() helper.
- https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef
- https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036
- https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf
- https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174
- https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae
- https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104
- https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef
- https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036
- https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf
- https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174
- https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae
- https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52463
In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime.
- https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737
- https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe
- https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826
- https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8
- https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548
- https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b
- https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737
- https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe
- https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826
- https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8
- https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548
- https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52464
In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ]
- https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5
- https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8
- https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6
- https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a
- https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21
- https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601
- https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398
- https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057
- https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5
- https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8
- https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6
- https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a
- https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21
- https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601
- https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398
- https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52467
In the Linux kernel, the following vulnerability has been resolved: mfd: syscon: Fix null pointer dereference in of_syscon_register() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
- https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c
- https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1
- https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001
- https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973
- https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875
- https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b
- https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c
- https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1
- https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001
- https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973
- https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875
- https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2023-52469
In the Linux kernel, the following vulnerability has been resolved: drivers/amd/pm: fix a use-after-free in kv_parse_power_table When ps allocated by kzalloc equals to NULL, kv_parse_power_table frees adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call chains: kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its first free in kv_parse_power_table and causes a use-after-free bug.
- https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743
- https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02
- https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706
- https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3
- https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e
- https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63
- https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3
- https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a
- https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743
- https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02
- https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706
- https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3
- https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e
- https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63
- https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3
- https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52470
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() check the alloc_workqueue return value in radeon_crtc_init() to avoid null-ptr-deref.
- https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088
- https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1
- https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41
- https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb
- https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4
- https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310
- https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85
- https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97
- https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088
- https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1
- https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41
- https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb
- https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4
- https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310
- https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85
- https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2023-52474
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request. Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3). 3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node could be evicted by another thread that gets mmu_rb_handler->lock and checks mmu_rb_node->refcount before mmu_rb_node->refcount is incremented. 4. Related to #2 above, SDMA request submission failure path does not check mmu_rb_node->refcount before freeing mmu_rb_node object. If there are other SDMA requests in progress whose iovecs have pointers to the now-freed mmu_rb_node(s), those pointers to the now-freed mmu_rb nodes will be dereferenced when those SDMA requests complete.
- https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127
- https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc
- https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d
- https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678
- https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80
- https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844
- https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127
- https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc
- https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d
- https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678
- https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80
- https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844
Modified: 2024-12-09
CVE-2023-52475
In the Linux kernel, the following vulnerability has been resolved: Input: powermate - fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
- https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46
- https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd
- https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b11f461bc
- https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc
- https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f
- https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9
- https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06
- https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8
- https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46
- https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd
- https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b11f461bc
- https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc
- https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f
- https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9
- https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06
- https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8
Modified: 2026-01-05
CVE-2023-52476
In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region.
- https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c
- https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265
- https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db
- https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c
- https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c
- https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265
- https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db
Modified: 2024-12-09
CVE-2023-52477
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev->bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev->bos will be NULL and those accesses will result in a
crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1
- https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289
- https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c
- https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b
- https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3
- https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d
- https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81
- https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee
- https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81
- https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289
- https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c
- https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b
- https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3
- https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d
- https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81
- https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee
- https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81
Modified: 2025-01-10
CVE-2023-52478
In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated---
- https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1
- https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528
- https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c
- https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5
- https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b
- https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452
- https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e
- https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d
- https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1
- https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528
- https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c
- https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5
- https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b
- https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452
- https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e
- https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d
Modified: 2025-03-19
CVE-2023-52479
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix uaf in smb20_oplock_break_ack drop reference after use opinfo.
- https://git.kernel.org/stable/c/694e13732e830cbbfedb562e57f28644927c33fd
- https://git.kernel.org/stable/c/8226ffc759ea59f10067b9acdf7f94bae1c69930
- https://git.kernel.org/stable/c/c69813471a1ec081a0b9bf0c6bd7e8afd818afce
- https://git.kernel.org/stable/c/d5b0e9d3563e7e314a850e81f42b2ef6f39882f9
- https://git.kernel.org/stable/c/694e13732e830cbbfedb562e57f28644927c33fd
- https://git.kernel.org/stable/c/8226ffc759ea59f10067b9acdf7f94bae1c69930
- https://git.kernel.org/stable/c/c69813471a1ec081a0b9bf0c6bd7e8afd818afce
- https://git.kernel.org/stable/c/d5b0e9d3563e7e314a850e81f42b2ef6f39882f9
Modified: 2025-01-13
CVE-2023-52480
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix race condition between session lookup and expire Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | + This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session.
- https://git.kernel.org/stable/c/18ced78b0ebccc2d16f426143dc56ab3aad666be
- https://git.kernel.org/stable/c/53ff5cf89142b978b1a5ca8dc4d4425e6a09745f
- https://git.kernel.org/stable/c/a2ca5fd3dbcc665e1169044fa0c9e3eba779202b
- https://git.kernel.org/stable/c/c77fd3e25a51ac92b0f1b347a96eff6a0b4f066f
- https://git.kernel.org/stable/c/18ced78b0ebccc2d16f426143dc56ab3aad666be
- https://git.kernel.org/stable/c/53ff5cf89142b978b1a5ca8dc4d4425e6a09745f
- https://git.kernel.org/stable/c/a2ca5fd3dbcc665e1169044fa0c9e3eba779202b
- https://git.kernel.org/stable/c/c77fd3e25a51ac92b0f1b347a96eff6a0b4f066f
Modified: 2025-04-04
CVE-2023-52481
In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Add Cortex-A520 speculative unprivileged load workaround Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient. The workaround isn't necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. Page table isolation should normally be disabled for Cortex-A520 as it supports the CSV3 feature and the E0PD feature (used when KASLR is enabled).
- https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25
- https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513
- https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c
- https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25
- https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513
- https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c
Modified: 2025-01-13
CVE-2023-52483
In the Linux kernel, the following vulnerability has been resolved:
mctp: perform route lookups under a RCU read-side lock
Our current route lookups (mctp_route_lookup and mctp_route_lookup_null)
traverse the net's route list without the RCU read lock held. This means
the route lookup is subject to preemption, resulting in an potential
grace period expiry, and so an eventual kfree() while we still have the
route pointer.
Add the proper read-side critical section locks around the route
lookups, preventing premption and a possible parallel kfree.
The remaining net->mctp.routes accesses are already under a
rcu_read_lock, or protected by the RTNL for updates.
Based on an analysis from Sili Luo
- https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a
- https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4
- https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c
- https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67
- https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a
- https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4
- https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c
- https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67
Modified: 2024-12-10
CVE-2023-52484
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains. The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold.
- https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429
- https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6
- https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b
- https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264
- https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429
- https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6
- https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b
- https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264
Modified: 2025-01-14
CVE-2023-52486
In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.
- https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229
- https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0
- https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7
- https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551
- https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a
- https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c
- https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c
- https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105
- https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229
- https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0
- https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7
- https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551
- https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a
- https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c
- https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c
- https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-14
CVE-2023-52488
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte. The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_ versions in order to remove the manual cache control which was a workaround when using the _raw_ versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses.
- https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db
- https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573
- https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611
- https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23
- https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b
- https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169
- https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db
- https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573
- https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611
- https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23
- https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b
- https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-14
CVE-2023-52489
In the Linux kernel, the following vulnerability has been resolved: mm/sparsemem: fix race in accessing memory_section->usage The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When from other core, the section mappings are being removed for the ZONE_DEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1]. compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()//return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Free the array ms->usage and set ms->usage = NULL] pfn_section_valid() [Access ms->usage which is NULL] NOTE: From the above it can be said that the race is reduced to between the pfn_valid()/pfn_section_valid() and the section deactivate with SPASEMEM_VMEMAP enabled. The commit b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") tried to address the same problem by clearing the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns false thus ms->usage is not accessed. Fix this issue by the below steps: a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage. b) RCU protected read side critical section will either return NULL when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage. c) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No attempt will be made to access ->usage after this as the SECTION_HAS_MEM_MAP is cleared thus valid_section() return false. Thanks to David/Pavan for their inputs on this patch. [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/ On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm. For this particular issue below is the log. Though the below log is not directly pointing to the pfn_section_valid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing. [ 540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 540.578068] Mem abort info: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [ 540.578077] SET = 0, FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: level 1 translation fault [ 540.578085] Data abort info: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated---
- https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7
- https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800
- https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a
- https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97
- https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea
- https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529
- https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7
- https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800
- https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a
- https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97
- https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea
- https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52491
In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
- https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590
- https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e
- https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9
- https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c
- https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7
- https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6
- https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590
- https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e
- https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9
- https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c
- https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7
- https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2023-52492
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel unregistration function __dma_async_device_channel_register() can fail. In case of failure, chan->local is freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [ 1.484499] Call trace: [ 1.486930] device_del+0x40/0x394 [ 1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Look at dma_async_device_register() function error path, channel device unregistration is done only if chan->local is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function.
- https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79
- https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08
- https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b
- https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0
- https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17
- https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7
- https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79
- https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08
- https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b
- https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0
- https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17
- https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52493
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Drop chan lock before queuing buffers Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup. [mani: added fixes tag and cc'ed stable]
- https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b
- https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e
- https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690
- https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece
- https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830
- https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e
- https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b
- https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e
- https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690
- https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece
- https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830
- https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-14
CVE-2023-52494
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Add alignment check for event ring read pointer Though we do check the event ring read pointer by "is_valid_ring_ptr" to make sure it is in the buffer range, but there is another risk the pointer may be not aligned. Since we are expecting event ring elements are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer could lead to multiple issues like DoS or ring buffer memory corruption. So add a alignment check for event ring read pointer.
- https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551
- https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08
- https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010
- https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b
- https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f
- https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551
- https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08
- https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010
- https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b
- https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f
Modified: 2025-01-09
CVE-2023-52497
In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order.
- https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847
- https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de
- https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184
- https://git.kernel.org/stable/c/9ff2d260b25df6fe1341a79113d88fecf6bd553e
- https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379
- https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e
- https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae
- https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847
- https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de
- https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184
- https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379
- https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e
- https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52498
In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false.
- https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557
- https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7
- https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0
- https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34
- https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe
- https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d
- https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557
- https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7
- https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0
- https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34
- https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe
- https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-13
CVE-2023-52499
In the Linux kernel, the following vulnerability has been resolved:
powerpc/47x: Fix 47x syscall return crash
Eddie reported that newer kernels were crashing during boot on his 476
FSP2 system:
kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0xb7ee2000
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K FSP-2
Modules linked in:
CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1
Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2
NIP: b7ee2000 LR: 8c008000 CTR: 00000000
REGS: bffebd83 TRAP: 0400 Not tainted (6.1.55-d23900f.ppcnf-fs p2)
MSR: 00000030
- https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820
- https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746
- https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3
- https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14
- https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820
- https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746
- https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3
- https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14
Modified: 2025-01-13
CVE-2023-52500
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed when we receive the response.
- https://git.kernel.org/stable/c/2259e1901b2d8c0e8538fc99e77de443b939e749
- https://git.kernel.org/stable/c/22e6d783a33015bcdf0979015e4eac603912bea7
- https://git.kernel.org/stable/c/2afd8fcee0c4d65a482e30c3ad2a92c25e5e92d4
- https://git.kernel.org/stable/c/c13e7331745852d0dd7c35eabbe181cbd5b01172
- https://git.kernel.org/stable/c/d540a4370aba378fbedf349ba0bb68e96e24243d
- https://git.kernel.org/stable/c/2259e1901b2d8c0e8538fc99e77de443b939e749
- https://git.kernel.org/stable/c/22e6d783a33015bcdf0979015e4eac603912bea7
- https://git.kernel.org/stable/c/2afd8fcee0c4d65a482e30c3ad2a92c25e5e92d4
- https://git.kernel.org/stable/c/c13e7331745852d0dd7c35eabbe181cbd5b01172
- https://git.kernel.org/stable/c/d540a4370aba378fbedf349ba0bb68e96e24243d
Modified: 2025-01-13
CVE-2023-52501
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not attempt to read past "commit" When iterating over the ring buffer while the ring buffer is active, the writer can corrupt the reader. There's barriers to help detect this and handle it, but that code missed the case where the last event was at the very end of the page and has only 4 bytes left. The checks to detect the corruption by the writer to reads needs to see the length of the event. If the length in the first 4 bytes is zero then the length is stored in the second 4 bytes. But if the writer is in the process of updating that code, there's a small window where the length in the first 4 bytes could be zero even though the length is only 4 bytes. That will cause rb_event_length() to read the next 4 bytes which could happen to be off the allocated page. To protect against this, fail immediately if the next event pointer is less than 8 bytes from the end of the commit (last byte of data), as all events must be a minimum of 8 bytes anyway.
- https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d
- https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a
- https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca
- https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49
- https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3
- https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d
- https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a
- https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca
- https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49
- https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3
Modified: 2025-03-19
CVE-2023-52502
In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn() Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF. Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock. nfc_llcp_sock_get_sn() has a similar problem. Finally nfc_llcp_recv_snl() needs to make sure the socket found by nfc_llcp_sock_from_sn() does not disappear.
- https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11ff058d93
- https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9
- https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d
- https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c
- https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8
- https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc
- https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a
- https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11ff058d93
- https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9
- https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d
- https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c
- https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8
- https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc
- https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a
Modified: 2024-12-10
CVE-2023-52503
In the Linux kernel, the following vulnerability has been resolved: tee: amdtee: fix use-after-free vulnerability in amdtee_close_session There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session); the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return 'sess' that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session. To fix this issue, treat decrement of sess->refcount and removal of 'sess' from session list in destroy_session() as a critical section, so that it is executed atomically.
- https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116
- https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce
- https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c
- https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27
- https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f
- https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116
- https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce
- https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c
- https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27
- https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f
Modified: 2024-12-11
CVE-2023-52504
In the Linux kernel, the following vulnerability has been resolved: x86/alternatives: Disable KASAN in apply_alternatives() Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine: BUG: KASAN: out-of-bounds in rcu_is_watching() Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0 ... __asan_load4() rcu_is_watching() trace_hardirqs_on() text_poke_early() apply_alternatives() ... On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled(). KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue. Fix it for real by disabling KASAN while the kernel is patching alternatives. [ mingo: updated the changelog ]
- https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae
- https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1
- https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b
- https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e
- https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4
- https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff8dacf61
- https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc
- https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae
- https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1
- https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b
- https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e
- https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4
- https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff8dacf61
- https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc
Modified: 2025-01-13
CVE-2023-52505
In the Linux kernel, the following vulnerability has been resolved: phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the "old" or for the "new" protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking. Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers.
- https://git.kernel.org/stable/c/139ad1143151a07be93bf741d4ea7c89e59f89ce
- https://git.kernel.org/stable/c/6f901f8448c6b25ed843796b114471d2a3fc5dfb
- https://git.kernel.org/stable/c/c2d7c79898b427d263c64a4841987eec131f2d4e
- https://git.kernel.org/stable/c/139ad1143151a07be93bf741d4ea7c89e59f89ce
- https://git.kernel.org/stable/c/6f901f8448c6b25ed843796b114471d2a3fc5dfb
- https://git.kernel.org/stable/c/c2d7c79898b427d263c64a4841987eec131f2d4e
Modified: 2025-01-13
CVE-2023-52506
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Set all reserved memblocks on Node#0 at initialization After commit 61167ad5fecdea ("mm: pass nid to reserve_bootmem_region()") we get a panic if DEFERRED_STRUCT_PAGE_INIT is enabled: [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000002b82, era == 90000000040e3f28, ra == 90000000040e3f18 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #733 [ 0.000000] pc 90000000040e3f28 ra 90000000040e3f18 tp 90000000046f4000 sp 90000000046f7c90 [ 0.000000] a0 0000000000000001 a1 0000000000200000 a2 0000000000000040 a3 90000000046f7ca0 [ 0.000000] a4 90000000046f7ca4 a5 0000000000000000 a6 90000000046f7c38 a7 0000000000000000 [ 0.000000] t0 0000000000000002 t1 9000000004b00ac8 t2 90000000040e3f18 t3 90000000040f0800 [ 0.000000] t4 00000000000f0000 t5 80000000ffffe07e t6 0000000000000003 t7 900000047fff5e20 [ 0.000000] t8 aaaaaaaaaaaaaaab u0 0000000000000018 s9 0000000000000000 s0 fffffefffe000000 [ 0.000000] s1 0000000000000000 s2 0000000000000080 s3 0000000000000040 s4 0000000000000000 [ 0.000000] s5 0000000000000000 s6 fffffefffe000000 s7 900000000470b740 s8 9000000004ad4000 [ 0.000000] ra: 90000000040e3f18 reserve_bootmem_region+0xec/0x21c [ 0.000000] ERA: 90000000040e3f28 reserve_bootmem_region+0xfc/0x21c [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010800 [PIL] (IS=11 ECode=1 EsubCode=0) [ 0.000000] BADV: 0000000000002b82 [ 0.000000] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 0000000000000000 9000000002eb5430 0000003a00000020 90000000045ccd00 [ 0.000000] 900000000470e000 90000000002c1918 0000000000000000 9000000004110780 [ 0.000000] 00000000fe6c0000 0000000480000000 9000000004b4e368 9000000004110748 [ 0.000000] 0000000000000000 900000000421ca84 9000000004620000 9000000004564970 [ 0.000000] 90000000046f7d78 9000000002cc9f70 90000000002c1918 900000000470e000 [ 0.000000] 9000000004564970 90000000040bc0e0 90000000046f7d78 0000000000000000 [ 0.000000] 0000000000004000 90000000045ccd00 0000000000000000 90000000002c1918 [ 0.000000] 90000000002c1900 900000000470b700 9000000004b4df78 9000000004620000 [ 0.000000] 90000000046200a8 90000000046200a8 0000000000000000 9000000004218b2c [ 0.000000] 9000000004270008 0000000000000001 0000000000000000 90000000045ccd00 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<90000000040e3f28>] reserve_bootmem_region+0xfc/0x21c [ 0.000000] [<900000000421ca84>] memblock_free_all+0x114/0x350 [ 0.000000] [<9000000004218b2c>] mm_core_init+0x138/0x3cc [ 0.000000] [<9000000004200e38>] start_kernel+0x488/0x7a4 [ 0.000000] [<90000000040df0d8>] kernel_entry+0xd8/0xdc [ 0.000000] [ 0.000000] Code: 02eb21ad 00410f4c 380c31ac <262b818d> 6800b70d 02c1c196 0015001c 57fe4bb1 260002cd The reason is early memblock_reserve() in memblock_init() set node id to MAX_NUMNODES, making NODE_DATA(nid) a NULL dereference in the call chain reserve_bootmem_region() -> init_reserved_page(). After memblock_init(), those late calls of memblock_reserve() operate on subregions of memblock .memory regions. As a result, these reserved regions will be set to the correct node at the first iteration of memmap_init_reserved_pages(). So set all reserved memblocks on Node#0 at initialization can avoid this panic.
- https://git.kernel.org/stable/c/19878758accf6b2788091a771d9f9fee7bab11ab
- https://git.kernel.org/stable/c/b795fb9f5861ee256070d59e33130980a01fadd7
- https://git.kernel.org/stable/c/f105e893a8edd48bdf4bef9fef845a9ff402f737
- https://git.kernel.org/stable/c/19878758accf6b2788091a771d9f9fee7bab11ab
- https://git.kernel.org/stable/c/b795fb9f5861ee256070d59e33130980a01fadd7
- https://git.kernel.org/stable/c/f105e893a8edd48bdf4bef9fef845a9ff402f737
Modified: 2025-01-13
CVE-2023-52507
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: assert requested protocol is valid The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesn't potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones.
- https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213
- https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53
- https://git.kernel.org/stable/c/354a6e707e29cb0c007176ee5b8db8be7bd2dee0
- https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c21521da
- https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848
- https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb
- https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802
- https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729
- https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213
- https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53
- https://git.kernel.org/stable/c/354a6e707e29cb0c007176ee5b8db8be7bd2dee0
- https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c21521da
- https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848
- https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb
- https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802
- https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729
Modified: 2025-03-19
CVE-2023-52508
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid() The nvme_fc_fcp_op structure describing an AEN operation is initialized with a null request structure pointer. An FC LLDD may make a call to nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation. Add validation of the request structure pointer before dereference.
- https://git.kernel.org/stable/c/8ae5b3a685dc59a8cf7ccfe0e850999ba9727a3c
- https://git.kernel.org/stable/c/be90c9e29dd59b7d19a73297a1590ff3ec1d22ea
- https://git.kernel.org/stable/c/dd46b3ac7322baf3772b33b29726e94f98289db7
- https://git.kernel.org/stable/c/8ae5b3a685dc59a8cf7ccfe0e850999ba9727a3c
- https://git.kernel.org/stable/c/be90c9e29dd59b7d19a73297a1590ff3ec1d22ea
- https://git.kernel.org/stable/c/dd46b3ac7322baf3772b33b29726e94f98289db7
Modified: 2024-12-11
CVE-2023-52509
In the Linux kernel, the following vulnerability has been resolved: ravb: Fix use-after-free issue in ravb_tx_timeout_work() The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work() is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout() ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called, netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop().
- https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705
- https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89
- https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6
- https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5
- https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965
- https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82
- https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705
- https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89
- https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6
- https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5
- https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965
- https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82
Modified: 2024-12-11
CVE-2023-52510
In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: Fix a potential UAF in ca8210_probe If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
- https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66
- https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add
- https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f
- https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e
- https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc
- https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f035415491640
- https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d
- https://git.kernel.org/stable/c/f990874b1c98fe8e57ee9385669f501822979258
- https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66
- https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add
- https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f
- https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e
- https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc
- https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f035415491640
- https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d
- https://git.kernel.org/stable/c/f990874b1c98fe8e57ee9385669f501822979258
Modified: 2025-04-29
CVE-2023-52511
In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: reduce DMA RX transfer width to single byte Through empirical testing it has been determined that sometimes RX SPI transfers with DMA enabled return corrupted data. This is down to single or even multiple bytes lost during DMA transfer from SPI peripheral to memory. It seems the RX FIFO within the SPI peripheral can become confused when performing bus read accesses wider than a single byte to it during an active SPI transfer. This patch reduces the width of individual DMA read accesses to the RX FIFO to a single byte to mitigate that issue.
- https://git.kernel.org/stable/c/171f8a49f212e87a8b04087568e1b3d132e36a18
- https://git.kernel.org/stable/c/b3c21c9c7289692f4019f163c3b06d8bdf78b355
- https://git.kernel.org/stable/c/e15bb292b24630ee832bfc7fd616bd72c7682bbb
- https://git.kernel.org/stable/c/ff05ed4ae214011464a0156f05cac1b0b46b5fbc
- https://git.kernel.org/stable/c/171f8a49f212e87a8b04087568e1b3d132e36a18
- https://git.kernel.org/stable/c/b3c21c9c7289692f4019f163c3b06d8bdf78b355
- https://git.kernel.org/stable/c/e15bb292b24630ee832bfc7fd616bd72c7682bbb
- https://git.kernel.org/stable/c/ff05ed4ae214011464a0156f05cac1b0b46b5fbc
Modified: 2025-03-19
CVE-2023-52512
In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: wpcm450: fix out of bounds write Write into 'pctrl->gpio_bank' happens before the check for GPIO index validity, so out of bounds write may happen. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/6c18c386fd13dbb3ff31a1086dabb526780d9bda
- https://git.kernel.org/stable/c/87d315a34133edcb29c4cadbf196ec6c30dfd47b
- https://git.kernel.org/stable/c/c9d7cac0fd27c74dd368e80dc4b5d0f9f2e13cf8
- https://git.kernel.org/stable/c/6c18c386fd13dbb3ff31a1086dabb526780d9bda
- https://git.kernel.org/stable/c/87d315a34133edcb29c4cadbf196ec6c30dfd47b
- https://git.kernel.org/stable/c/c9d7cac0fd27c74dd368e80dc4b5d0f9f2e13cf8
Modified: 2024-12-11
CVE-2023-52513
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix connection failure handling In case immediate MPA request processing fails, the newly created endpoint unlinks the listening endpoint and is ready to be dropped. This special case was not handled correctly by the code handling the later TCP socket close, causing a NULL dereference crash in siw_cm_work_handler() when dereferencing a NULL listener. We now also cancel the useless MPA timeout, if immediate MPA request processing fails. This patch furthermore simplifies MPA processing in general: Scheduling a useless TCP socket read in sk_data_ready() upcall is now surpressed, if the socket is already moved out of TCP_ESTABLISHED state.
- https://git.kernel.org/stable/c/0d520cdb0cd095eac5d00078dfd318408c9b5eed
- https://git.kernel.org/stable/c/53a3f777049771496f791504e7dc8ef017cba590
- https://git.kernel.org/stable/c/5cf38e638e5d01b68f9133968a85e8b3fd1ecf2f
- https://git.kernel.org/stable/c/6e26812e289b374c17677d238164a5a8f5770594
- https://git.kernel.org/stable/c/81b7bf367eea795d259d0261710c6a89f548844d
- https://git.kernel.org/stable/c/eeafc50a77f6a783c2c44e7ec3674a7b693e06f8
- https://git.kernel.org/stable/c/0d520cdb0cd095eac5d00078dfd318408c9b5eed
- https://git.kernel.org/stable/c/53a3f777049771496f791504e7dc8ef017cba590
- https://git.kernel.org/stable/c/5cf38e638e5d01b68f9133968a85e8b3fd1ecf2f
- https://git.kernel.org/stable/c/6e26812e289b374c17677d238164a5a8f5770594
- https://git.kernel.org/stable/c/81b7bf367eea795d259d0261710c6a89f548844d
- https://git.kernel.org/stable/c/eeafc50a77f6a783c2c44e7ec3674a7b693e06f8
Modified: 2024-12-11
CVE-2023-52515
In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned.
- https://git.kernel.org/stable/c/05a10b316adaac1f322007ca9a0383b410d759cc
- https://git.kernel.org/stable/c/26788a5b48d9d5cd3283d777d238631c8cd7495a
- https://git.kernel.org/stable/c/2b298f9181582270d5e95774e5a6c7a7fb5b1206
- https://git.kernel.org/stable/c/b9bdffb3f9aaeff8379c83f5449c6b42cb71c2b5
- https://git.kernel.org/stable/c/e193b7955dfad68035b983a0011f4ef3590c85eb
- https://git.kernel.org/stable/c/05a10b316adaac1f322007ca9a0383b410d759cc
- https://git.kernel.org/stable/c/26788a5b48d9d5cd3283d777d238631c8cd7495a
- https://git.kernel.org/stable/c/2b298f9181582270d5e95774e5a6c7a7fb5b1206
- https://git.kernel.org/stable/c/b9bdffb3f9aaeff8379c83f5449c6b42cb71c2b5
- https://git.kernel.org/stable/c/e193b7955dfad68035b983a0011f4ef3590c85eb
Modified: 2024-12-11
CVE-2023-52516
In the Linux kernel, the following vulnerability has been resolved: dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8 ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}: __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key --> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock); lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated---
- https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c
- https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab
- https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae
- https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1
- https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3
- https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c
- https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab
- https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae
- https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1
- https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3
Modified: 2025-01-13
CVE-2023-52517
In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain Previously the transfer complete IRQ immediately drained to RX FIFO to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any data read. Additionally the RX buffer pointer is never adjusted according to DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA mode is a bug. Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode. Also wait for completion of RX DMA when in DMA mode before returning to ensure all data has been copied to the supplied memory buffer.
- https://git.kernel.org/stable/c/1f11f4202caf5710204d334fe63392052783876d
- https://git.kernel.org/stable/c/36b29974a7ad2ff604c24ad348f940506c7b1209
- https://git.kernel.org/stable/c/4e149d524678431638ff378ef6025e4e89b71097
- https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f
- https://git.kernel.org/stable/c/1f11f4202caf5710204d334fe63392052783876d
- https://git.kernel.org/stable/c/36b29974a7ad2ff604c24ad348f940506c7b1209
- https://git.kernel.org/stable/c/4e149d524678431638ff378ef6025e4e89b71097
- https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f
Modified: 2025-03-19
CVE-2023-52518
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_codec: Fix leaking content of local_codecs
The following memory leak can be observed when the controller supports
codecs which are stored in local_codecs list but the elements are never
freed:
unreferenced object 0xffff88800221d840 (size 32):
comm "kworker/u3:0", pid 36, jiffies 4294898739 (age 127.060s)
hex dump (first 32 bytes):
f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff ..........!.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/626535077ba9dc110787540d1fe24881094c15a1
- https://git.kernel.org/stable/c/b938790e70540bf4f2e653dcd74b232494d06c8f
- https://git.kernel.org/stable/c/eea5a8f0c3b7c884d2351e75fbdd0a3d7def5ae1
- https://git.kernel.org/stable/c/626535077ba9dc110787540d1fe24881094c15a1
- https://git.kernel.org/stable/c/b938790e70540bf4f2e653dcd74b232494d06c8f
- https://git.kernel.org/stable/c/eea5a8f0c3b7c884d2351e75fbdd0a3d7def5ae1
Modified: 2025-01-13
CVE-2023-52519
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) service, which allows to wakup device when the system is in S5 (Soft-Off state). This OOB service can be enabled/disabled from BIOS settings. When enabled, the ISH device gets PME wake capability. To enable PME wakeup, driver also needs to enable ACPI GPE bit. On resume, BIOS will clear the wakeup bit. So driver need to re-enable it in resume function to keep the next wakeup capability. But this BIOS clearing of wakeup bit doesn't decrement internal OS GPE reference count, so this reenabling on every resume will cause reference count to overflow. So first disable and reenable ACPI GPE bit using acpi_disable_gpe().
- https://git.kernel.org/stable/c/60fb3f054c99608ddb1f2466c07108da6292951e
- https://git.kernel.org/stable/c/8781fe259dd5a178fdd1069401bbd1437f9491c5
- https://git.kernel.org/stable/c/8f02139ad9a7e6e5c05712f8c1501eebed8eacfd
- https://git.kernel.org/stable/c/cdcc04e844a2d22d9d25cef1e8e504a174ea9f8f
- https://git.kernel.org/stable/c/60fb3f054c99608ddb1f2466c07108da6292951e
- https://git.kernel.org/stable/c/8781fe259dd5a178fdd1069401bbd1437f9491c5
- https://git.kernel.org/stable/c/8f02139ad9a7e6e5c05712f8c1501eebed8eacfd
- https://git.kernel.org/stable/c/cdcc04e844a2d22d9d25cef1e8e504a174ea9f8f
Modified: 2024-12-11
CVE-2023-52520
In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"), so it seems that the bug was copied from that driver. Compile-tested only.
- https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293
- https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81
- https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4
- https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106
- https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293
- https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81
- https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4
- https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106
Modified: 2025-09-16
CVE-2023-52522
In the Linux kernel, the following vulnerability has been resolved: net: fix possible store tearing in neigh_periodic_work() While looking at a related syzbot report involving neigh_periodic_work(), I found that I forgot to add an annotation when deleting an RCU protected item from a list. Readers use rcu_deference(*np), we need to use either rcu_assign_pointer() or WRITE_ONCE() on writer side to prevent store tearing. I use rcu_assign_pointer() to have lockdep support, this was the choice made in neigh_flush_dev().
- https://git.kernel.org/stable/c/147d89ee41434b97043c2dcb17a97dc151859baa
- https://git.kernel.org/stable/c/25563b581ba3a1f263a00e8c9a97f5e7363be6fd
- https://git.kernel.org/stable/c/2ea52a2fb8e87067e26bbab4efb8872639240eb0
- https://git.kernel.org/stable/c/95eabb075a5902f4c0834ab1fb12dc35730c05af
- https://git.kernel.org/stable/c/a75152d233370362eebedb2643592e7c883cc9fc
- https://git.kernel.org/stable/c/f82aac8162871e87027692b36af335a2375d4580
- https://git.kernel.org/stable/c/147d89ee41434b97043c2dcb17a97dc151859baa
- https://git.kernel.org/stable/c/25563b581ba3a1f263a00e8c9a97f5e7363be6fd
- https://git.kernel.org/stable/c/2ea52a2fb8e87067e26bbab4efb8872639240eb0
- https://git.kernel.org/stable/c/95eabb075a5902f4c0834ab1fb12dc35730c05af
- https://git.kernel.org/stable/c/a75152d233370362eebedb2643592e7c883cc9fc
- https://git.kernel.org/stable/c/f82aac8162871e87027692b36af335a2375d4580
Modified: 2025-01-13
CVE-2023-52523
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets
With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages
sent from one TCP socket (s1) to actually egress from another TCP
socket (s2):
tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg
tcp_bpf_send_verdict(s1) // __SK_REDIRECT case
tcp_bpf_sendmsg_redir(s2)
tcp_bpf_push_locked(s2)
tcp_bpf_push(s2)
tcp_rate_check_app_limited(s2) // expects tcp_sock
tcp_sendmsg_locked(s2) // ditto
There is a hard-coded assumption in the call-chain, that the egress
socket (s2) is a TCP socket.
However in commit 122e6c79efe1 ("sock_map: Update sock type checks for
UDP") we have enabled redirects to non-TCP sockets. This was done for the
sake of BPF sk_skb programs. There was no indention to support sk_msg
send-to-egress use case.
As a result, attempts to send-to-egress through a non-TCP socket lead to a
crash due to invalid downcast from sock to tcp_sock:
BUG: kernel NULL pointer dereference, address: 000000000000002f
...
Call Trace:
- https://git.kernel.org/stable/c/b80e31baa43614e086a9d29dc1151932b1bd7fc5
- https://git.kernel.org/stable/c/b8f97e47b6fb84fcf2f5a22e725eefb6cf5070c2
- https://git.kernel.org/stable/c/bc8b89b6963803a123f64aa9494155a037b3d728
- https://git.kernel.org/stable/c/ded6e448028f0f91b6af35985afca01fa02a9089
- https://git.kernel.org/stable/c/b80e31baa43614e086a9d29dc1151932b1bd7fc5
- https://git.kernel.org/stable/c/b8f97e47b6fb84fcf2f5a22e725eefb6cf5070c2
- https://git.kernel.org/stable/c/bc8b89b6963803a123f64aa9494155a037b3d728
- https://git.kernel.org/stable/c/ded6e448028f0f91b6af35985afca01fa02a9089
Modified: 2024-12-11
CVE-2023-52526
In the Linux kernel, the following vulnerability has been resolved: erofs: fix memory leak of LZMA global compressed deduplication When stressing microLZMA EROFS images with the new global compressed deduplication feature enabled (`-Ededupe`), I found some short-lived temporary pages weren't properly released, which could slowly cause unexpected OOMs hours later. Let's fix it now (LZ4 and DEFLATE don't have this issue.)
- https://git.kernel.org/stable/c/6a5a8f0a9740f865693d5aa97a42cc4504538e18
- https://git.kernel.org/stable/c/75a5221630fe5aa3fedba7a06be618db0f79ba1e
- https://git.kernel.org/stable/c/c955751cbf864cf2055117dd3fe7f780d2a57b56
- https://git.kernel.org/stable/c/6a5a8f0a9740f865693d5aa97a42cc4504538e18
- https://git.kernel.org/stable/c/75a5221630fe5aa3fedba7a06be618db0f79ba1e
- https://git.kernel.org/stable/c/c955751cbf864cf2055117dd3fe7f780d2a57b56
Modified: 2025-01-13
CVE-2023-52527
In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we don't want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 that occurs when MSG_SPLICE_PAGES is used to append more data to an already partially occupied skbuff. The warning occurs when 'copy' is larger than the amount of data in the message iterator. This is because the requested length includes the transport header length when it shouldn't. This can be triggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024); Fix this by only adding transhdrlen into the length if the write queue is empty in l2tp_ip6_sendmsg(), analogously to how UDP does things. l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds the UDP packet itself.
- https://git.kernel.org/stable/c/1fc793d68d50dee4782ef2e808913d5dd880bcc6
- https://git.kernel.org/stable/c/559d697c5d072593d22b3e0bd8b8081108aeaf59
- https://git.kernel.org/stable/c/7626b9fed53092aa2147978070e610ecb61af844
- https://git.kernel.org/stable/c/96b2e1090397217839fcd6c9b6d8f5d439e705ed
- https://git.kernel.org/stable/c/9d4c75800f61e5d75c1659ba201b6c0c7ead3070
- https://git.kernel.org/stable/c/cd1189956393bf850b2e275e37411855d3bd86bb
- https://git.kernel.org/stable/c/f6a7182179c0ed788e3755ee2ed18c888ddcc33f
- https://git.kernel.org/stable/c/fe80658c08e3001c80c5533cd41abfbb0e0e28fd
- https://git.kernel.org/stable/c/1fc793d68d50dee4782ef2e808913d5dd880bcc6
- https://git.kernel.org/stable/c/559d697c5d072593d22b3e0bd8b8081108aeaf59
- https://git.kernel.org/stable/c/7626b9fed53092aa2147978070e610ecb61af844
- https://git.kernel.org/stable/c/96b2e1090397217839fcd6c9b6d8f5d439e705ed
- https://git.kernel.org/stable/c/9d4c75800f61e5d75c1659ba201b6c0c7ead3070
- https://git.kernel.org/stable/c/cd1189956393bf850b2e275e37411855d3bd86bb
- https://git.kernel.org/stable/c/f6a7182179c0ed788e3755ee2ed18c888ddcc33f
- https://git.kernel.org/stable/c/fe80658c08e3001c80c5533cd41abfbb0e0e28fd
Modified: 2024-12-11
CVE-2023-52528
In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable ----buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested.
- https://git.kernel.org/stable/c/2a36d9e2995c8c3c3f179aab1215a69cff06cbed
- https://git.kernel.org/stable/c/30bc4d7aebe33904b0f2d3aad4b4a9c6029ad0c5
- https://git.kernel.org/stable/c/310f1c92f65ad905b7e81fe14de82d979ebbd825
- https://git.kernel.org/stable/c/3e0af6eec1789fd11934164a7f4dbcad979855a4
- https://git.kernel.org/stable/c/4931e80da9463b03bfe42be54a9a19f213b0f76d
- https://git.kernel.org/stable/c/9ffc5018020fe646795a8dc1203224b8f776dc09
- https://git.kernel.org/stable/c/cda10784a176d7192f08ecb518f777a4e9575812
- https://git.kernel.org/stable/c/e9c65989920f7c28775ec4e0c11b483910fb67b8
- https://git.kernel.org/stable/c/2a36d9e2995c8c3c3f179aab1215a69cff06cbed
- https://git.kernel.org/stable/c/30bc4d7aebe33904b0f2d3aad4b4a9c6029ad0c5
- https://git.kernel.org/stable/c/310f1c92f65ad905b7e81fe14de82d979ebbd825
- https://git.kernel.org/stable/c/3e0af6eec1789fd11934164a7f4dbcad979855a4
- https://git.kernel.org/stable/c/4931e80da9463b03bfe42be54a9a19f213b0f76d
- https://git.kernel.org/stable/c/9ffc5018020fe646795a8dc1203224b8f776dc09
- https://git.kernel.org/stable/c/cda10784a176d7192f08ecb518f777a4e9575812
- https://git.kernel.org/stable/c/e9c65989920f7c28775ec4e0c11b483910fb67b8
Modified: 2025-03-19
CVE-2023-52529
In the Linux kernel, the following vulnerability has been resolved: HID: sony: Fix a potential memory leak in sony_probe() If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() should be called.
- https://git.kernel.org/stable/c/bb0707fde7492121917fd9ddb43829e96ec0bb9e
- https://git.kernel.org/stable/c/e1cd4004cde7c9b694bbdd8def0e02288ee58c74
- https://git.kernel.org/stable/c/f237b17611fa3501f43f12d1cb64323e10fdcb4f
- https://git.kernel.org/stable/c/f566efa7de1e35e6523f4acbaf85068a540be07d
- https://git.kernel.org/stable/c/bb0707fde7492121917fd9ddb43829e96ec0bb9e
- https://git.kernel.org/stable/c/e1cd4004cde7c9b694bbdd8def0e02288ee58c74
- https://git.kernel.org/stable/c/f237b17611fa3501f43f12d1cb64323e10fdcb4f
- https://git.kernel.org/stable/c/f566efa7de1e35e6523f4acbaf85068a540be07d
Modified: 2025-11-03
CVE-2023-52530
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential key use-after-free When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add().
- https://git.kernel.org/stable/c/2408f491ff998d674707725eadc47d8930aced09
- https://git.kernel.org/stable/c/2f4e16e39e4f5e78248dd9e51276a83203950b36
- https://git.kernel.org/stable/c/31db78a4923ef5e2008f2eed321811ca79e7f71b
- https://git.kernel.org/stable/c/65c72a7201704574dace708cbc96a8f367b1491d
- https://git.kernel.org/stable/c/e8a834eb09bb95c2bf9c76f1a28ecef7d8c439d0
- https://git.kernel.org/stable/c/e8e599a635066c50ac214c3e10858f1d37e03022
- https://git.kernel.org/stable/c/2f4e16e39e4f5e78248dd9e51276a83203950b36
- https://git.kernel.org/stable/c/31db78a4923ef5e2008f2eed321811ca79e7f71b
- https://git.kernel.org/stable/c/65c72a7201704574dace708cbc96a8f367b1491d
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2024-12-11
CVE-2023-52531
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct ieee80211_channel'. So only 1 element is allocated in this array. When doing: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the 'channels' flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1); because of the "(u8 *)" cast, we add only 1 to the address of the beginning of the flex array. It is likely that we want point at the 'struct ieee80211_rate' allocated just after. Remove the spurious casting so that the pointer arithmetic works as expected.
- https://git.kernel.org/stable/c/6b3223449c959a8be94a1f042288059e40fcccb0
- https://git.kernel.org/stable/c/7c8faa31080342aec4903c9acb20caf82fcca1ef
- https://git.kernel.org/stable/c/8ba438ef3cacc4808a63ed0ce24d4f0942cfe55d
- https://git.kernel.org/stable/c/f06cdd8d4ba5252986f51f80cc30263636397128
- https://git.kernel.org/stable/c/6b3223449c959a8be94a1f042288059e40fcccb0
- https://git.kernel.org/stable/c/7c8faa31080342aec4903c9acb20caf82fcca1ef
- https://git.kernel.org/stable/c/8ba438ef3cacc4808a63ed0ce24d4f0942cfe55d
- https://git.kernel.org/stable/c/f06cdd8d4ba5252986f51f80cc30263636397128
Modified: 2025-01-16
CVE-2023-52532
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TX CQE error handling For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging.
- https://git.kernel.org/stable/c/a910e0f6304726da30a212feecec65cb97ff7a80
- https://git.kernel.org/stable/c/b2b000069a4c307b09548dc2243f31f3ca0eac9c
- https://git.kernel.org/stable/c/b67d7b1bfc46d05c1a58b172516454698e8d5004
- https://git.kernel.org/stable/c/a910e0f6304726da30a212feecec65cb97ff7a80
- https://git.kernel.org/stable/c/b2b000069a4c307b09548dc2243f31f3ca0eac9c
- https://git.kernel.org/stable/c/b67d7b1bfc46d05c1a58b172516454698e8d5004
Modified: 2025-01-16
CVE-2023-52559
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Avoid memory allocation in iommu_suspend()
The iommu_suspend() syscore suspend callback is invoked with IRQ disabled.
Allocating memory with the GFP_KERNEL flag may re-enable IRQs during
the suspend callback, which can cause intermittent suspend/hibernation
problems with the following kernel traces:
Calling iommu_suspend+0x0/0x1d0
------------[ cut here ]------------
WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0
...
CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1
RIP: 0010:ktime_get+0x9b/0xb0
...
Call Trace:
- https://git.kernel.org/stable/c/29298c85a81abdc512e87537515ed4b1a9601d0e
- https://git.kernel.org/stable/c/496c591f0b389eb782f36d9d4c2564b9a865eed0
- https://git.kernel.org/stable/c/59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e
- https://git.kernel.org/stable/c/c12ef025add77ca3a0902e8719d552b6d47b4282
- https://git.kernel.org/stable/c/29298c85a81abdc512e87537515ed4b1a9601d0e
- https://git.kernel.org/stable/c/496c591f0b389eb782f36d9d4c2564b9a865eed0
- https://git.kernel.org/stable/c/59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e
- https://git.kernel.org/stable/c/c12ef025add77ca3a0902e8719d552b6d47b4282
Modified: 2024-12-11
CVE-2023-52560
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary
variables"), the damon_destroy_ctx() is removed, but still call
damon_new_target() and damon_new_region(), the damon_region which is
allocated by kmem_cache_alloc() in damon_new_region() and the damon_target
which is allocated by kmalloc in damon_new_target() are not freed. And
the damon_region which is allocated in damon_new_region() in
damon_set_regions() is also not freed.
So use damon_destroy_target to free all the damon_regions and damon_target.
unreferenced object 0xffff888107c9a940 (size 64):
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............
backtrace:
[
- https://git.kernel.org/stable/c/45120b15743fa7c0aa53d5db6dfb4c8f87be4abd
- https://git.kernel.org/stable/c/6b522001693aa113d97a985abc5f6932972e8e86
- https://git.kernel.org/stable/c/9a4fe81a8644b717d57d81ce5849e16583b13fe8
- https://git.kernel.org/stable/c/45120b15743fa7c0aa53d5db6dfb4c8f87be4abd
- https://git.kernel.org/stable/c/6b522001693aa113d97a985abc5f6932972e8e86
- https://git.kernel.org/stable/c/9a4fe81a8644b717d57d81ce5849e16583b13fe8
Modified: 2025-04-08
CVE-2023-52561
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved Adding a reserved memory region for the framebuffer memory (the splash memory region set up by the bootloader). It fixes a kernel panic (arm-smmu: Unhandled context fault at this particular memory region) reported on DB845c running v5.10.y.
- https://git.kernel.org/stable/c/110e70fccce4f22b53986ae797d665ffb1950aa6
- https://git.kernel.org/stable/c/82dacd0ca0d9640723824026d6fdf773c02de1d2
- https://git.kernel.org/stable/c/dc1ab6577475b0460ba4261cd9caec37bd62ca0b
- https://git.kernel.org/stable/c/110e70fccce4f22b53986ae797d665ffb1950aa6
- https://git.kernel.org/stable/c/82dacd0ca0d9640723824026d6fdf773c02de1d2
- https://git.kernel.org/stable/c/dc1ab6577475b0460ba4261cd9caec37bd62ca0b
Modified: 2025-01-16
CVE-2023-52562
In the Linux kernel, the following vulnerability has been resolved: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy() After the commit in Fixes:, if a module that created a slab cache does not release all of its allocated objects before destroying the cache (at rmmod time), we might end up releasing the kmem_cache object without removing it from the slab_caches list thus corrupting the list as kmem_cache_destroy() ignores the return value from shutdown_cache(), which in turn never removes the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails to release all of the cache's slabs. This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y as after that ill release the system will immediately trip on list_add, or list_del, assertions similar to the one shown below as soon as another kmem_cache gets created, or destroyed: [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268) [ 1041.219165] ------------[ cut here ]------------ [ 1041.221517] kernel BUG at lib/list_debug.c:62! [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y, is to set slub_debug to poison the released objects and then just run cat /proc/slabinfo after removing the module that leaks slab objects, in which case the kernel will panic: [ 50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0 This patch fixes this issue by properly checking shutdown_cache()'s return value before taking the kmem_cache_release() branch.
- https://git.kernel.org/stable/c/46a9ea6681907a3be6b6b0d43776dccc62cad6cf
- https://git.kernel.org/stable/c/51988be187b041e5355245957b0b9751fa382e0d
- https://git.kernel.org/stable/c/a5569bb187521432f509b69dda7d29f78b2d38b0
- https://git.kernel.org/stable/c/46a9ea6681907a3be6b6b0d43776dccc62cad6cf
- https://git.kernel.org/stable/c/51988be187b041e5355245957b0b9751fa382e0d
- https://git.kernel.org/stable/c/a5569bb187521432f509b69dda7d29f78b2d38b0
Modified: 2024-12-11
CVE-2023-52563
In the Linux kernel, the following vulnerability has been resolved: drm/meson: fix memory leak on ->hpd_notify callback The EDID returned by drm_bridge_get_edid() needs to be freed.
- https://git.kernel.org/stable/c/099f0af9d98231bb74956ce92508e87cbcb896be
- https://git.kernel.org/stable/c/43b63e088887a8b82750e16762f77100ffa76cba
- https://git.kernel.org/stable/c/66cb6d74f5a1b6eafe3370b56bf2cb575a91acbc
- https://git.kernel.org/stable/c/ee335e0094add7fc2c7034e0534e1920d61d2078
- https://git.kernel.org/stable/c/099f0af9d98231bb74956ce92508e87cbcb896be
- https://git.kernel.org/stable/c/43b63e088887a8b82750e16762f77100ffa76cba
- https://git.kernel.org/stable/c/66cb6d74f5a1b6eafe3370b56bf2cb575a91acbc
- https://git.kernel.org/stable/c/ee335e0094add7fc2c7034e0534e1920d61d2078
Modified: 2025-04-08
CVE-2023-52566
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly. [konishi.ryusuke@gmail.com: NOTE added to the commit log]
- https://git.kernel.org/stable/c/193b5a1c6c67c36b430989dc063fe7ea4e200a33
- https://git.kernel.org/stable/c/28df4646ad8b433340772edc90ca709cdefc53e2
- https://git.kernel.org/stable/c/3936e8714907cd55e37c7cc50e50229e4a9042e8
- https://git.kernel.org/stable/c/7130a87ca32396eb9bf48b71a2d42259ae44c6c7
- https://git.kernel.org/stable/c/7ee29facd8a9c5a26079148e36bcf07141b3a6bc
- https://git.kernel.org/stable/c/980663f1d189eedafd18d80053d9cf3e2ceb5c8c
- https://git.kernel.org/stable/c/bb61224f6abc8e71bfdf06d7c984e23460875f5b
- https://git.kernel.org/stable/c/fb1084e63ee56958b0a56e17a50a4fd86445b9c1
- https://git.kernel.org/stable/c/193b5a1c6c67c36b430989dc063fe7ea4e200a33
- https://git.kernel.org/stable/c/28df4646ad8b433340772edc90ca709cdefc53e2
- https://git.kernel.org/stable/c/3936e8714907cd55e37c7cc50e50229e4a9042e8
- https://git.kernel.org/stable/c/7130a87ca32396eb9bf48b71a2d42259ae44c6c7
- https://git.kernel.org/stable/c/7ee29facd8a9c5a26079148e36bcf07141b3a6bc
- https://git.kernel.org/stable/c/980663f1d189eedafd18d80053d9cf3e2ceb5c8c
- https://git.kernel.org/stable/c/bb61224f6abc8e71bfdf06d7c984e23460875f5b
- https://git.kernel.org/stable/c/fb1084e63ee56958b0a56e17a50a4fd86445b9c1
Modified: 2024-12-11
CVE-2023-52568
In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an enclave and set secs.epc_page to NULL. The SECS page is used for EAUG and ELDU in the SGX page fault handler. However, the NULL check for secs.epc_page is only done for ELDU, not EAUG before being used. Fix this by doing the same NULL check and reloading of the SECS page as needed for both EAUG and ELDU. The SECS page holds global enclave metadata. It can only be reclaimed when there are no other enclave pages remaining. At that point, virtually nothing can be done with the enclave until the SECS page is paged back in. An enclave can not run nor generate page faults without a resident SECS page. But it is still possible for a #PF for a non-SECS page to race with paging out the SECS page: when the last resident non-SECS page A triggers a #PF in a non-resident page B, and then page A and the SECS both are paged out before the #PF on B is handled. Hitting this bug requires that race triggered with a #PF for EAUG. Following is a trace when it happens. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:sgx_encl_eaug_page+0xc7/0x210 Call Trace: ? __kmem_cache_alloc_node+0x16a/0x440 ? xa_load+0x6e/0xa0 sgx_vma_fault+0x119/0x230 __do_fault+0x36/0x140 do_fault+0x12f/0x400 __handle_mm_fault+0x728/0x1110 handle_mm_fault+0x105/0x310 do_user_addr_fault+0x1ee/0x750 ? __this_cpu_preempt_check+0x13/0x20 exc_page_fault+0x76/0x180 asm_exc_page_fault+0x27/0x30
- https://git.kernel.org/stable/c/1348f7f15d7c7798456856bee74a4235c2da994e
- https://git.kernel.org/stable/c/811ba2ef0cb6402672e64ba1419d6ef95aa3405d
- https://git.kernel.org/stable/c/c6c2adcba50c2622ed25ba5d5e7f05f584711358
- https://git.kernel.org/stable/c/1348f7f15d7c7798456856bee74a4235c2da994e
- https://git.kernel.org/stable/c/811ba2ef0cb6402672e64ba1419d6ef95aa3405d
- https://git.kernel.org/stable/c/c6c2adcba50c2622ed25ba5d5e7f05f584711358
Modified: 2025-06-19
CVE-2023-52569
In the Linux kernel, the following vulnerability has been resolved: btrfs: remove BUG() after failure to insert delayed dir index item Instead of calling BUG() when we fail to insert a delayed dir index item into the delayed node's tree, we can just release all the resources we have allocated/acquired before and return the error to the caller. This is fine because all existing call chains undo anything they have done before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the transaction commit path). So remove the BUG() call and do proper error handling. This relates to a syzbot report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the issue where somehow we attempt to use twice the same index number for different index items.
- https://git.kernel.org/stable/c/2c58c3931ede7cd08cbecf1f1a4acaf0a04a41a9
- https://git.kernel.org/stable/c/d10fd53393cc5de4b9cf1a4b8f9984f0a037aa51
- https://git.kernel.org/stable/c/2c58c3931ede7cd08cbecf1f1a4acaf0a04a41a9
- https://git.kernel.org/stable/c/39c4a9522db0072570d602e9b365119e17fb9f4f
- https://git.kernel.org/stable/c/d10fd53393cc5de4b9cf1a4b8f9984f0a037aa51
Modified: 2024-12-11
CVE-2023-52570
In the Linux kernel, the following vulnerability has been resolved:
vfio/mdev: Fix a null-ptr-deref bug for mdev_unregister_parent()
Inject fault while probing mdpy.ko, if kstrdup() of create_dir() fails in
kobject_add_internal() in kobject_init_and_add() in mdev_type_add()
in parent_create_sysfs_files(), it will return 0 and probe successfully.
And when rmmod mdpy.ko, the mdpy_dev_exit() will call
mdev_unregister_parent(), the mdev_type_remove() may traverse uninitialized
parent->types[i] in parent_remove_sysfs_files(), and it will cause
below null-ptr-deref.
If mdev_type_add() fails, return the error code and kset_unregister()
to fix the issue.
general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 2 PID: 10215 Comm: rmmod Tainted: G W N 6.6.0-rc2+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:__kobject_del+0x62/0x1c0
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 24 01 00 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8
RSP: 0018:ffff88810695fd30 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffffffffa0270268 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000004 RDI: 0000000000000010
RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10233a4ef1
R10: ffff888119d2778b R11: 0000000063666572 R12: 0000000000000000
R13: fffffbfff404e2d4 R14: dffffc0000000000 R15: ffffffffa0271660
FS: 00007fbc81981540(0000) GS:ffff888119d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc14a142dc0 CR3: 0000000110a62003 CR4: 0000000000770ee0
DR0: ffffffff8fb0bce8 DR1: ffffffff8fb0bce9 DR2: ffffffff8fb0bcea
DR3: ffffffff8fb0bceb DR6: 00000000fffe0ff0 DR7: 0000000000000600
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/52093779b1830ac184a23848d971f06404cf513e
- https://git.kernel.org/stable/c/c01b2e0ee22ef8b4dd7509a93aecc0ac0826bae4
- https://git.kernel.org/stable/c/c777b11d34e0f47dbbc4b018ef65ad030f2b283a
- https://git.kernel.org/stable/c/52093779b1830ac184a23848d971f06404cf513e
- https://git.kernel.org/stable/c/c01b2e0ee22ef8b4dd7509a93aecc0ac0826bae4
- https://git.kernel.org/stable/c/c777b11d34e0f47dbbc4b018ef65ad030f2b283a
Modified: 2025-11-25
CVE-2023-52572
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix UAF in cifs_demultiplex_thread()
There is a UAF when xfstests on cifs:
BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160
Read of size 4 at addr ffff88810103fc08 by task cifsd/923
CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45
...
Call Trace:
- https://git.kernel.org/stable/c/76569e3819e0bb59fc19b1b8688b017e627c268a
- https://git.kernel.org/stable/c/908b3b5e97d25e879de3d1f172a255665491c2c3
- https://git.kernel.org/stable/c/99960d282fba6634fa758df4124cb73ef8a77d8a
- https://git.kernel.org/stable/c/d527f51331cace562393a8038d870b3e9916686f
- https://git.kernel.org/stable/c/ed3b36f351d97dacb62cd0f399e8cf79f73bd30a
- https://git.kernel.org/stable/c/fe87e2d0e6265859c659a3ef1e2559a83c5e8e68
- https://git.kernel.org/stable/c/76569e3819e0bb59fc19b1b8688b017e627c268a
- https://git.kernel.org/stable/c/908b3b5e97d25e879de3d1f172a255665491c2c3
- https://git.kernel.org/stable/c/d527f51331cace562393a8038d870b3e9916686f
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2024-12-11
CVE-2023-52573
In the Linux kernel, the following vulnerability has been resolved: net: rds: Fix possible NULL-pointer dereference In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists before dereferencing it as rdma_set_service_type() argument Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/069ac51c37a6f07a51f7134d8c34289075786a35
- https://git.kernel.org/stable/c/51fa66024a5eabf270164f2dc82a48ffb35a12e9
- https://git.kernel.org/stable/c/812da2a08dc5cc75fb71e29083ea20904510ac7a
- https://git.kernel.org/stable/c/ea82139e6e3561100d38d14401d57c0ea93fc07e
- https://git.kernel.org/stable/c/f1d95df0f31048f1c59092648997686e3f7d9478
- https://git.kernel.org/stable/c/f515112e833791001aaa8ab886af3ca78503617f
- https://git.kernel.org/stable/c/069ac51c37a6f07a51f7134d8c34289075786a35
- https://git.kernel.org/stable/c/51fa66024a5eabf270164f2dc82a48ffb35a12e9
- https://git.kernel.org/stable/c/812da2a08dc5cc75fb71e29083ea20904510ac7a
- https://git.kernel.org/stable/c/ea82139e6e3561100d38d14401d57c0ea93fc07e
- https://git.kernel.org/stable/c/f1d95df0f31048f1c59092648997686e3f7d9478
- https://git.kernel.org/stable/c/f515112e833791001aaa8ab886af3ca78503617f
Modified: 2024-12-11
CVE-2023-52574
In the Linux kernel, the following vulnerability has been resolved:
team: fix null-ptr-deref when team device type is changed
Get a null-ptr-deref bug as follows with reproducer [1].
BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
- https://git.kernel.org/stable/c/1779eb51b9cc628cee551f252701a85a2a50a457
- https://git.kernel.org/stable/c/2f0acb0736ecc3eb85dc80ad2790d634dcb10b58
- https://git.kernel.org/stable/c/492032760127251e5540a5716a70996bacf2a3fd
- https://git.kernel.org/stable/c/a7fb47b9711101d2405b0eb1276fb1f9b9b270c7
- https://git.kernel.org/stable/c/b44dd92e2afd89eb6e9d27616858e72a67bdc1a7
- https://git.kernel.org/stable/c/c5f6478686bb45f453031594ae19b6c9723a780d
- https://git.kernel.org/stable/c/cac50d9f5d876be32cb9aa21c74018468900284d
- https://git.kernel.org/stable/c/cd05eec2ee0cc396813a32ef675634e403748255
- https://git.kernel.org/stable/c/1779eb51b9cc628cee551f252701a85a2a50a457
- https://git.kernel.org/stable/c/2f0acb0736ecc3eb85dc80ad2790d634dcb10b58
- https://git.kernel.org/stable/c/492032760127251e5540a5716a70996bacf2a3fd
- https://git.kernel.org/stable/c/a7fb47b9711101d2405b0eb1276fb1f9b9b270c7
- https://git.kernel.org/stable/c/b44dd92e2afd89eb6e9d27616858e72a67bdc1a7
- https://git.kernel.org/stable/c/c5f6478686bb45f453031594ae19b6c9723a780d
- https://git.kernel.org/stable/c/cac50d9f5d876be32cb9aa21c74018468900284d
- https://git.kernel.org/stable/c/cd05eec2ee0cc396813a32ef675634e403748255
Modified: 2025-04-08
CVE-2023-52576
In the Linux kernel, the following vulnerability has been resolved: x86/mm, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer() The code calling ima_free_kexec_buffer() runs long after the memblock allocator has already been torn down, potentially resulting in a use after free in memblock_isolate_range(). With KASAN or KFENCE, this use after free will result in a BUG from the idle task, and a subsequent kernel panic. Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid that bug.
- https://git.kernel.org/stable/c/34cf99c250d5cd2530b93a57b0de31d3aaf8685b
- https://git.kernel.org/stable/c/d2dfbc0e3b7a04c2d941421a958dc31c897fb204
- https://git.kernel.org/stable/c/eef16bfdb212da60f5144689f2967fb25b051a2b
- https://git.kernel.org/stable/c/34cf99c250d5cd2530b93a57b0de31d3aaf8685b
- https://git.kernel.org/stable/c/d2dfbc0e3b7a04c2d941421a958dc31c897fb204
- https://git.kernel.org/stable/c/eef16bfdb212da60f5144689f2967fb25b051a2b
Modified: 2024-12-11
CVE-2023-52578
In the Linux kernel, the following vulnerability has been resolved: net: bridge: use DEV_STATS_INC() syzbot/KCSAN reported data-races in br_handle_frame_finish() [1] This function can run from multiple cpus without mutual exclusion. Adopt SMP safe DEV_STATS_INC() to update dev->stats fields. Handles updates to dev->stats.tx_dropped while we are at it. [1] BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK include/linux/netfilter.h:304 [inline] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline] nf_hook_bridge_pre net/bridge/br_input.c:272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net/core/dev.c:5521 [inline] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/core/dev.c:6594 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 run_ksoftirqd+0x17/0x20 kernel/softirq.c:921 smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK include/linux/netfilter.h:304 [inline] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline] nf_hook_bridge_pre net/bridge/br_input.c:272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net/core/dev.c:5521 [inline] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/core/dev.c:6594 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356 batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560 process_one_work kernel/workqueue.c:2630 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703 worker_thread+0x525/0x730 kernel/workqueue.c:2784 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 value changed: 0x00000000000d7190 -> 0x00000000000d7191 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0
- https://git.kernel.org/stable/c/04cc361f029c14dd067ad180525c7392334c9bfd
- https://git.kernel.org/stable/c/44bdb313da57322c9b3c108eb66981c6ec6509f4
- https://git.kernel.org/stable/c/89f9f20b1cbd36d99d5a248a4bf8d11d4fd049a2
- https://git.kernel.org/stable/c/8bc97117b51d68d5cea8f5351cca2d8c4153f394
- https://git.kernel.org/stable/c/ad8d39c7b437fcdab7208a6a56c093d222c008d5
- https://git.kernel.org/stable/c/d2346e6beb699909ca455d9d20c4e577ce900839
- https://git.kernel.org/stable/c/f2ef4cb4d418fa64fe73eb84d10cc5c0e52e00fa
- https://git.kernel.org/stable/c/04cc361f029c14dd067ad180525c7392334c9bfd
- https://git.kernel.org/stable/c/44bdb313da57322c9b3c108eb66981c6ec6509f4
- https://git.kernel.org/stable/c/89f9f20b1cbd36d99d5a248a4bf8d11d4fd049a2
- https://git.kernel.org/stable/c/8bc97117b51d68d5cea8f5351cca2d8c4153f394
- https://git.kernel.org/stable/c/ad8d39c7b437fcdab7208a6a56c093d222c008d5
- https://git.kernel.org/stable/c/d2346e6beb699909ca455d9d20c4e577ce900839
- https://git.kernel.org/stable/c/f2ef4cb4d418fa64fe73eb84d10cc5c0e52e00fa
Modified: 2025-01-16
CVE-2023-52580
In the Linux kernel, the following vulnerability has been resolved:
net/core: Fix ETH_P_1588 flow dissector
When a PTP ethernet raw frame with a size of more than 256 bytes followed
by a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation
is wrong. For example: hdr->message_length takes the wrong value (0xffff)
and it does not replicate real header length. In this case, 'nhoff' value
was overridden and the PTP header was badly dissected. This leads to a
kernel crash.
net/core: flow_dissector
net/core flow dissector nhoff = 0x0000000e
net/core flow dissector hdr->message_length = 0x0000ffff
net/core flow dissector nhoff = 0x0001000d (u16 overflow)
...
skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88
skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Using the size of the ptp_header struct will allow the corrected
calculation of the nhoff value.
net/core flow dissector nhoff = 0x0000000e
net/core flow dissector nhoff = 0x00000030 (sizeof ptp_header)
...
skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff
skb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
skb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Kernel trace:
[ 74.984279] ------------[ cut here ]------------
[ 74.989471] kernel BUG at include/linux/skbuff.h:2440!
[ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1
[ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023
[ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130
[ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9
[ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297
[ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003
[ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300
[ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800
[ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010
[ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800
[ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000
[ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0
[ 75.121980] PKRU: 55555554
[ 75.125035] Call Trace:
[ 75.127792]
- https://git.kernel.org/stable/c/488ea2a3e2666022f79abfdd7d12e8305fc27a40
- https://git.kernel.org/stable/c/48e105a2a1a10adc21c0ae717969f5e8e990ba48
- https://git.kernel.org/stable/c/75ad80ed88a182ab2ad5513e448cf07b403af5c3
- https://git.kernel.org/stable/c/f90a7b9586d72f907092078a9f394733ca502cc9
- https://git.kernel.org/stable/c/488ea2a3e2666022f79abfdd7d12e8305fc27a40
- https://git.kernel.org/stable/c/48e105a2a1a10adc21c0ae717969f5e8e990ba48
- https://git.kernel.org/stable/c/75ad80ed88a182ab2ad5513e448cf07b403af5c3
- https://git.kernel.org/stable/c/f90a7b9586d72f907092078a9f394733ca502cc9
Modified: 2025-01-16
CVE-2023-52582
In the Linux kernel, the following vulnerability has been resolved: netfs: Only call folio_start_fscache() one time for each folio If a network filesystem using netfs implements a clamp_length() function, it can set subrequest lengths smaller than a page size. When we loop through the folios in netfs_rreq_unlock_folios() to set any folios to be written back, we need to make sure we only call folio_start_fscache() once for each folio. Otherwise, this simple testcase: mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s echo 3 > /proc/sys/vm/drop_caches cat /mnt/nfs/file.bin > /dev/null will trigger an oops similar to the following: page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio)) ------------[ cut here ]------------ kernel BUG at include/linux/netfs.h:44! ... CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5 ... RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs] ... Call Trace: netfs_rreq_assess+0x497/0x660 [netfs] netfs_subreq_terminated+0x32b/0x610 [netfs] nfs_netfs_read_completion+0x14e/0x1a0 [nfs] nfs_read_completion+0x2f9/0x330 [nfs] rpc_free_task+0x72/0xa0 [sunrpc] rpc_async_release+0x46/0x70 [sunrpc] process_one_work+0x3bd/0x710 worker_thread+0x89/0x610 kthread+0x181/0x1c0 ret_from_fork+0x29/0x50
- https://git.kernel.org/stable/c/d9f5537479d4ec97ea92ff24e81a517d5772581a
- https://git.kernel.org/stable/c/df1c357f25d808e30b216188330e708e09e1a412
- https://git.kernel.org/stable/c/df9950d37df113db59495fa09d060754366a2b7c
- https://git.kernel.org/stable/c/d9f5537479d4ec97ea92ff24e81a517d5772581a
- https://git.kernel.org/stable/c/df1c357f25d808e30b216188330e708e09e1a412
- https://git.kernel.org/stable/c/df9950d37df113db59495fa09d060754366a2b7c
Modified: 2025-02-03
CVE-2023-52583
In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.
- https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160
- https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980
- https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67
- https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e
- https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca
- https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085
- https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3
- https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6
- https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160
- https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980
- https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67
- https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e
- https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca
- https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085
- https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3
- https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-14
CVE-2023-52584
In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller.
- https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8
- https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e
- https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9
- https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e
- https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8
- https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e
- https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9
- https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e
Modified: 2025-02-14
CVE-2023-52587
In the Linux kernel, the following vulnerability has been resolved:
IB/ipoib: Fix mcast list locking
Releasing the `priv->lock` while iterating the `priv->multicast_list` in
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
&priv->multicast_list, list) |
ipoib_mcast_join(dev, mcast) |
spin_unlock_irq(&priv->lock) |
| spin_lock_irqsave(&priv->lock, flags)
| list_for_each_entry_safe(mcast, tmcast,
| &priv->multicast_list, list)
| list_del(&mcast->list);
| list_add_tail(&mcast->list, &remove_list)
| spin_unlock_irqrestore(&priv->lock, flags)
spin_lock_irq(&priv->lock) |
| ipoib_mcast_remove_list(&remove_list)
(Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,
`priv->multicast_list` and we keep | remove_list, list)
spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done)
the other thread which is blocked |
and the list is still valid on |
it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
eventual sleeps.
Unfortunately we could not reproduce the lockup and confirm this fix but
based on the code review I think this fix should address such lockups.
crash> bc 31
PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"
--
[exception RIP: ipoib_mcast_join_task+0x1b1]
RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002
RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
work (&priv->mcast_task{,.work})
RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
&mcast->list
RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000
R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00
mcast
R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8
dev priv (&priv->lock) &priv->multicast_list (aka head)
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
---
- https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18
- https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825
- https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9
- https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a
- https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90
- https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89
- https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2
- https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34
- https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18
- https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825
- https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9
- https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a
- https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90
- https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89
- https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2
- https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-14
CVE-2023-52588
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to tag gcing flag on page during block migration It needs to add missing gcing flag on page during block migration, in order to garantee migrated data be persisted during checkpoint, otherwise out-of-order persistency between data and node may cause data corruption after SPOR. Similar issue was fixed by commit 2d1fe8a86bf5 ("f2fs: fix to tag gcing flag on page during file defragment").
- https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde
- https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b
- https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c
- https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136
- https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3
- https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde
- https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b
- https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c
- https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136
- https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3
Modified: 2025-02-14
CVE-2023-52589
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ disable race issue In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the case, as the interrupt handler can already be running, which would lead to the ISP being disabled while the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2) the interrupt handler code and the code that disables the streaming might do things that conflict. It is not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case) in the interrupt handler, leading to board lockup.
- https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7
- https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395
- https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe
- https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545
- https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7
- https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395
- https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe
- https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545
Modified: 2024-12-12
CVE-2023-52593
In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap() Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only.
- https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878
- https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03
- https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132
- https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d
- https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878
- https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03
- https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132
- https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d
Modified: 2024-12-12
CVE-2023-52594
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus() Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case. Found by a modified version of syzkaller. UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt
- https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234
- https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348
- https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1
- https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9
- https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1
- https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d
- https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225
- https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc
- https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234
- https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348
- https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1
- https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9
- https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1
- https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d
- https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225
- https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-12
CVE-2023-52595
In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: restart beacon queue when hardware reset When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().
- https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83
- https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c
- https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e
- https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957
- https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8
- https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48
- https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb
- https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83
- https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c
- https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e
- https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957
- https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8
- https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48
- https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-14
CVE-2023-52597
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix setting of fpc register kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space. In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu. Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values. This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c.
- https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3
- https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99
- https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7
- https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18
- https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1
- https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2
- https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55
- https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f
- https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3
- https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99
- https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7
- https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18
- https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1
- https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2
- https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55
- https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-14
CVE-2023-52598
In the Linux kernel, the following vulnerability has been resolved: s390/ptrace: handle setting of fpc register correctly If the content of the floating point control (fpc) register of a traced process is modified with the ptrace interface the new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when returning to user space. In result the tracer will incorrectly continue to run with the value that was supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs() before using test_fp_ctl().
- https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1
- https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25
- https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713
- https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8
- https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3
- https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a
- https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829
- https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4
- https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1
- https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25
- https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713
- https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8
- https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3
- https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a
- https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829
- https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52599
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diNewExt
[Syz report]
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
index -878706688 is out of range for type 'struct iagctl[128]'
CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
Call Trace:
- https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641
- https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402
- https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe
- https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b
- https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98
- https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017
- https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e
- https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41
- https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641
- https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402
- https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe
- https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b
- https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98
- https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017
- https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e
- https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-12
CVE-2023-52600
In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap.
- https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e
- https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce
- https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35
- https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61
- https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f
- https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e
- https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8
- https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3
- https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e
- https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce
- https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35
- https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61
- https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f
- https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e
- https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8
- https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-14
CVE-2023-52601
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in dbAdjTree Currently there is a bound check missing in the dbAdjTree while accessing the dmt_stree. To add the required check added the bool is_ctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/
- https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317
- https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c
- https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555
- https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e
- https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603
- https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b
- https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e
- https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73
- https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317
- https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c
- https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555
- https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e
- https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603
- https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b
- https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e
- https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-14
CVE-2023-52602
In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds Read in dtSearch Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error. Dave: Set return code to -EIO
- https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb
- https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6
- https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd
- https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7
- https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472
- https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612
- https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950
- https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f
- https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb
- https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6
- https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd
- https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7
- https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472
- https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612
- https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950
- https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-12
CVE-2023-52603
In the Linux kernel, the following vulnerability has been resolved:
UBSAN: array-index-out-of-bounds in dtSplitRoot
Syzkaller reported the following issue:
oop0: detected capacity change from 0 to 32768
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type 'struct dtslot [128]'
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
- https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16
- https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2
- https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8
- https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af
- https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60
- https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39
- https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f
- https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07
- https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16
- https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2
- https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8
- https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af
- https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60
- https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39
- https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f
- https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-12
CVE-2023-52604
In the Linux kernel, the following vulnerability has been resolved:
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
- https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03
- https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9
- https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd
- https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b
- https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68
- https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56
- https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b
- https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15
- https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03
- https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9
- https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd
- https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b
- https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68
- https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56
- https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b
- https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-14
CVE-2023-52606
In the Linux kernel, the following vulnerability has been resolved: powerpc/lib: Validate size for vector operations Some of the fp/vmx code in sstep.c assume a certain maximum size for the instructions being emulated. The size of those operations however is determined separately in analyse_instr(). Add a check to validate the assumption on the maximum size of the operations, so as to prevent any unintended kernel stack corruption.
- https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf
- https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c
- https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414
- https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd
- https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59
- https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e
- https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678
- https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b
- https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf
- https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c
- https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414
- https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd
- https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59
- https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e
- https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678
- https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-14
CVE-2023-52607
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer dereference in pgtable_cache_add kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
- https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532
- https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611
- https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b
- https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7
- https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1
- https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071
- https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e
- https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74
- https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532
- https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611
- https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b
- https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7
- https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1
- https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071
- https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e
- https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-25
CVE-2023-52608
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Check mailbox/SMT channel for consistency On reception of a completion interrupt the shared memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too. When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform. Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive. This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate such condition in the A2P ISR.
- https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda
- https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306
- https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d
- https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350
- https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2
- https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda
- https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306
- https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d
- https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350
- https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2
Modified: 2025-03-10
CVE-2023-52609
In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A. Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then. In order to fix this use mmput_async() that will schedule the work in the corresponding mm->async_put_work WQ instead of Task A.
- https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097
- https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3
- https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e
- https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01
- https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918
- https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608
- https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9
- https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5
- https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097
- https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3
- https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e
- https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01
- https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918
- https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608
- https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9
- https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-10
CVE-2023-52610
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix skb leak and crash on ooo frags
act_ct adds skb->users before defragmentation. If frags arrive in order,
the last frag's reference is reset in:
inet_frag_reasm_prepare
skb_morph
which is not straightforward.
However when frags arrive out of order, nobody unref the last frag, and
all frags are leaked. The situation is even worse, as initiating packet
capture can lead to a crash[0] when skb has been cloned and shared at the
same time.
Fix the issue by removing skb_get() before defragmentation. act_ct
returns TC_ACT_CONSUMED when defrag failed or in progress.
[0]:
[ 843.804823] ------------[ cut here ]------------
[ 843.809659] kernel BUG at net/core/skbuff.c:2091!
[ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89
[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 843.894229] PKRU: 55555554
[ 843.898539] Call Trace:
[ 843.902772]
- https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4
- https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4
- https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6
- https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97
- https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441
- https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4
- https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4
- https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6
- https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97
- https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441
Modified: 2025-02-27
CVE-2023-52612
In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem.
- https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe
- https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e
- https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5
- https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883
- https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131
- https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759
- https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625
- https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76
- https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe
- https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e
- https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5
- https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883
- https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131
- https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759
- https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625
- https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-12
CVE-2023-52614
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix buffer overflow in trans_stat_show Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG in the case where we don't have enough space to write the full transition table. Also document in the ABI that this function can return -EFBIG error.
- https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c
- https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4
- https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f
- https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c
- https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8
- https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87
- https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c
- https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4
- https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f
- https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c
- https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8
- https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2023-52615
In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user.
- https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0
- https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48
- https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029
- https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922
- https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e
- https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c
- https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990
- https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d
- https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0
- https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48
- https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029
- https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922
- https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e
- https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c
- https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990
- https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-08
CVE-2023-52617
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com
- https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3
- https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a
- https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c
- https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355
- https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66
- https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693
- https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8
- https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3
- https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a
- https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c
- https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355
- https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66
- https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693
- https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2023-52618
In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present).
- https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827
- https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7
- https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41
- https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339
- https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f
- https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7
- https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827
- https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7
- https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41
- https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339
- https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f
- https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-10
CVE-2023-52619
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug.
- https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee
- https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c
- https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a
- https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4
- https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10
- https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542
- https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c
- https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb
- https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee
- https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c
- https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a
- https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4
- https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10
- https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542
- https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c
- https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-25
CVE-2023-52621
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
These three bpf_map_{lookup,update,delete}_elem() helpers are also
available for sleepable bpf program, so add the corresponding lock
assertion for sleepable bpf program, otherwise the following warning
will be reported when a sleepable bpf program manipulates bpf map under
interpreter mode (aka bpf_jit_enable=0):
WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......
CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
RIP: 0010:bpf_map_lookup_elem+0x54/0x60
......
Call Trace:
- https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d
- https://git.kernel.org/stable/c/3516f93cc63d956e1b290ae4b7bf2586074535a0
- https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d
- https://git.kernel.org/stable/c/82f2df94dac1aa9b879e74d1f82ba1b631bdc612
- https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304
- https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3
- https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d
- https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d
- https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304
- https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-03-17
CVE-2023-52622
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid online resizing failures due to oversized flex bg
When we online resize an ext4 filesystem with a oversized flexbg_size,
mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
mount $dev $dir
resize2fs $dev 16G
the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
- https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0
- https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954
- https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c
- https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07
- https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644
- https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8
- https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90
- https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2
- https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0
- https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954
- https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c
- https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07
- https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644
- https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8
- https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90
- https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-31
CVE-2023-52623
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix a suspicious RCU usage warning
I received the following warning while running cthon against an ontap
server running pNFS:
[ 57.202521] =============================
[ 57.202522] WARNING: suspicious RCU usage
[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
[ 57.202525] -----------------------------
[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
[ 57.202527]
other info that might help us debug this:
[ 57.202528]
rcu_scheduler_active = 2, debug_locks = 1
[ 57.202529] no locks held by test5/3567.
[ 57.202530]
stack backtrace:
[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
[ 57.202536] Call Trace:
[ 57.202537]
- https://git.kernel.org/stable/c/31b62908693c90d4d07db597e685d9f25a120073
- https://git.kernel.org/stable/c/69c7eeb4f622c2a28da965f970f982db171f3dc6
- https://git.kernel.org/stable/c/7a96d85bf196c170dcf1b47a82e9bb97cca69aa6
- https://git.kernel.org/stable/c/8f860c8407470baff2beb9982ad6b172c94f1d0a
- https://git.kernel.org/stable/c/c430e6bb43955c6bf573665fcebf31694925b9f7
- https://git.kernel.org/stable/c/e8ca3e73301e23e8c0ac0ce2e6bac4545cd776e0
- https://git.kernel.org/stable/c/f8cf4dabbdcb8bef85335b0ed7ad5b25fd82ff56
- https://git.kernel.org/stable/c/fece80a2a6718ed58487ce397285bb1b83a3e54e
- https://git.kernel.org/stable/c/31b62908693c90d4d07db597e685d9f25a120073
- https://git.kernel.org/stable/c/69c7eeb4f622c2a28da965f970f982db171f3dc6
- https://git.kernel.org/stable/c/7a96d85bf196c170dcf1b47a82e9bb97cca69aa6
- https://git.kernel.org/stable/c/8f860c8407470baff2beb9982ad6b172c94f1d0a
- https://git.kernel.org/stable/c/c430e6bb43955c6bf573665fcebf31694925b9f7
- https://git.kernel.org/stable/c/e8ca3e73301e23e8c0ac0ce2e6bac4545cd776e0
- https://git.kernel.org/stable/c/f8cf4dabbdcb8bef85335b0ed7ad5b25fd82ff56
- https://git.kernel.org/stable/c/fece80a2a6718ed58487ce397285bb1b83a3e54e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-04-29
CVE-2023-52627
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7091r: Allow users to configure device events AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set. Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation. Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added.
- https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f
- https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4
- https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5
- https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091
- https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6
- https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2
- https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f
- https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4
- https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5
- https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091
- https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6
- https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-11-04
CVE-2023-52628
In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: exthdr: fix 4-byte stack OOB write If priv->len is a multiple of 4, then dst[len / 4] can write past the destination array which leads to stack corruption. This construct is necessary to clean the remainder of the register in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does. The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added. Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961).
- https://git.kernel.org/stable/c/1ad7b189cc1411048434e8595ffcbe7873b71082
- https://git.kernel.org/stable/c/28a97c43c9e32f437ebb8d6126f9bb7f3ca9521a
- https://git.kernel.org/stable/c/a7d86a77c33ba1c357a7504341172cc1507f0698
- https://git.kernel.org/stable/c/c8f292322ff16b9a2272a67de396c09a50e09dce
- https://git.kernel.org/stable/c/cf39c4f77a773a547ac2bcf30ecdd303bb0c80cb
- https://git.kernel.org/stable/c/d9ebfc0f21377690837ebbd119e679243e0099cc
- https://git.kernel.org/stable/c/fd94d9dadee58e09b49075240fe83423eb1dcd36
- https://git.kernel.org/stable/c/1ad7b189cc1411048434e8595ffcbe7873b71082
- https://git.kernel.org/stable/c/28a97c43c9e32f437ebb8d6126f9bb7f3ca9521a
- https://git.kernel.org/stable/c/a7d86a77c33ba1c357a7504341172cc1507f0698
- https://git.kernel.org/stable/c/c8f292322ff16b9a2272a67de396c09a50e09dce
- https://git.kernel.org/stable/c/cf39c4f77a773a547ac2bcf30ecdd303bb0c80cb
- https://git.kernel.org/stable/c/d9ebfc0f21377690837ebbd119e679243e0099cc
- https://git.kernel.org/stable/c/fd94d9dadee58e09b49075240fe83423eb1dcd36
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2023-52632
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu);
- https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4
- https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340
- https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c
- https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94
- https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4
- https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340
- https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c
- https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94
Modified: 2025-03-17
CVE-2023-52633
In the Linux kernel, the following vulnerability has been resolved: um: time-travel: fix time corruption In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding. Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled.
- https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab
- https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025
- https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c
- https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283
- https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c
- https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab
- https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025
- https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c
- https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283
- https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c
Modified: 2025-03-17
CVE-2023-52635
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
There is a chance if a frequent switch of the governor
done in a loop result in timer list corruption where
timer cancel being done from two place one from
cancel_delayed_work_sync() and followed by expire_timers()
can be seen from the traces[1].
while true
do
echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
done
It looks to be issue with devfreq driver where
device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either
being queued or running or being cancelled.
Let's use polling flag and devfreq lock to synchronize the
queueing the timer instance twice and work data being
corrupted.
[1]
...
..
- https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675
- https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9
- https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9
- https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475
- https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22
- https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6
- https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675
- https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9
- https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9
- https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475
- https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22
- https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
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: 2025-09-18
CVE-2023-52654
In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: disable sending io_uring over sockets File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary.
- https://git.kernel.org/stable/c/18824f592aad4124d79751bbc1500ea86ac3ff29
- https://git.kernel.org/stable/c/3fe1ea5f921bf5b71cbfdc4469fb96c05936610e
- https://git.kernel.org/stable/c/5a33d385eb36991a91e3dddb189d8679e2aac2be
- https://git.kernel.org/stable/c/705318a99a138c29a512a72c3e0043b3cd7f55f4
- https://git.kernel.org/stable/c/bcedd497b3b4a0be56f3adf7c7542720eced0792
- https://git.kernel.org/stable/c/f2f57f51b53be153a522300454ddb3887722fb2c
- https://git.kernel.org/stable/c/18824f592aad4124d79751bbc1500ea86ac3ff29
- https://git.kernel.org/stable/c/3fe1ea5f921bf5b71cbfdc4469fb96c05936610e
- https://git.kernel.org/stable/c/5a33d385eb36991a91e3dddb189d8679e2aac2be
- https://git.kernel.org/stable/c/705318a99a138c29a512a72c3e0043b3cd7f55f4
- https://git.kernel.org/stable/c/bcedd497b3b4a0be56f3adf7c7542720eced0792
- https://git.kernel.org/stable/c/f2f57f51b53be153a522300454ddb3887722fb2c
Modified: 2025-09-18
CVE-2023-52655
In the Linux kernel, the following vulnerability has been resolved: usb: aqc111: check packet for fixup for true limit If a device sends a packet that is inbetween 0 and sizeof(u64) the value passed to skb_trim() as length will wrap around ending up as some very large value. The driver will then proceed to parse the header located at that position, which will either oops or process some random value. The fix is to check against sizeof(u64) rather than 0, which the driver currently does. The issue exists since the introduction of the driver.
- https://git.kernel.org/stable/c/2ebf775f0541ae0d474836fa0cf3220e502f8e3e
- https://git.kernel.org/stable/c/46412b2fb1f9cc895d6d4036bf24f640b5d86dab
- https://git.kernel.org/stable/c/82c386d73689a45d5ee8c1290827bce64056dddd
- https://git.kernel.org/stable/c/84f2e5b3e70f08fce3cb1ff73414631c5e490204
- https://git.kernel.org/stable/c/ccab434e674ca95d483788b1895a70c21b7f016a
- https://git.kernel.org/stable/c/d69581c17608d81824dd497d9a54b6a5b6139975
- https://git.kernel.org/stable/c/2ebf775f0541ae0d474836fa0cf3220e502f8e3e
- https://git.kernel.org/stable/c/46412b2fb1f9cc895d6d4036bf24f640b5d86dab
- https://git.kernel.org/stable/c/82c386d73689a45d5ee8c1290827bce64056dddd
- https://git.kernel.org/stable/c/84f2e5b3e70f08fce3cb1ff73414631c5e490204
- https://git.kernel.org/stable/c/ccab434e674ca95d483788b1895a70c21b7f016a
- https://git.kernel.org/stable/c/d69581c17608d81824dd497d9a54b6a5b6139975
Modified: 2025-01-07
CVE-2023-52664
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.
- https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d
- https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928
- https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf
- https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d
- https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d
- https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928
- https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf
- https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d
Modified: 2025-01-10
CVE-2023-52667
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a potential double-free in fs_any_create_groups When kcalloc() for ft->g succeeds but kvzalloc() for in fails, fs_any_create_groups() will free ft->g. However, its caller fs_any_create_table() will free ft->g again through calling mlx5e_destroy_flow_table(), which will lead to a double-free. Fix this by setting ft->g to NULL in fs_any_create_groups().
- https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8
- https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779
- https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1
- https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e
- https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe
- https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8
- https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779
- https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1
- https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e
- https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe
Modified: 2025-12-23
CVE-2023-52669
In the Linux kernel, the following vulnerability has been resolved: crypto: s390/aes - Fix buffer overread in CTR mode When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.
- https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a98423703285
- https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79
- https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
- https://git.kernel.org/stable/c/d68ac38895e84446848b7647ab9458d54cacba3e
- https://git.kernel.org/stable/c/dbc9a791a70ea47be9f2acf251700fe254a2ab23
- https://git.kernel.org/stable/c/e78f1a43e72daf77705ad5b9946de66fc708b874
- https://git.kernel.org/stable/c/a7f580cdb42ec3d53bbb7c4e4335a98423703285
- https://git.kernel.org/stable/c/cd51e26a3b89706beec64f2d8296cfb1c34e0c79
- https://git.kernel.org/stable/c/d07f951903fa9922c375b8ab1ce81b18a0034e3b
- https://git.kernel.org/stable/c/d68ac38895e84446848b7647ab9458d54cacba3e
- https://git.kernel.org/stable/c/dbc9a791a70ea47be9f2acf251700fe254a2ab23
- https://git.kernel.org/stable/c/e78f1a43e72daf77705ad5b9946de66fc708b874
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-12-23
CVE-2023-52670
In the Linux kernel, the following vulnerability has been resolved: rpmsg: virtio: Free driver_override when rpmsg_remove() Free driver_override when rpmsg_remove(), otherwise the following memory leak will occur: unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] really_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] device_initial_probe+0x14/0x20 [<000000003c999637>] bus_probe_device+0xa0/0xac
- https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08
- https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6
- https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
- https://git.kernel.org/stable/c/69ca89d80f2c8a1f5af429b955637beea7eead30
- https://git.kernel.org/stable/c/9a416d624e5fb7246ea97c11fbfea7e0e27abf43
- https://git.kernel.org/stable/c/d5362c37e1f8a40096452fc201c30e705750e687
- https://git.kernel.org/stable/c/dd50fe18c234bd5ff22f658f4d414e8fa8cd6a5d
- https://git.kernel.org/stable/c/f4bb1d5daf77b1a95a43277268adf0d1430c2346
- https://git.kernel.org/stable/c/229ce47cbfdc7d3a9415eb676abbfb77d676cb08
- https://git.kernel.org/stable/c/2d27a7b19cb354c6d04bcdc9239e261ff29858d6
- https://git.kernel.org/stable/c/4e6cef3fae5c164968118a13f3fe293700adc81a
- https://git.kernel.org/stable/c/69ca89d80f2c8a1f5af429b955637beea7eead30
- https://git.kernel.org/stable/c/9a416d624e5fb7246ea97c11fbfea7e0e27abf43
- https://git.kernel.org/stable/c/d5362c37e1f8a40096452fc201c30e705750e687
- https://git.kernel.org/stable/c/dd50fe18c234bd5ff22f658f4d414e8fa8cd6a5d
- https://git.kernel.org/stable/c/f4bb1d5daf77b1a95a43277268adf0d1430c2346
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2023-52672
In the Linux kernel, the following vulnerability has been resolved:
pipe: wakeup wr_wait after setting max_usage
Commit c73be61cede5 ("pipe: Add general notification queue support") a
regression was introduced that would lock up resized pipes under certain
conditions. See the reproducer in [1].
The commit resizing the pipe ring size was moved to a different
function, doing that moved the wakeup for pipe->wr_wait before actually
raising pipe->max_usage. If a pipe was full before the resize occured it
would result in the wakeup never actually triggering pipe_write.
Set @max_usage and @nr_accounted before waking writers if this isn't a
watch queue.
[Christian Brauner
- https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8
- https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9
- https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
- https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55
- https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f
- https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a
- https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8
- https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9
- https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24
- https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55
- https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f
- https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2023-52674
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put() Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside scarlett2_mixer_values[].
- https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572
- https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7
- https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2
- https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810
- https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b
- https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572
- https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7
- https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2
- https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810
- https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b
Modified: 2025-03-04
CVE-2023-52675
In the Linux kernel, the following vulnerability has been resolved: powerpc/imc-pmu: Add a null pointer check in update_events_in_group() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
- https://git.kernel.org/stable/c/024352f7928b28f53609660663329d8c0f4ad032
- https://git.kernel.org/stable/c/0a233867a39078ebb0f575e2948593bbff5826b3
- https://git.kernel.org/stable/c/1e80aa25d186a7aa212df5acd8c75f55ac8dae34
- https://git.kernel.org/stable/c/5a669f3511d273c8c1ab1c1d268fbcdf53fc7a05
- https://git.kernel.org/stable/c/75fc599bcdcb1de093c9ced2e3cccc832f3787f3
- https://git.kernel.org/stable/c/a2da3f9b1a1019c887ee1d164475a8fcdb0a3fec
- https://git.kernel.org/stable/c/c7d828e12b326ea50fb80c369d7aa87519ed14c6
- https://git.kernel.org/stable/c/f105c263009839d80fad6998324a4e1b3511cba0
- https://git.kernel.org/stable/c/024352f7928b28f53609660663329d8c0f4ad032
- https://git.kernel.org/stable/c/0a233867a39078ebb0f575e2948593bbff5826b3
- https://git.kernel.org/stable/c/1e80aa25d186a7aa212df5acd8c75f55ac8dae34
- https://git.kernel.org/stable/c/5a669f3511d273c8c1ab1c1d268fbcdf53fc7a05
- https://git.kernel.org/stable/c/75fc599bcdcb1de093c9ced2e3cccc832f3787f3
- https://git.kernel.org/stable/c/a2da3f9b1a1019c887ee1d164475a8fcdb0a3fec
- https://git.kernel.org/stable/c/c7d828e12b326ea50fb80c369d7aa87519ed14c6
- https://git.kernel.org/stable/c/f105c263009839d80fad6998324a4e1b3511cba0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-09-25
CVE-2023-52677
In the Linux kernel, the following vulnerability has been resolved: riscv: Check if the code to patch lies in the exit section Otherwise we fall through to vmalloc_to_page() which panics since the address does not lie in the vmalloc region.
- https://git.kernel.org/stable/c/1d7a03052846f34d624d0ab41a879adf5e85c85f
- https://git.kernel.org/stable/c/420370f3ae3d3b883813fd3051a38805160b2b9f
- https://git.kernel.org/stable/c/890cfe5337e0aaf03ece1429db04d23c88da72e7
- https://git.kernel.org/stable/c/8db56df4a954b774bdc68917046a685a9fa2e4bc
- https://git.kernel.org/stable/c/938f70d14618ec72e10d6fcf8a546134136d7c13
- https://git.kernel.org/stable/c/1d7a03052846f34d624d0ab41a879adf5e85c85f
- https://git.kernel.org/stable/c/420370f3ae3d3b883813fd3051a38805160b2b9f
- https://git.kernel.org/stable/c/890cfe5337e0aaf03ece1429db04d23c88da72e7
- https://git.kernel.org/stable/c/8db56df4a954b774bdc68917046a685a9fa2e4bc
- https://git.kernel.org/stable/c/938f70d14618ec72e10d6fcf8a546134136d7c13
Modified: 2025-09-25
CVE-2023-52678
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c Before using list_first_entry, make sure to check that list is not empty, if list is empty return -ENODATA. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL?
- https://git.kernel.org/stable/c/4525525cb7161d08f95d0e47025323dd10214313
- https://git.kernel.org/stable/c/499839eca34ad62d43025ec0b46b80e77065f6d8
- https://git.kernel.org/stable/c/4ac4e023ed7ab1c7c67d2d12b7b6198fcd099e5c
- https://git.kernel.org/stable/c/5024cce888e11e5688f77df81db9e14828495d64
- https://git.kernel.org/stable/c/4525525cb7161d08f95d0e47025323dd10214313
- https://git.kernel.org/stable/c/499839eca34ad62d43025ec0b46b80e77065f6d8
- https://git.kernel.org/stable/c/4ac4e023ed7ab1c7c67d2d12b7b6198fcd099e5c
- https://git.kernel.org/stable/c/5024cce888e11e5688f77df81db9e14828495d64
Modified: 2025-01-10
CVE-2023-52679
In the Linux kernel, the following vulnerability has been resolved: of: Fix double free in of_parse_phandle_with_args_map In of_parse_phandle_with_args_map() the inner loop that iterates through the map entries calls of_node_put(new) to free the reference acquired by the previous iteration of the inner loop. This assumes that the value of "new" is NULL on the first iteration of the inner loop. Make sure that this is true in all iterations of the outer loop by setting "new" to NULL after its value is assigned to "cur". Extend the unittest to detect the double free and add an additional test case that actually triggers this path.
- https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db
- https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21
- https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b
- https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2
- https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8
- https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd
- https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7
- https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea
- https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db
- https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21
- https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b
- https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2
- https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8
- https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd
- https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7
- https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-25
CVE-2023-52680
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add missing error checks to *_ctl_get() The *_ctl_get() functions which call scarlett2_update_*() were not checking the return value. Fix to check the return value and pass to the caller.
- https://git.kernel.org/stable/c/3a09488f4f67f7ade59b8ac62a6c7fb29439cf51
- https://git.kernel.org/stable/c/50603a67daef161c78c814580d57f7f0be57167e
- https://git.kernel.org/stable/c/773e38f73461ef2134a0d33a08f1668edde9b7c3
- https://git.kernel.org/stable/c/821fbaeaaae23d483d3df799fe91ec8045973ec3
- https://git.kernel.org/stable/c/cda7762bea857e6951315a2f7d0632ea1850ed43
- https://git.kernel.org/stable/c/3a09488f4f67f7ade59b8ac62a6c7fb29439cf51
- https://git.kernel.org/stable/c/50603a67daef161c78c814580d57f7f0be57167e
- https://git.kernel.org/stable/c/773e38f73461ef2134a0d33a08f1668edde9b7c3
- https://git.kernel.org/stable/c/821fbaeaaae23d483d3df799fe91ec8045973ec3
- https://git.kernel.org/stable/c/cda7762bea857e6951315a2f7d0632ea1850ed43
Modified: 2025-09-19
CVE-2023-52682
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait on block writeback for post_read case If inode is compressed, but not encrypted, it missed to call f2fs_wait_on_block_writeback() to wait for GCed page writeback in IPU write path. Thread A GC-Thread - f2fs_gc - do_garbage_collect - gc_data_segment - move_data_block - f2fs_submit_page_write migrate normal cluster's block via meta_inode's page cache - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_submit_page_bio IRQ - f2fs_read_end_io IRQ old data overrides new data due to out-of-order GC and common IO. - f2fs_read_end_io
- https://git.kernel.org/stable/c/4535be48780431753505e74e1b1ad4836a189bc2
- https://git.kernel.org/stable/c/55fdc1c24a1d6229fe0ecf31335fb9a2eceaaa00
- https://git.kernel.org/stable/c/9bfd5ea71521d0e522ba581c6ccc5db93759c0c3
- https://git.kernel.org/stable/c/f904c156d8011d8291ffd5b6b398f3747e294986
- https://git.kernel.org/stable/c/4535be48780431753505e74e1b1ad4836a189bc2
- https://git.kernel.org/stable/c/55fdc1c24a1d6229fe0ecf31335fb9a2eceaaa00
- https://git.kernel.org/stable/c/9bfd5ea71521d0e522ba581c6ccc5db93759c0c3
- https://git.kernel.org/stable/c/f904c156d8011d8291ffd5b6b398f3747e294986
Modified: 2025-12-17
CVE-2023-52683
In the Linux kernel, the following vulnerability has been resolved: ACPI: LPIT: Avoid u32 multiplication overflow In lpit_update_residency() there is a possibility of overflow in multiplication, if tsc_khz is large enough (> UINT_MAX/1000). Change multiplication to mul_u32_u32(). Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/56d2eeda87995245300836ee4dbd13b002311782
- https://git.kernel.org/stable/c/647d1d50c31e60ef9ccb9756a8fdf863329f7aee
- https://git.kernel.org/stable/c/6c38e791bde07d6ca2a0a619ff9b6837e0d5f9ad
- https://git.kernel.org/stable/c/72222dfd76a79d9666ab3117fcdd44ca8cd0c4de
- https://git.kernel.org/stable/c/b7aab9d906e2e252a7783f872406033ec49b6dae
- https://git.kernel.org/stable/c/c1814a4ffd016ce5392c6767d22ef3aa2f0d4bd1
- https://git.kernel.org/stable/c/d1ac288b2742aa4af746c5613bac71760fadd1c4
- https://git.kernel.org/stable/c/f39c3d578c7d09a18ceaf56750fc7f20b02ada63
- https://git.kernel.org/stable/c/56d2eeda87995245300836ee4dbd13b002311782
- https://git.kernel.org/stable/c/647d1d50c31e60ef9ccb9756a8fdf863329f7aee
- https://git.kernel.org/stable/c/6c38e791bde07d6ca2a0a619ff9b6837e0d5f9ad
- https://git.kernel.org/stable/c/72222dfd76a79d9666ab3117fcdd44ca8cd0c4de
- https://git.kernel.org/stable/c/b7aab9d906e2e252a7783f872406033ec49b6dae
- https://git.kernel.org/stable/c/c1814a4ffd016ce5392c6767d22ef3aa2f0d4bd1
- https://git.kernel.org/stable/c/d1ac288b2742aa4af746c5613bac71760fadd1c4
- https://git.kernel.org/stable/c/f39c3d578c7d09a18ceaf56750fc7f20b02ada63
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-04
CVE-2023-52686
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_event_init() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
- https://git.kernel.org/stable/c/8422d179cf46889c15ceff9ede48c5bfa4e7f0b4
- https://git.kernel.org/stable/c/8649829a1dd25199bbf557b2621cedb4bf9b3050
- https://git.kernel.org/stable/c/9a523e1da6d88c2034f946adfa4f74b236c95ca9
- https://git.kernel.org/stable/c/a14c55eb461d630b836f80591d8caf1f74e62877
- https://git.kernel.org/stable/c/c0b111ea786ddcc8be0682612830796ece9436c7
- https://git.kernel.org/stable/c/e08c2e275fa1874de945b87093f925997722ee42
- https://git.kernel.org/stable/c/e6ad05e3ae9c84c5a71d7bb2d44dc845ae7990cf
- https://git.kernel.org/stable/c/e93d7cf4c1ddbcd846739e7ad849f955a4f18031
- https://git.kernel.org/stable/c/8422d179cf46889c15ceff9ede48c5bfa4e7f0b4
- https://git.kernel.org/stable/c/8649829a1dd25199bbf557b2621cedb4bf9b3050
- https://git.kernel.org/stable/c/9a523e1da6d88c2034f946adfa4f74b236c95ca9
- https://git.kernel.org/stable/c/a14c55eb461d630b836f80591d8caf1f74e62877
- https://git.kernel.org/stable/c/c0b111ea786ddcc8be0682612830796ece9436c7
- https://git.kernel.org/stable/c/e08c2e275fa1874de945b87093f925997722ee42
- https://git.kernel.org/stable/c/e6ad05e3ae9c84c5a71d7bb2d44dc845ae7990cf
- https://git.kernel.org/stable/c/e93d7cf4c1ddbcd846739e7ad849f955a4f18031
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-09-25
CVE-2023-52687
In the Linux kernel, the following vulnerability has been resolved: crypto: safexcel - Add error handling for dma_map_sg() calls Macro dma_map_sg() may return 0 on error. This patch enables checks in case of the macro failure and ensures unmapping of previously mapped buffers with dma_unmap_sg(). Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
- https://git.kernel.org/stable/c/4c0ac81a172a69a7733290915276672787e904ec
- https://git.kernel.org/stable/c/8084b788c2fb1260f7d44c032d5124680b20d2b2
- https://git.kernel.org/stable/c/87e02063d07708cac5bfe9fd3a6a242898758ac8
- https://git.kernel.org/stable/c/fc0b785802b856566df3ac943e38a072557001c4
- https://git.kernel.org/stable/c/4c0ac81a172a69a7733290915276672787e904ec
- https://git.kernel.org/stable/c/8084b788c2fb1260f7d44c032d5124680b20d2b2
- https://git.kernel.org/stable/c/87e02063d07708cac5bfe9fd3a6a242898758ac8
- https://git.kernel.org/stable/c/fc0b785802b856566df3ac943e38a072557001c4
Modified: 2025-03-04
CVE-2023-52690
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check to scom_debug_init_one() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Add a null pointer check, and release 'ent' to avoid memory leaks.
- https://git.kernel.org/stable/c/1eefa93faf69188540b08b024794fa90b1d82e8b
- https://git.kernel.org/stable/c/2a82c4439b903639e0a1f21990cd399fb0a49c19
- https://git.kernel.org/stable/c/9a260f2dd827bbc82cc60eb4f4d8c22707d80742
- https://git.kernel.org/stable/c/a9c05cbb6644a2103c75b6906e9dafb9981ebd13
- https://git.kernel.org/stable/c/dd8422ff271c22058560832fc3006324ded895a9
- https://git.kernel.org/stable/c/ed8d023cfa97b559db58c0e1afdd2eec7a83d8f2
- https://git.kernel.org/stable/c/f84c1446daa552e9699da8d1f8375eac0f65edc7
- https://git.kernel.org/stable/c/1eefa93faf69188540b08b024794fa90b1d82e8b
- https://git.kernel.org/stable/c/2a82c4439b903639e0a1f21990cd399fb0a49c19
- https://git.kernel.org/stable/c/9a260f2dd827bbc82cc60eb4f4d8c22707d80742
- https://git.kernel.org/stable/c/a9c05cbb6644a2103c75b6906e9dafb9981ebd13
- https://git.kernel.org/stable/c/dd8422ff271c22058560832fc3006324ded895a9
- https://git.kernel.org/stable/c/ed8d023cfa97b559db58c0e1afdd2eec7a83d8f2
- https://git.kernel.org/stable/c/f84c1446daa552e9699da8d1f8375eac0f65edc7
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-01-10
CVE-2023-52691
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix a double-free in si_dpm_init When the allocation of adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails, amdgpu_free_extended_power_table is called to free some fields of adev. However, when the control flow returns to si_dpm_sw_init, it goes to label dpm_failed and calls si_dpm_fini, which calls amdgpu_free_extended_power_table again and free those fields again. Thus a double-free is triggered.
- https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706
- https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334
- https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30
- https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4
- https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0
- https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a
- https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2
- https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9
- https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706
- https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334
- https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30
- https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4
- https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0
- https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a
- https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2
- https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-25
CVE-2023-52692
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config() scarlett2_usb_set_config() calls scarlett2_usb_get() but was not checking the result. Return the error if it fails rather than continuing with an invalid value.
- https://git.kernel.org/stable/c/145c5aa51486171025ab47f35cff34bff8d0cea3
- https://git.kernel.org/stable/c/51d5697e1c0380d482c3eab002bfc8d0be177e99
- https://git.kernel.org/stable/c/996fde492ad9b9563ee483b363af40d7696a8467
- https://git.kernel.org/stable/c/be96acd3eaa790d10a5b33e65267f52d02f6ad88
- https://git.kernel.org/stable/c/ca459dfa7d4ed9098fcf13e410963be6ae9b6bf3
- https://git.kernel.org/stable/c/145c5aa51486171025ab47f35cff34bff8d0cea3
- https://git.kernel.org/stable/c/51d5697e1c0380d482c3eab002bfc8d0be177e99
- https://git.kernel.org/stable/c/996fde492ad9b9563ee483b363af40d7696a8467
- https://git.kernel.org/stable/c/be96acd3eaa790d10a5b33e65267f52d02f6ad88
- https://git.kernel.org/stable/c/ca459dfa7d4ed9098fcf13e410963be6ae9b6bf3
Modified: 2025-12-17
CVE-2023-52693
In the Linux kernel, the following vulnerability has been resolved: ACPI: video: check for error while searching for backlight device parent If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device. Check acpi_get_parent() result and set parent device only in case of success. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3
- https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95
- https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c
- https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af
- https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8
- https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852df0f15f
- https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f
- https://git.kernel.org/stable/c/ccd45faf4973746c4f30ea41eec864e5cf191099
- https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3
- https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95
- https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c
- https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af
- https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8
- https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852df0f15f
- https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f
- https://git.kernel.org/stable/c/ccd45faf4973746c4f30ea41eec864e5cf191099
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2023-52694
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function With tpd12s015_remove() marked with __exit this function is discarded when the driver is compiled as a built-in. The result is that when the driver unbinds there is no cleanup done which results in resource leakage or worse.
- https://git.kernel.org/stable/c/08ccff6ece35f08e8107e975903c370d849089e5
- https://git.kernel.org/stable/c/53926e2a39629702f7f809d614b3ca89c2478205
- https://git.kernel.org/stable/c/81f1bd85960b7a089a91e679ff7cd2524390bbf1
- https://git.kernel.org/stable/c/a8657406e12aa10412134622c58977ac657f16d2
- https://git.kernel.org/stable/c/ce3e112e7ae854249d8755906acc5f27e1542114
- https://git.kernel.org/stable/c/e00ec5901954d85b39b5f10f94e60ab9af463eb1
- https://git.kernel.org/stable/c/08ccff6ece35f08e8107e975903c370d849089e5
- https://git.kernel.org/stable/c/53926e2a39629702f7f809d614b3ca89c2478205
- https://git.kernel.org/stable/c/81f1bd85960b7a089a91e679ff7cd2524390bbf1
- https://git.kernel.org/stable/c/a8657406e12aa10412134622c58977ac657f16d2
- https://git.kernel.org/stable/c/ce3e112e7ae854249d8755906acc5f27e1542114
- https://git.kernel.org/stable/c/e00ec5901954d85b39b5f10f94e60ab9af463eb1
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-04-07
CVE-2023-52696
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_powercap_init() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.
- https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664
- https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219
- https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc
- https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1
- https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab
- https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d
- https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0
- https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664
- https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219
- https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc
- https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1
- https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab
- https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d
- https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2025-01-07
CVE-2023-52698
In the Linux kernel, the following vulnerability has been resolved: calipso: fix memory leak in netlbl_calipso_add_pass() If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free(). BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller [PM: merged via the LSM tree at Jakub Kicinski request]
- https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149
- https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53
- https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031
- https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01
- https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da
- https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded
- https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99
- https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c
- https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149
- https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53
- https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031
- https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01
- https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da
- https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded
- https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99
- https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-09-19
CVE-2023-52700
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix kernel warning when sending SYN message
When sending a SYN message, this kernel stack trace is observed:
...
[ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550
...
[ 13.398494] Call Trace:
[ 13.398630]
Modified: 2025-09-25
CVE-2023-52701
In the Linux kernel, the following vulnerability has been resolved: net: use a bounce buffer for copying skb->mark syzbot found arm64 builds would crash in sock_recv_mark() when CONFIG_HARDENED_USERCOPY=y x86 and powerpc are not detecting the issue because they define user_access_begin. This will be handled in a different patch, because a check_object_size() is missing. Only data from skb->cb[] can be copied directly to/from user space, as explained in commit 79a8a642bf05 ("net: Whitelist the skbuff_head_cache "cb" field") syzbot report was: usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_head_cache' (offset 168, size 4)! ------------[ cut here ]------------ kernel BUG at mm/usercopy.c:102 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 4410 Comm: syz-executor533 Not tainted 6.2.0-rc7-syzkaller-17907-g2d3827b3f393 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:90 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:90 sp : ffff80000fb9b9a0 x29: ffff80000fb9b9b0 x28: ffff0000c6073400 x27: 0000000020001a00 x26: 0000000000000014 x25: ffff80000cf52000 x24: fffffc0000000000 x23: 05ffc00000000200 x22: fffffc000324bf80 x21: ffff0000c92fe1a8 x20: 0000000000000001 x19: 0000000000000004 x18: 0000000000000000 x17: 656a626f2042554c x16: ffff0000c6073dd0 x15: ffff80000dbd2118 x14: ffff0000c6073400 x13: 00000000ffffffff x12: ffff0000c6073400 x11: ff808000081bbb4c x10: 0000000000000000 x9 : 7b0572d7cc0ccf00 x8 : 7b0572d7cc0ccf00 x7 : ffff80000bf650d4 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000 x2 : ffff0001fefbff08 x1 : 0000000100000000 x0 : 000000000000006c Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:90 __check_heap_object+0xa8/0x100 mm/slub.c:4761 check_heap_object mm/usercopy.c:196 [inline] __check_object_size+0x208/0x6b8 mm/usercopy.c:251 check_object_size include/linux/thread_info.h:199 [inline] __copy_to_user include/linux/uaccess.h:115 [inline] put_cmsg+0x408/0x464 net/core/scm.c:238 sock_recv_mark net/socket.c:975 [inline] __sock_recv_cmsgs+0x1fc/0x248 net/socket.c:984 sock_recv_cmsgs include/net/sock.h:2728 [inline] packet_recvmsg+0x2d8/0x678 net/packet/af_packet.c:3482 ____sys_recvmsg+0x110/0x3a0 ___sys_recvmsg net/socket.c:2737 [inline] __sys_recvmsg+0x194/0x210 net/socket.c:2767 __do_sys_recvmsg net/socket.c:2777 [inline] __se_sys_recvmsg net/socket.c:2774 [inline] __arm64_sys_recvmsg+0x2c/0x3c net/socket.c:2774 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x64/0x178 arch/arm64/kernel/syscall.c:52 el0_svc_common+0xbc/0x180 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x48/0x110 arch/arm64/kernel/syscall.c:193 el0_svc+0x58/0x14c arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Code: 91388800 aa0903e1 f90003e8 94e6d752 (d4210000)
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: 2025-09-25
CVE-2023-52704
In the Linux kernel, the following vulnerability has been resolved: freezer,umh: Fix call_usermode_helper_exec() vs SIGKILL Tetsuo-San noted that commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic") broke call_usermodehelper_exec() for the KILLABLE case. Specifically it was missed that the second, unconditional, wait_for_completion() was not optional and ensures the on-stack completion is unused before going out-of-scope.
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-52706
In the Linux kernel, the following vulnerability has been resolved: gpio: sim: fix a memory leak Fix an inverted logic bug in gpio_sim_remove_hogs() that leads to GPIO hog structures never being freed.
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-52731
In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix invalid page access after closing deferred I/O devices When a fbdev with deferred I/O is once opened and closed, the dirty pages still remain queued in the pageref list, and eventually later those may be processed in the delayed work. This may lead to a corruption of pages, hitting an Oops. This patch makes sure to cancel the delayed work and clean up the pageref list at closing the device for addressing the bug. A part of the cleanup code is factored out as a new helper function that is called from the common fb_release().
- https://git.kernel.org/stable/c/3efc61d95259956db25347e2a9562c3e54546e20
- https://git.kernel.org/stable/c/87b9802ca824fcee7915e717e9a60471af62e8e9
- https://git.kernel.org/stable/c/f1d91f0e9d5a240a809698d7d9c5a538e7dcc149
- https://git.kernel.org/stable/c/3efc61d95259956db25347e2a9562c3e54546e20
- https://git.kernel.org/stable/c/87b9802ca824fcee7915e717e9a60471af62e8e9
- https://git.kernel.org/stable/c/f1d91f0e9d5a240a809698d7d9c5a538e7dcc149
Modified: 2025-09-25
CVE-2023-52732
In the Linux kernel, the following vulnerability has been resolved: ceph: blocklist the kclient when receiving corrupted snap trace When received corrupted snap trace we don't know what exactly has happened in MDS side. And we shouldn't continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents. This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself. The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster.
Modified: 2025-04-02
CVE-2023-52735
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/
- https://git.kernel.org/stable/c/5b4a79ba65a1ab479903fff2e604865d229b70a9
- https://git.kernel.org/stable/c/7499859881488da97589f3c79cc66fa75748ad49
- https://git.kernel.org/stable/c/f312367f5246e04df564d341044286e9e37a97ba
- https://git.kernel.org/stable/c/5b4a79ba65a1ab479903fff2e604865d229b70a9
- https://git.kernel.org/stable/c/7499859881488da97589f3c79cc66fa75748ad49
- https://git.kernel.org/stable/c/f312367f5246e04df564d341044286e9e37a97ba
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-01-10
CVE-2023-52737
In the Linux kernel, the following vulnerability has been resolved:
btrfs: lock the inode in shared mode before starting fiemap
Currently fiemap does not take the inode's lock (VFS lock), it only locks
a file range in the inode's io tree. This however can lead to a deadlock
if we have a concurrent fsync on the file and fiemap code triggers a fault
when accessing the user space buffer with fiemap_fill_next_extent(). The
deadlock happens on the inode's i_mmap_lock semaphore, which is taken both
by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by
syzbot and triggers a trace like the following:
task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004
Call Trace:
Modified: 2025-04-02
CVE-2023-52738
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
Currently amdgpu calls drm_sched_fini() from the fence driver sw fini
routine - such function is expected to be called only after the
respective init function - drm_sched_init() - was executed successfully.
Happens that we faced a driver probe failure in the Steam Deck
recently, and the function drm_sched_fini() was called even without
its counter-part had been previously called, causing the following oops:
amdgpu: probe of 0000:04:00.0 failed with error -110
BUG: kernel NULL pointer dereference, address: 0000000000000090
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338
Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]
[...]
Call Trace:
- https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b
- https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd
- https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535
- https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b
- https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd
- https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535
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-09-23
CVE-2023-52740
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch The RFI and STF security mitigation options can flip the interrupt_exit_not_reentrant static branch condition concurrently with the interrupt exit code which tests that branch. Interrupt exit tests this condition to set MSR[EE|RI] for exit, then again in the case a soft-masked interrupt is found pending, to recover the MSR so the interrupt can be replayed before attempting to exit again. If the condition changes between these two tests, the MSR and irq soft-mask state will become corrupted, leading to warnings and possible crashes. For example, if the branch is initially true then false, MSR[EE] will be 0 but PACA_IRQ_HARD_DIS clear and EE may not get enabled, leading to warnings in irq_64.c.
- https://git.kernel.org/stable/c/2ea31e2e62bbc4d11c411eeb36f1b02841dbcab1
- https://git.kernel.org/stable/c/6f097c24815e67909a1fcc2c605586d02babd673
- https://git.kernel.org/stable/c/86f7e423933608d536015a0f2eb9e0338c1227e0
- https://git.kernel.org/stable/c/2ea31e2e62bbc4d11c411eeb36f1b02841dbcab1
- https://git.kernel.org/stable/c/6f097c24815e67909a1fcc2c605586d02babd673
- https://git.kernel.org/stable/c/86f7e423933608d536015a0f2eb9e0338c1227e0
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-01-06
CVE-2023-52744
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix potential NULL-ptr-dereference in_dev_get() can return NULL which will cause a failure once idev is dereferenced in in_dev_for_each_ifa_rtnl(). This patch adds a check for NULL value in idev beforehand. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/360682fe7df262d94fae54f737c487bec0f9190d
- https://git.kernel.org/stable/c/5d9745cead1f121974322b94ceadfb4d1e67960e
- https://git.kernel.org/stable/c/8f5fe1cd8e6a97f94840b55f59ed08cbc397086f
- https://git.kernel.org/stable/c/360682fe7df262d94fae54f737c487bec0f9190d
- https://git.kernel.org/stable/c/5d9745cead1f121974322b94ceadfb4d1e67960e
- https://git.kernel.org/stable/c/8f5fe1cd8e6a97f94840b55f59ed08cbc397086f
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: 2025-09-23
CVE-2023-52748
In the Linux kernel, the following vulnerability has been resolved: f2fs: avoid format-overflow warning With gcc and W=1 option, there's a warning like this: fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’: fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between 1 and 7 bytes into a region of size between 5 and 8 [-Werror=format-overflow=] 1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev), MINOR(dev)); | ^~ String "f2fs_page_array_entry-%u:%u" can up to 35. The first "%u" can up to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35". slab_name's size should be 35 rather than 32.
- https://git.kernel.org/stable/c/3eebe636cac53886bd5d1cdd55e082ec9e84983f
- https://git.kernel.org/stable/c/526dd7540a09ecf87b5f54f3ab4e0a2528f25a79
- https://git.kernel.org/stable/c/6fca08fd3085253b48fcb1bd243a0a5e18821a00
- https://git.kernel.org/stable/c/c041f5ddef00c731c541e00bc8ae97b8c84c682f
- https://git.kernel.org/stable/c/e0d4e8acb3789c5a8651061fbab62ca24a45c063
- https://git.kernel.org/stable/c/e4088d7d8f1123006d46a42edf51b8c960a58ef9
- https://git.kernel.org/stable/c/3eebe636cac53886bd5d1cdd55e082ec9e84983f
- https://git.kernel.org/stable/c/526dd7540a09ecf87b5f54f3ab4e0a2528f25a79
- https://git.kernel.org/stable/c/6fca08fd3085253b48fcb1bd243a0a5e18821a00
- https://git.kernel.org/stable/c/c041f5ddef00c731c541e00bc8ae97b8c84c682f
- https://git.kernel.org/stable/c/e0d4e8acb3789c5a8651061fbab62ca24a45c063
- https://git.kernel.org/stable/c/e4088d7d8f1123006d46a42edf51b8c960a58ef9
Modified: 2025-01-06
CVE-2023-52749
In the Linux kernel, the following vulnerability has been resolved: spi: Fix null dereference on suspend A race condition exists where a synchronous (noqueue) transfer can be active during a system suspend. This can cause a null pointer dereference exception to occur when the system resumes. Example order of events leading to the exception: 1. spi_sync() calls __spi_transfer_message_noqueue() which sets ctlr->cur_msg 2. Spi transfer begins via spi_transfer_one_message() 3. System is suspended interrupting the transfer context 4. System is resumed 6. spi_controller_resume() calls spi_start_queue() which resets cur_msg to NULL 7. Spi transfer context resumes and spi_finalize_current_message() is called which dereferences cur_msg (which is now NULL) Wait for synchronous transfers to complete before suspending by acquiring the bus mutex and setting/checking a suspend flag.
- https://git.kernel.org/stable/c/4ec4508db97502a12daee88c74782e8d35ced068
- https://git.kernel.org/stable/c/96474ea47dc67b0704392d59192b233c8197db0e
- https://git.kernel.org/stable/c/bef4a48f4ef798c4feddf045d49e53c8a97d5e37
- https://git.kernel.org/stable/c/4ec4508db97502a12daee88c74782e8d35ced068
- https://git.kernel.org/stable/c/96474ea47dc67b0704392d59192b233c8197db0e
- https://git.kernel.org/stable/c/bef4a48f4ef798c4feddf045d49e53c8a97d5e37
Modified: 2025-09-25
CVE-2023-52750
In the Linux kernel, the following vulnerability has been resolved: arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0. This went unnoticed until commit: 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD") Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state. After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g. | Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __pi_strcmp+0x1c/0x150 | lr : populate_properties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x13c/0x340 | el1t_64_irq_handler+0x0/0x1c | el1_abort+0x0/0x5c | el1h_64_sync+0x64/0x68 | __pi_strcmp+0x1c/0x150 | unflatten_dt_nodes+0x1e8/0x2d8 | __unflatten_device_tree+0x5c/0x15c | unflatten_device_tree+0x38/0x50 | setup_arch+0x164/0x1e0 | start_kernel+0x64/0x38c | __primary_switched+0xbc/0xc4 Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit.
- https://git.kernel.org/stable/c/146a15b873353f8ac28dc281c139ff611a3c4848
- https://git.kernel.org/stable/c/69e619d2fd056fe1f5d0adf01584f2da669e0d28
- https://git.kernel.org/stable/c/936c9c10efaefaf1ab3ef020e1f8aaaaff1ad2f9
- https://git.kernel.org/stable/c/bd31e534721ab95ef237020fe6995c899ffdf21a
- https://git.kernel.org/stable/c/d08a1e75253b4e19ae290b1c35349f12cfcebc0a
- https://git.kernel.org/stable/c/ef0224ee5399ea8a46bc07dc6c6494961ed5fdd2
- https://git.kernel.org/stable/c/146a15b873353f8ac28dc281c139ff611a3c4848
- https://git.kernel.org/stable/c/69e619d2fd056fe1f5d0adf01584f2da669e0d28
- https://git.kernel.org/stable/c/936c9c10efaefaf1ab3ef020e1f8aaaaff1ad2f9
- https://git.kernel.org/stable/c/bd31e534721ab95ef237020fe6995c899ffdf21a
- https://git.kernel.org/stable/c/d08a1e75253b4e19ae290b1c35349f12cfcebc0a
- https://git.kernel.org/stable/c/ef0224ee5399ea8a46bc07dc6c6494961ed5fdd2
Modified: 2025-11-25
CVE-2023-52752
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
Skip SMB sessions that are being teared down
(e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show()
to avoid use-after-free in @ses.
This fixes the following GPF when reading from /proc/fs/cifs/DebugData
while mounting and umounting
[ 816.251274] general protection fault, probably for non-canonical
address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI
...
[ 816.260138] Call Trace:
[ 816.260329]
- https://git.kernel.org/stable/c/0ab6f842452ce2cae04209d4671ac6289d0aef8a
- https://git.kernel.org/stable/c/2abdf136784b7edaec7ffe0f4b461b63f9c4c4de
- https://git.kernel.org/stable/c/336a066990bb3962c46daf574ace596bda9303ce
- https://git.kernel.org/stable/c/558817597d5fbd7af31f891b67b0fd20f0d047b7
- https://git.kernel.org/stable/c/89929ea46f9cc11ba66d2c64713aa5d5dc723b09
- https://git.kernel.org/stable/c/d328c09ee9f15ee5a26431f5aad7c9239fa85e62
- https://git.kernel.org/stable/c/0ab6f842452ce2cae04209d4671ac6289d0aef8a
- https://git.kernel.org/stable/c/558817597d5fbd7af31f891b67b0fd20f0d047b7
- https://git.kernel.org/stable/c/89929ea46f9cc11ba66d2c64713aa5d5dc723b09
- https://git.kernel.org/stable/c/d328c09ee9f15ee5a26431f5aad7c9239fa85e62
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2024-11-21
CVE-2023-52753
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference of timing generator [Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference.
- https://git.kernel.org/stable/c/09909f515032fa80b921fd3118efe66b185d10fd
- https://git.kernel.org/stable/c/4e497f1acd99075b13605b2e7fa0cba721a2cfd9
- https://git.kernel.org/stable/c/6d8653b1a7a8dc938b566ae8c4f373b36e792c68
- https://git.kernel.org/stable/c/79b6a90f4f2433312154cd68452b0ba501fa74db
- https://git.kernel.org/stable/c/8a06894666e0b462c9316b26ab615cefdd0d676c
- https://git.kernel.org/stable/c/b1904ed480cee3f9f4036ea0e36d139cb5fee2d6
- https://git.kernel.org/stable/c/df8bc953eed72371e43ca407bd063507f760cf89
- https://git.kernel.org/stable/c/eac3e4760aa12159f7f5475d55a67b7933abc195
- https://git.kernel.org/stable/c/09909f515032fa80b921fd3118efe66b185d10fd
- https://git.kernel.org/stable/c/4e497f1acd99075b13605b2e7fa0cba721a2cfd9
- https://git.kernel.org/stable/c/6d8653b1a7a8dc938b566ae8c4f373b36e792c68
- https://git.kernel.org/stable/c/79b6a90f4f2433312154cd68452b0ba501fa74db
- https://git.kernel.org/stable/c/8a06894666e0b462c9316b26ab615cefdd0d676c
- https://git.kernel.org/stable/c/b1904ed480cee3f9f4036ea0e36d139cb5fee2d6
- https://git.kernel.org/stable/c/df8bc953eed72371e43ca407bd063507f760cf89
- https://git.kernel.org/stable/c/eac3e4760aa12159f7f5475d55a67b7933abc195
Modified: 2025-09-23
CVE-2023-52754
In the Linux kernel, the following vulnerability has been resolved: media: imon: fix access to invalid resource for the second interface imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver. This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.
- https://git.kernel.org/stable/c/0f5068519f89d928d6c51100e4b274479123829f
- https://git.kernel.org/stable/c/10ec5a97f8f5a772a1a42b4eb27196b447cd3aa9
- https://git.kernel.org/stable/c/2a493a34bd6e496c55fabedd82b957193ace178f
- https://git.kernel.org/stable/c/5e0b788fb96be36d1baf1a5c88d09c7c82a0452a
- https://git.kernel.org/stable/c/a1766a4fd83befa0b34d932d532e7ebb7fab1fa7
- https://git.kernel.org/stable/c/b083aaf5db2eeca9e362723258e5d8698f7dd84e
- https://git.kernel.org/stable/c/0f5068519f89d928d6c51100e4b274479123829f
- https://git.kernel.org/stable/c/10ec5a97f8f5a772a1a42b4eb27196b447cd3aa9
- https://git.kernel.org/stable/c/2a493a34bd6e496c55fabedd82b957193ace178f
- https://git.kernel.org/stable/c/5e0b788fb96be36d1baf1a5c88d09c7c82a0452a
- https://git.kernel.org/stable/c/a1766a4fd83befa0b34d932d532e7ebb7fab1fa7
- https://git.kernel.org/stable/c/b083aaf5db2eeca9e362723258e5d8698f7dd84e
Modified: 2025-04-02
CVE-2023-52755
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab out of bounds write in smb_inherit_dacl() slab out-of-bounds write is caused by that offsets is bigger than pntsd allocation size. This patch add the check to validate 3 offsets using allocation size.
- https://git.kernel.org/stable/c/09d9d8b40a3338193619c14ed4dc040f4f119e70
- https://git.kernel.org/stable/c/712e01f32e577e7e48ab0adb5fe550646a3d93cb
- https://git.kernel.org/stable/c/8387c94d73ec66eb597c7a23a8d9eadf64bfbafa
- https://git.kernel.org/stable/c/aaf0a07d60887d6c36fc46a24de0083744f07819
- https://git.kernel.org/stable/c/eebff19acaa35820cb09ce2ccb3d21bee2156ffb
- https://git.kernel.org/stable/c/09d9d8b40a3338193619c14ed4dc040f4f119e70
- https://git.kernel.org/stable/c/712e01f32e577e7e48ab0adb5fe550646a3d93cb
- https://git.kernel.org/stable/c/8387c94d73ec66eb597c7a23a8d9eadf64bfbafa
- https://git.kernel.org/stable/c/aaf0a07d60887d6c36fc46a24de0083744f07819
- https://git.kernel.org/stable/c/eebff19acaa35820cb09ce2ccb3d21bee2156ffb
Modified: 2025-11-25
CVE-2023-52757
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when releasing mids All release_mid() callers seem to hold a reference of @mid so there is no need to call kref_put(&mid->refcount, __release_mid) under @server->mid_lock spinlock. If they don't, then an use-after-free bug would have occurred anyways. By getting rid of such spinlock also fixes a potential deadlock as shown below CPU 0 CPU 1 ------------------------------------------------------------------ cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&server->mid_lock); spin_lock(&cifs_tcp_ses_lock) spin_lock(&server->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *deadlock*
- https://git.kernel.org/stable/c/99f476e27aad5964ab13777d84fda67d1356dec1
- https://git.kernel.org/stable/c/9eb44db68c5b7f5aa22b8fc7de74a3e2e08d1f29
- https://git.kernel.org/stable/c/b9bb9607b1fc12fca51f5632da25b36975f599bf
- https://git.kernel.org/stable/c/c1a5962f1462b64fe7b69f20a4b6af8067bc2d26
- https://git.kernel.org/stable/c/ce49569079a9d4cad26c0f1d4653382fd9a5ca7a
- https://git.kernel.org/stable/c/e6322fd177c6885a21dd4609dc5e5c973d1a2eb7
- https://git.kernel.org/stable/c/9eb44db68c5b7f5aa22b8fc7de74a3e2e08d1f29
- https://git.kernel.org/stable/c/b9bb9607b1fc12fca51f5632da25b36975f599bf
- https://git.kernel.org/stable/c/c1a5962f1462b64fe7b69f20a4b6af8067bc2d26
- https://git.kernel.org/stable/c/e6322fd177c6885a21dd4609dc5e5c973d1a2eb7
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-09-23
CVE-2023-52762
In the Linux kernel, the following vulnerability has been resolved: virtio-blk: fix implicit overflow on virtio_max_dma_size The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead.
- https://git.kernel.org/stable/c/017278f141141367f7d14b203e930b45b6ffffb9
- https://git.kernel.org/stable/c/472bd4787406bef2e8b41ee4c74d960a06a49a48
- https://git.kernel.org/stable/c/72775cad7f572bb2501f9ea609e1d20e68f0b38b
- https://git.kernel.org/stable/c/d667fe301dcbcb12d1d6494fc4b8abee2cb75d90
- https://git.kernel.org/stable/c/fafb51a67fb883eb2dde352539df939a251851be
- https://git.kernel.org/stable/c/017278f141141367f7d14b203e930b45b6ffffb9
- https://git.kernel.org/stable/c/472bd4787406bef2e8b41ee4c74d960a06a49a48
- https://git.kernel.org/stable/c/72775cad7f572bb2501f9ea609e1d20e68f0b38b
- https://git.kernel.org/stable/c/d667fe301dcbcb12d1d6494fc4b8abee2cb75d90
- https://git.kernel.org/stable/c/fafb51a67fb883eb2dde352539df939a251851be
Modified: 2025-09-19
CVE-2023-52763
In the Linux kernel, the following vulnerability has been resolved: i3c: master: mipi-i3c-hci: Fix a kernel panic for accessing DAT_data. The `i3c_master_bus_init` function may attach the I2C devices before the I3C bus initialization. In this flow, the DAT `alloc_entry`` will be used before the DAT `init`. Additionally, if the `i3c_master_bus_init` fails, the DAT `cleanup` will execute before the device is detached, which will execue DAT `free_entry` function. The above scenario can cause the driver to use DAT_data when it is NULL.
- https://git.kernel.org/stable/c/39c71357e68e2f03766f9321b9f4882e49ff1442
- https://git.kernel.org/stable/c/3cb79a365e7cce8f121bba91312e2ddd206b9781
- https://git.kernel.org/stable/c/b53e9758a31c683fc8615df930262192ed5f034b
- https://git.kernel.org/stable/c/e64d23dc65810be4e3395d72df0c398f60c991f9
- https://git.kernel.org/stable/c/eed74230435c61eeb58abaa275b1820e6a4b7f02
- https://git.kernel.org/stable/c/39c71357e68e2f03766f9321b9f4882e49ff1442
- https://git.kernel.org/stable/c/3cb79a365e7cce8f121bba91312e2ddd206b9781
- https://git.kernel.org/stable/c/b53e9758a31c683fc8615df930262192ed5f034b
- https://git.kernel.org/stable/c/e64d23dc65810be4e3395d72df0c398f60c991f9
- https://git.kernel.org/stable/c/eed74230435c61eeb58abaa275b1820e6a4b7f02
Modified: 2025-09-23
CVE-2023-52764
In the Linux kernel, the following vulnerability has been resolved: media: gspca: cpia1: shift-out-of-bounds in set_flicker Syzkaller reported the following issue: UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27 shift exponent 245 is too large for 32-bit type 'int' When the value of the variable "sd->params.exposure.gain" exceeds the number of bits in an integer, a shift-out-of-bounds error is reported. It is triggered because the variable "currentexp" cannot be left-shifted by more than the number of bits in an integer. In order to avoid invalid range during left-shift, the conditional expression is added.
- https://git.kernel.org/stable/c/099be1822d1f095433f4b08af9cc9d6308ec1953
- https://git.kernel.org/stable/c/09cd8b561aa9796903710a1046957f2b112c8f26
- https://git.kernel.org/stable/c/2eee8edfff90e22980a6b22079d238c3c9d323bb
- https://git.kernel.org/stable/c/69bba62600bd91d6b7c1e8ca181faf8ac64f7060
- https://git.kernel.org/stable/c/8f83c85ee88225319c52680792320c02158c2a9b
- https://git.kernel.org/stable/c/93bddd6529f187f510eec759f37d0569243c9809
- https://git.kernel.org/stable/c/a647f27a7426d2fe1b40da7c8fa2b81354a51177
- https://git.kernel.org/stable/c/c6b6b8692218da73b33b310d7c1df90f115bdd9a
- https://git.kernel.org/stable/c/e2d7149b913d14352c82624e723ce1c211ca06d3
- https://git.kernel.org/stable/c/099be1822d1f095433f4b08af9cc9d6308ec1953
- https://git.kernel.org/stable/c/09cd8b561aa9796903710a1046957f2b112c8f26
- https://git.kernel.org/stable/c/2eee8edfff90e22980a6b22079d238c3c9d323bb
- https://git.kernel.org/stable/c/69bba62600bd91d6b7c1e8ca181faf8ac64f7060
- https://git.kernel.org/stable/c/8f83c85ee88225319c52680792320c02158c2a9b
- https://git.kernel.org/stable/c/93bddd6529f187f510eec759f37d0569243c9809
- https://git.kernel.org/stable/c/a647f27a7426d2fe1b40da7c8fa2b81354a51177
- https://git.kernel.org/stable/c/c6b6b8692218da73b33b310d7c1df90f115bdd9a
- https://git.kernel.org/stable/c/e2d7149b913d14352c82624e723ce1c211ca06d3
Modified: 2025-04-02
CVE-2023-52765
In the Linux kernel, the following vulnerability has been resolved: mfd: qcom-spmi-pmic: Fix revid implementation The Qualcomm SPMI PMIC revid implementation is broken in multiple ways. First, it assumes that just because the sibling base device has been registered that means that it is also bound to a driver, which may not be the case (e.g. due to probe deferral or asynchronous probe). This could trigger a NULL-pointer dereference when attempting to access the driver data of the unbound device. Second, it accesses driver data of a sibling device directly and without any locking, which means that the driver data may be freed while it is being accessed (e.g. on driver unbind). Third, it leaks a struct device reference to the sibling device which is looked up using the spmi_device_from_of() every time a function (child) device is calling the revid function (e.g. on probe). Fix this mess by reimplementing the revid lookup so that it is done only at probe of the PMIC device; the base device fetches the revid info from the hardware, while any secondary SPMI device fetches the information from the base device and caches it so that it can be accessed safely from its children. If the base device has not been probed yet then probe of a secondary device is deferred.
- https://git.kernel.org/stable/c/4ce77b023d42a9f1062eecf438df1af4b4072eb2
- https://git.kernel.org/stable/c/7b439aaa62fee474a0d84d67a25f4984467e7b95
- https://git.kernel.org/stable/c/affae18838db5e6b463ee30c821385695af56dc2
- https://git.kernel.org/stable/c/db98de0809f12b0edb9cd1be78e1ec1bfeba8f40
- https://git.kernel.org/stable/c/4ce77b023d42a9f1062eecf438df1af4b4072eb2
- https://git.kernel.org/stable/c/7b439aaa62fee474a0d84d67a25f4984467e7b95
- https://git.kernel.org/stable/c/affae18838db5e6b463ee30c821385695af56dc2
- https://git.kernel.org/stable/c/db98de0809f12b0edb9cd1be78e1ec1bfeba8f40
Modified: 2025-01-06
CVE-2023-52766
In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler Do not loop over ring headers in hci_dma_irq_handler() that are not allocated and enabled in hci_dma_init(). Otherwise out of bounds access will occur from rings->headers[i] access when i >= number of allocated ring headers.
- https://git.kernel.org/stable/c/45a832f989e520095429589d5b01b0c65da9b574
- https://git.kernel.org/stable/c/4c86cb2321bd9c72d3b945ce7f747961beda8e65
- https://git.kernel.org/stable/c/7c2b91b30d74d7c407118ad72502d4ca28af1af6
- https://git.kernel.org/stable/c/8be39f66915b40d26ea2c18ba84b5c3d5da6809b
- https://git.kernel.org/stable/c/d23ad76f240c0f597b7a9eb79905d246f27d40df
- https://git.kernel.org/stable/c/45a832f989e520095429589d5b01b0c65da9b574
- https://git.kernel.org/stable/c/4c86cb2321bd9c72d3b945ce7f747961beda8e65
- https://git.kernel.org/stable/c/7c2b91b30d74d7c407118ad72502d4ca28af1af6
- https://git.kernel.org/stable/c/8be39f66915b40d26ea2c18ba84b5c3d5da6809b
- https://git.kernel.org/stable/c/d23ad76f240c0f597b7a9eb79905d246f27d40df
Modified: 2025-04-02
CVE-2023-52768
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: use vmm_table as array in wilc struct Enabling KASAN and running some iperf tests raises some memory issues with vmm_table: BUG: KASAN: slab-out-of-bounds in wilc_wlan_handle_txq+0x6ac/0xdb4 Write of size 4 at addr c3a61540 by task wlan0-tx/95 KASAN detects that we are writing data beyond range allocated to vmm_table. There is indeed a mismatch between the size passed to allocator in wilc_wlan_init, and the range of possible indexes used later: allocation size is missing a multiplication by sizeof(u32)
- https://git.kernel.org/stable/c/05ac1a198a63ad66bf5ae8b7321407c102d40ef3
- https://git.kernel.org/stable/c/3ce1c2c3999b232258f7aabab311d47dda75605c
- https://git.kernel.org/stable/c/4b0d6ddb6466d10df878a7787f175a0e4adc3e27
- https://git.kernel.org/stable/c/541b3757fd443a68ed8d25968eae511a8275e7c8
- https://git.kernel.org/stable/c/6aaf7cd8bdfe245d3c9a8b48fe70c2011965948e
- https://git.kernel.org/stable/c/05ac1a198a63ad66bf5ae8b7321407c102d40ef3
- https://git.kernel.org/stable/c/3ce1c2c3999b232258f7aabab311d47dda75605c
- https://git.kernel.org/stable/c/4b0d6ddb6466d10df878a7787f175a0e4adc3e27
- https://git.kernel.org/stable/c/541b3757fd443a68ed8d25968eae511a8275e7c8
- https://git.kernel.org/stable/c/6aaf7cd8bdfe245d3c9a8b48fe70c2011965948e
Modified: 2024-11-21
CVE-2023-52772
In the Linux kernel, the following vulnerability has been resolved:
af_unix: fix use-after-free in unix_stream_read_actor()
syzbot reported the following crash [1]
After releasing unix socket lock, u->oob_skb can be changed
by another thread. We must temporarily increase skb refcount
to make sure this other thread will not free the skb under us.
[1]
BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866
Read of size 4 at addr ffff88801f3b9cc4 by task syz-executor107/5297
CPU: 1 PID: 5297 Comm: syz-executor107 Not tainted 6.6.0-syzkaller-15910-gb8e3a87a627b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
Call Trace:
- https://git.kernel.org/stable/c/069a3ec329ff43e7869a3d94c62cd03203016bce
- https://git.kernel.org/stable/c/4b7b492615cf3017190f55444f7016812b66611d
- https://git.kernel.org/stable/c/75bcfc188abf4fae9c1d5f5dc0a03540be602eef
- https://git.kernel.org/stable/c/d179189eec426fe4801e4b91efa1889faed12700
- https://git.kernel.org/stable/c/eae0b295ce16d8c8b4114c3037993191b4bb92f0
- https://git.kernel.org/stable/c/069a3ec329ff43e7869a3d94c62cd03203016bce
- https://git.kernel.org/stable/c/4b7b492615cf3017190f55444f7016812b66611d
- https://git.kernel.org/stable/c/75bcfc188abf4fae9c1d5f5dc0a03540be602eef
- https://git.kernel.org/stable/c/d179189eec426fe4801e4b91efa1889faed12700
- https://git.kernel.org/stable/c/eae0b295ce16d8c8b4114c3037993191b4bb92f0
Modified: 2024-11-21
CVE-2023-52773
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer() When ddc_service_construct() is called, it explicitly checks both the link type and whether there is something on the link which will dictate whether the pin is marked as hw_supported. If the pin isn't set or the link is not set (such as from unloading/reloading amdgpu in an IGT test) then fail the amdgpu_dm_i2c_xfer() call.
- https://git.kernel.org/stable/c/1d07b7e84276777dad3c8cfebdf8e739606f90c9
- https://git.kernel.org/stable/c/5b14cf37b9f01de0b28c6f8960019d4c7883ce42
- https://git.kernel.org/stable/c/b71f4ade1b8900d30c661d6c27f87c35214c398c
- https://git.kernel.org/stable/c/fb5c134ca589fe670430acc9e7ebf2691ca2476d
- https://git.kernel.org/stable/c/1d07b7e84276777dad3c8cfebdf8e739606f90c9
- https://git.kernel.org/stable/c/5b14cf37b9f01de0b28c6f8960019d4c7883ce42
- https://git.kernel.org/stable/c/b71f4ade1b8900d30c661d6c27f87c35214c398c
- https://git.kernel.org/stable/c/fb5c134ca589fe670430acc9e7ebf2691ca2476d
Modified: 2025-09-23
CVE-2023-52774
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: protect device queue against concurrent access In dasd_profile_start() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasd_profile_start() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses. Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path.
- https://git.kernel.org/stable/c/6062c527d0403cef27c54b91ac8390c3a497b250
- https://git.kernel.org/stable/c/9372aab5d0ff621ea203c8c603e7e5f75e888240
- https://git.kernel.org/stable/c/c841de6247e94e07566d57163d3c0d8b29278f7a
- https://git.kernel.org/stable/c/db46cd1e0426f52999d50fa72cfa97fa39952885
- https://git.kernel.org/stable/c/dc96fde8fcb2b896fd6c64802a7f4ece2e69b0be
- https://git.kernel.org/stable/c/ebdc569a07a3e8dbe66b4184922ad6f88ac0b96f
- https://git.kernel.org/stable/c/f1ac7789406e2ca9ac51c41ad2daa597f47bdd4d
- https://git.kernel.org/stable/c/f75617cc8df4155374132f0b500b0b3ebb967458
- https://git.kernel.org/stable/c/6062c527d0403cef27c54b91ac8390c3a497b250
- https://git.kernel.org/stable/c/9372aab5d0ff621ea203c8c603e7e5f75e888240
- https://git.kernel.org/stable/c/c841de6247e94e07566d57163d3c0d8b29278f7a
- https://git.kernel.org/stable/c/db46cd1e0426f52999d50fa72cfa97fa39952885
- https://git.kernel.org/stable/c/dc96fde8fcb2b896fd6c64802a7f4ece2e69b0be
- https://git.kernel.org/stable/c/ebdc569a07a3e8dbe66b4184922ad6f88ac0b96f
- https://git.kernel.org/stable/c/f1ac7789406e2ca9ac51c41ad2daa597f47bdd4d
- https://git.kernel.org/stable/c/f75617cc8df4155374132f0b500b0b3ebb967458
Modified: 2025-09-23
CVE-2023-52775
In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid data corruption caused by decline We found a data corruption issue during testing of SMC-R on Redis applications. The benchmark has a low probability of reporting a strange error as shown below. "Error: Protocol error, got "\xe2" as reply type byte" Finally, we found that the retrieved error data was as follows: 0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2 It is quite obvious that this is a SMC DECLINE message, which means that the applications received SMC protocol message. We found that this was caused by the following situations: client server ¦ clc proposal -------------> ¦ clc accept <------------- ¦ clc confirm -------------> wait llc confirm send llc confirm ¦failed llc confirm ¦ x------ (after 2s)timeout wait llc confirm rsp wait decline (after 1s) timeout (after 2s) timeout ¦ decline --------------> ¦ decline <-------------- As a result, a decline message was sent in the implementation, and this message was read from TCP by the already-fallback connection. This patch double the client timeout as 2x of the server value, With this simple change, the Decline messages should never cross or collide (during Confirm link timeout). This issue requires an immediate solution, since the protocol updates involve a more long-term solution.
- https://git.kernel.org/stable/c/5ada292b5c504720a0acef8cae9acc62a694d19c
- https://git.kernel.org/stable/c/7234d2b5dffa5af77fd4e0deaebab509e130c6b1
- https://git.kernel.org/stable/c/90072af9efe8c7bd7d086709014ddd44cebd5e7c
- https://git.kernel.org/stable/c/94a0ae698b4d5d5bb598e23228002a1491c50add
- https://git.kernel.org/stable/c/e6d71b437abc2f249e3b6a1ae1a7228e09c6e563
- https://git.kernel.org/stable/c/5ada292b5c504720a0acef8cae9acc62a694d19c
- https://git.kernel.org/stable/c/7234d2b5dffa5af77fd4e0deaebab509e130c6b1
- https://git.kernel.org/stable/c/90072af9efe8c7bd7d086709014ddd44cebd5e7c
- https://git.kernel.org/stable/c/94a0ae698b4d5d5bb598e23228002a1491c50add
- https://git.kernel.org/stable/c/e6d71b437abc2f249e3b6a1ae1a7228e09c6e563
Modified: 2025-01-14
CVE-2023-52777
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix gtk offload status event locking The ath11k active pdevs are protected by RCU but the gtk offload status event handling code calling ath11k_mac_get_arvif_by_vdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only.
- https://git.kernel.org/stable/c/0cf7577b6b3153b4b49deea9719fe43f96469c6d
- https://git.kernel.org/stable/c/1dea3c0720a146bd7193969f2847ccfed5be2221
- https://git.kernel.org/stable/c/cf9c7d783a2bf9305df4ef5b93d9063a52e18fca
- https://git.kernel.org/stable/c/e83246ecd3b193f8d91fce778e8a5ba747fc7d8a
- https://git.kernel.org/stable/c/0cf7577b6b3153b4b49deea9719fe43f96469c6d
- https://git.kernel.org/stable/c/1dea3c0720a146bd7193969f2847ccfed5be2221
- https://git.kernel.org/stable/c/cf9c7d783a2bf9305df4ef5b93d9063a52e18fca
- https://git.kernel.org/stable/c/e83246ecd3b193f8d91fce778e8a5ba747fc7d8a
Modified: 2025-09-25
CVE-2023-52778
In the Linux kernel, the following vulnerability has been resolved:
mptcp: deal with large GSO size
After the blamed commit below, the TCP sockets (and the MPTCP subflows)
can build egress packets larger than 64K. That exceeds the maximum DSS
data size, the length being misrepresent on the wire and the stream being
corrupted, as later observed on the receiver:
WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0
CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.
RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705
RSP: 0018:ffffc90000006e80 EFLAGS: 00010246
RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000
netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.
RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908
RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a
R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908
R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29
FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/342b528c0e849bed9def76dadaa470d3af678e94
- https://git.kernel.org/stable/c/57ced2eb77343a91d28f4a73675b05fe7b555def
- https://git.kernel.org/stable/c/70ff9b65a72885b3a2dfde6709da1f19b85fa696
- https://git.kernel.org/stable/c/9fce92f050f448a0d1ddd9083ef967d9930f1e52
- https://git.kernel.org/stable/c/342b528c0e849bed9def76dadaa470d3af678e94
- https://git.kernel.org/stable/c/57ced2eb77343a91d28f4a73675b05fe7b555def
- https://git.kernel.org/stable/c/70ff9b65a72885b3a2dfde6709da1f19b85fa696
- https://git.kernel.org/stable/c/9fce92f050f448a0d1ddd9083ef967d9930f1e52
Modified: 2025-02-03
CVE-2023-52780
In the Linux kernel, the following vulnerability has been resolved:
net: mvneta: fix calls to page_pool_get_stats
Calling page_pool_get_stats in the mvneta driver without checks
leads to kernel crashes.
First the page pool is only available if the bm is not used.
The page pool is also not allocated when the port is stopped.
It can also be not allocated in case of errors.
The current implementation leads to the following crash calling
ethstats on a port that is down or when calling it at the wrong moment:
ble to handle kernel NULL pointer dereference at virtual address 00000070
[00000070] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Hardware name: Marvell Armada 380/385 (Device Tree)
PC is at page_pool_get_stats+0x18/0x1cc
LR is at mvneta_ethtool_get_stats+0xa0/0xe0 [mvneta]
pc : [
- https://git.kernel.org/stable/c/00768b3e90e648227eaa959d9d279f5e32823df1
- https://git.kernel.org/stable/c/230dc06e2495487d88b3410da055bb618febb19b
- https://git.kernel.org/stable/c/2b0e99072654edd601d05c0061a20337af5008ba
- https://git.kernel.org/stable/c/ca8add922f9c7f6e2e3c71039da8e0dcc64b87ed
- https://git.kernel.org/stable/c/00768b3e90e648227eaa959d9d279f5e32823df1
- https://git.kernel.org/stable/c/230dc06e2495487d88b3410da055bb618febb19b
- https://git.kernel.org/stable/c/2b0e99072654edd601d05c0061a20337af5008ba
- https://git.kernel.org/stable/c/ca8add922f9c7f6e2e3c71039da8e0dcc64b87ed
Modified: 2025-09-25
CVE-2023-52781
In the Linux kernel, the following vulnerability has been resolved: usb: config: fix iteration issue in 'usb_get_bos_descriptor()' The BOS descriptor defines a root descriptor and is the base descriptor for accessing a family of related descriptors. Function 'usb_get_bos_descriptor()' encounters an iteration issue when skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in the same descriptor being read repeatedly. To address this issue, a 'goto' statement is introduced to ensure that the pointer and the amount read is updated correctly. This ensures that the function iterates to the next descriptor instead of reading the same descriptor repeatedly.
- https://git.kernel.org/stable/c/64c27b7b2357ddb38b6afebaf46d5bff4d250702
- https://git.kernel.org/stable/c/7c0244cc311a4038505b73682b7c8ceaa5c7a8c8
- https://git.kernel.org/stable/c/974bba5c118f4c2baf00de0356e3e4f7928b4cbc
- https://git.kernel.org/stable/c/9ef94ec8e52eaf7b9abc5b5f8f5b911751112223
- https://git.kernel.org/stable/c/f89fef7710b2ba0f7a1e46594e530dcf2f77be91
- https://git.kernel.org/stable/c/64c27b7b2357ddb38b6afebaf46d5bff4d250702
- https://git.kernel.org/stable/c/7c0244cc311a4038505b73682b7c8ceaa5c7a8c8
- https://git.kernel.org/stable/c/974bba5c118f4c2baf00de0356e3e4f7928b4cbc
- https://git.kernel.org/stable/c/9ef94ec8e52eaf7b9abc5b5f8f5b911751112223
- https://git.kernel.org/stable/c/f89fef7710b2ba0f7a1e46594e530dcf2f77be91
Modified: 2025-09-25
CVE-2023-52784
In the Linux kernel, the following vulnerability has been resolved: bonding: stop the device in bond_setup_by_slave() Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today. In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRD_ETHER member forced the bonding master to change its type. The fix is to make sure we call dev_close() in bond_setup_by_slave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed. A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRD_ETHER enslave failure") [1] skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:188 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 lr : skb_panic net/core/skbuff.c:188 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 sp : ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086 Call trace: skb_panic net/core/skbuff.c:188 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/netdevice.h:3136 [inline] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 sock_ioctl+0x4e8/0x834 net/socket.c:1322 vfs_ioctl fs/ioctl.c:51 [inline] __do_ ---truncated---
- https://git.kernel.org/stable/c/19554aa901b5833787df4417a05ccdebf351b7f4
- https://git.kernel.org/stable/c/396baca6683f415b5bc2b380289387bef1406edc
- https://git.kernel.org/stable/c/3cffa2ddc4d3fcf70cde361236f5a614f81a09b2
- https://git.kernel.org/stable/c/53064e8239dd2ecfefc5634e991f1025abc2ee0c
- https://git.kernel.org/stable/c/87c49806a37f88eddde3f537c162fd0c2834170c
- https://git.kernel.org/stable/c/b4f0e605a508f6d7cda6df2f03a0c676b778b1fe
- https://git.kernel.org/stable/c/d98c91215a5748a0f536e7ccea26027005196859
- https://git.kernel.org/stable/c/19554aa901b5833787df4417a05ccdebf351b7f4
- https://git.kernel.org/stable/c/396baca6683f415b5bc2b380289387bef1406edc
- https://git.kernel.org/stable/c/3cffa2ddc4d3fcf70cde361236f5a614f81a09b2
- https://git.kernel.org/stable/c/53064e8239dd2ecfefc5634e991f1025abc2ee0c
- https://git.kernel.org/stable/c/87c49806a37f88eddde3f537c162fd0c2834170c
- https://git.kernel.org/stable/c/b4f0e605a508f6d7cda6df2f03a0c676b778b1fe
- https://git.kernel.org/stable/c/d98c91215a5748a0f536e7ccea26027005196859
Modified: 2025-09-26
CVE-2023-52787
In the Linux kernel, the following vulnerability has been resolved: blk-mq: make sure active queue usage is held for bio_integrity_prep() blk_integrity_unregister() can come if queue usage counter isn't held for one bio with integrity prepared, so this request may be completed with calling profile->complete_fn, then kernel panic. Another constraint is that bio_integrity_prep() needs to be called before bio merge. Fix the issue by: - call bio_integrity_prep() with one queue usage counter grabbed reliably - call bio_integrity_prep() before bio merge
- https://git.kernel.org/stable/c/b0077e269f6c152e807fdac90b58caf012cdbaab
- https://git.kernel.org/stable/c/b5c8e0ff76d10f6bf70a7237678f27c20cf59bc9
- https://git.kernel.org/stable/c/b80056bd75a16e4550873ecefe12bc8fd190b1cf
- https://git.kernel.org/stable/c/e9c309ded295b7f8849097d71ae231456ca79f78
- https://git.kernel.org/stable/c/b0077e269f6c152e807fdac90b58caf012cdbaab
- https://git.kernel.org/stable/c/b5c8e0ff76d10f6bf70a7237678f27c20cf59bc9
- https://git.kernel.org/stable/c/b80056bd75a16e4550873ecefe12bc8fd190b1cf
- https://git.kernel.org/stable/c/e9c309ded295b7f8849097d71ae231456ca79f78
Modified: 2025-01-31
CVE-2023-52788
In the Linux kernel, the following vulnerability has been resolved: i915/perf: Fix NULL deref bugs with drm_dbg() calls When i915 perf interface is not available dereferencing it will lead to NULL dereferences. As returning -ENOTSUPP is pretty clear return when perf interface is not available. [tursulin: added stable tag] (cherry picked from commit 36f27350ff745bd228ab04d7845dfbffc177a889)
- https://git.kernel.org/stable/c/10f49cdfd5fb342a1a9641930dc040c570694e98
- https://git.kernel.org/stable/c/1566e8be73fd5fa424e88d2a4cffdc34f970f0e1
- https://git.kernel.org/stable/c/471aa951bf1206d3c10d0daa67005b8e4db4ff83
- https://git.kernel.org/stable/c/55db76caa782baa4a1bf02296e2773c38a524a3e
- https://git.kernel.org/stable/c/bf8e105030083e7b71591cdf437e464bcd8a0c09
- https://git.kernel.org/stable/c/10f49cdfd5fb342a1a9641930dc040c570694e98
- https://git.kernel.org/stable/c/1566e8be73fd5fa424e88d2a4cffdc34f970f0e1
- https://git.kernel.org/stable/c/471aa951bf1206d3c10d0daa67005b8e4db4ff83
- https://git.kernel.org/stable/c/55db76caa782baa4a1bf02296e2773c38a524a3e
- https://git.kernel.org/stable/c/bf8e105030083e7b71591cdf437e464bcd8a0c09
Modified: 2025-01-15
CVE-2023-52789
In the Linux kernel, the following vulnerability has been resolved: tty: vcc: Add check for kstrdup() in vcc_probe() Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3
- https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac
- https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9
- https://git.kernel.org/stable/c/4ef41a7f33ffe1a335e7db7e1564ddc6afad47cc
- https://git.kernel.org/stable/c/6c80f48912b5bd4965352d1a9a989e21743a4a06
- https://git.kernel.org/stable/c/7cebc86481bf16049e266f6774d90f2fd4f8d5d2
- https://git.kernel.org/stable/c/8f8771757b130383732195497e47fba2aba76d3a
- https://git.kernel.org/stable/c/909963e0c16778cec28efb1affc21558825f4200
- https://git.kernel.org/stable/c/d81ffb87aaa75f842cd7aa57091810353755b3e6
- https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3
- https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac
- https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9
- https://git.kernel.org/stable/c/4ef41a7f33ffe1a335e7db7e1564ddc6afad47cc
- https://git.kernel.org/stable/c/6c80f48912b5bd4965352d1a9a989e21743a4a06
- https://git.kernel.org/stable/c/7cebc86481bf16049e266f6774d90f2fd4f8d5d2
- https://git.kernel.org/stable/c/8f8771757b130383732195497e47fba2aba76d3a
- https://git.kernel.org/stable/c/909963e0c16778cec28efb1affc21558825f4200
- https://git.kernel.org/stable/c/d81ffb87aaa75f842cd7aa57091810353755b3e6
Modified: 2025-09-26
CVE-2023-52791
In the Linux kernel, the following vulnerability has been resolved: i2c: core: Run atomic i2c xfer when !preemptible Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in wait_for_completion() while waiting for the DMA). panic() calls preempt_disable_notrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like: [ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114 [ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70 ... [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c Use !preemptible() instead, which is basically the same check as pre-v5.2.
- https://git.kernel.org/stable/c/185f3617adc8fe45e40489b458f03911f0dec46c
- https://git.kernel.org/stable/c/25284c46b657f48c0f3880a2e0706c70d81182c0
- https://git.kernel.org/stable/c/25eb381a736e7ae39a4245ef5c96484eb1073809
- https://git.kernel.org/stable/c/3473cf43b9068b9dfef2f545f833f33c6a544b91
- https://git.kernel.org/stable/c/8c3fa52a46ff4d208cefb1a462ec94e0043a91e1
- https://git.kernel.org/stable/c/aa49c90894d06e18a1ee7c095edbd2f37c232d02
- https://git.kernel.org/stable/c/f6237afabc349c1c7909db00e15d2816519e0d2b
- https://git.kernel.org/stable/c/185f3617adc8fe45e40489b458f03911f0dec46c
- https://git.kernel.org/stable/c/25284c46b657f48c0f3880a2e0706c70d81182c0
- https://git.kernel.org/stable/c/25eb381a736e7ae39a4245ef5c96484eb1073809
- https://git.kernel.org/stable/c/3473cf43b9068b9dfef2f545f833f33c6a544b91
- https://git.kernel.org/stable/c/8c3fa52a46ff4d208cefb1a462ec94e0043a91e1
- https://git.kernel.org/stable/c/aa49c90894d06e18a1ee7c095edbd2f37c232d02
- https://git.kernel.org/stable/c/f6237afabc349c1c7909db00e15d2816519e0d2b
Modified: 2025-09-23
CVE-2023-52792
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Do not try to cleanup after cxl_region_setup_targets() fails Commit 5e42bcbc3fef ("cxl/region: decrement ->nr_targets on error in cxl_region_attach()") tried to avoid 'eiw' initialization errors when ->nr_targets exceeded 16, by just decrementing ->nr_targets when cxl_region_setup_targets() failed. Commit 86987c766276 ("cxl/region: Cleanup target list on attach error") extended that cleanup to also clear cxled->pos and p->targets[pos]. The initialization error was incidentally fixed separately by: Commit 8d4285425714 ("cxl/region: Fix port setup uninitialized variable warnings") which was merged a few days after 5e42bcbc3fef. But now the original cleanup when cxl_region_setup_targets() fails prevents endpoint and switch decoder resources from being reused: 1) the cleanup does not set the decoder's region to NULL, which results in future dpa_size_store() calls returning -EBUSY 2) the decoder is not properly freed, which results in future commit errors associated with the upstream switch Now that the initialization errors were fixed separately, the proper cleanup for this case is to just return immediately. Then the resources associated with this target get cleanup up as normal when the failed region is deleted. The ->nr_targets decrement in the error case also helped prevent a p->targets[] array overflow, so add a new check to prevent against that overflow. Tested by trying to create an invalid region for a 2 switch * 2 endpoint topology, and then following up with creating a valid region.
- https://git.kernel.org/stable/c/0718588c7aaa7a1510b4de972370535b61dddd0d
- https://git.kernel.org/stable/c/07ffcd8ec79cf7383e1e45815f4842fd357991c2
- https://git.kernel.org/stable/c/9090c5537c93cd0811ab7bfbd925b57addfffb60
- https://git.kernel.org/stable/c/90db4c1d5ebaf574d3c3065c055977982c378a83
- https://git.kernel.org/stable/c/0718588c7aaa7a1510b4de972370535b61dddd0d
- https://git.kernel.org/stable/c/07ffcd8ec79cf7383e1e45815f4842fd357991c2
- https://git.kernel.org/stable/c/9090c5537c93cd0811ab7bfbd925b57addfffb60
- https://git.kernel.org/stable/c/90db4c1d5ebaf574d3c3065c055977982c378a83
Modified: 2025-01-10
CVE-2023-52795
In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: fix use after free in vhost_vdpa_probe() The put_device() calls vhost_vdpa_release_dev() which calls ida_simple_remove() and frees "v". So this call to ida_simple_remove() is a use after free and a double free.
- https://git.kernel.org/stable/c/ae8ea4e200675a940c365b496ef8e3fb4123601c
- https://git.kernel.org/stable/c/bf04132cd64ccde4e9e9765d489c83fe83c09b7f
- https://git.kernel.org/stable/c/c0f8b8fb7df9d1a38652eb5aa817afccd3c56111
- https://git.kernel.org/stable/c/e07754e0a1ea2d63fb29574253d1fd7405607343
- https://git.kernel.org/stable/c/ae8ea4e200675a940c365b496ef8e3fb4123601c
- https://git.kernel.org/stable/c/bf04132cd64ccde4e9e9765d489c83fe83c09b7f
- https://git.kernel.org/stable/c/c0f8b8fb7df9d1a38652eb5aa817afccd3c56111
- https://git.kernel.org/stable/c/e07754e0a1ea2d63fb29574253d1fd7405607343
Modified: 2025-09-23
CVE-2023-52796
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: add ipvlan_route_v6_outbound() helper
Inspired by syzbot reports using a stack of multiple ipvlan devices.
Reduce stack size needed in ipvlan_process_v6_outbound() by moving
the flowi6 struct used for the route lookup in an non inlined
helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,
immediately reclaimed.
Also make sure ipvlan_process_v4_outbound() is not inlined.
We might also have to lower MAX_NEST_DEV, because only syzbot uses
setups with more than four stacked devices.
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)
stack guard page: 0000 [#1] SMP KASAN
CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188
Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89
RSP: 0018:ffffc9000e804000 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568
RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c
R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000
FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<#DF>#DF>
- https://git.kernel.org/stable/c/03cddc4df8c6be47fd27c8f8b87e5f9a989e1458
- https://git.kernel.org/stable/c/18f039428c7df183b09c69ebf10ffd4e521035d2
- https://git.kernel.org/stable/c/1f64cad3ac38ac5978b53c40e6c5e6fd3477c68f
- https://git.kernel.org/stable/c/43b781e7cb5cd0b435de276111953bf2bacd1f02
- https://git.kernel.org/stable/c/4d2d30f0792b47908af64c4d02ed1ee25ff50542
- https://git.kernel.org/stable/c/4f7f850611aa27aaaf1bf5687702ad2240ae442a
- https://git.kernel.org/stable/c/732a67ca436887b594ebc43bb5a04ffb0971a760
- https://git.kernel.org/stable/c/8872dc638c24bb774cd2224a69d72a7f661a4d56
- https://git.kernel.org/stable/c/03cddc4df8c6be47fd27c8f8b87e5f9a989e1458
- https://git.kernel.org/stable/c/18f039428c7df183b09c69ebf10ffd4e521035d2
- https://git.kernel.org/stable/c/1f64cad3ac38ac5978b53c40e6c5e6fd3477c68f
- https://git.kernel.org/stable/c/43b781e7cb5cd0b435de276111953bf2bacd1f02
- https://git.kernel.org/stable/c/4d2d30f0792b47908af64c4d02ed1ee25ff50542
- https://git.kernel.org/stable/c/4f7f850611aa27aaaf1bf5687702ad2240ae442a
- https://git.kernel.org/stable/c/732a67ca436887b594ebc43bb5a04ffb0971a760
- https://git.kernel.org/stable/c/8872dc638c24bb774cd2224a69d72a7f661a4d56
Modified: 2025-04-02
CVE-2023-52798
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix dfs radar event locking The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only.
- https://git.kernel.org/stable/c/1fd878e1750190a612b5de2af357cca422ec0822
- https://git.kernel.org/stable/c/21ebb0aba580d347e12f01ce5f6e75044427b3d5
- https://git.kernel.org/stable/c/3b6c14833165f689cc5928574ebafe52bbce5f1e
- https://git.kernel.org/stable/c/426e718ce9ba60013364a54233feee309356cb82
- https://git.kernel.org/stable/c/ca420ac4f9451f22347bae44b18ab47ba2c267ec
- https://git.kernel.org/stable/c/f882f51905517575c9f793a3dff567af90ef9a10
- https://git.kernel.org/stable/c/1fd878e1750190a612b5de2af357cca422ec0822
- https://git.kernel.org/stable/c/21ebb0aba580d347e12f01ce5f6e75044427b3d5
- https://git.kernel.org/stable/c/3b6c14833165f689cc5928574ebafe52bbce5f1e
- https://git.kernel.org/stable/c/426e718ce9ba60013364a54233feee309356cb82
- https://git.kernel.org/stable/c/ca420ac4f9451f22347bae44b18ab47ba2c267ec
- https://git.kernel.org/stable/c/f882f51905517575c9f793a3dff567af90ef9a10
Modified: 2025-03-06
CVE-2023-52799
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in dbFindLeaf Currently while searching for dmtree_t for sufficient free blocks there is an array out of bounds while getting element in tp->dm_stree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied.
- https://git.kernel.org/stable/c/20f9310a18e3e99fc031e036fcbed67105ae1859
- https://git.kernel.org/stable/c/22cad8bc1d36547cdae0eef316c47d917ce3147c
- https://git.kernel.org/stable/c/81aa58cd8495b8c3b527f58ccbe19478d8087f61
- https://git.kernel.org/stable/c/86df90f3fea7c5591f05c8a0010871d435e83046
- https://git.kernel.org/stable/c/87c681ab49e99039ff2dd3e71852417381b13878
- https://git.kernel.org/stable/c/88b7894a8f8705bf4e7ea90b10229376abf14514
- https://git.kernel.org/stable/c/a50b796d36719757526ee094c703378895ab5e67
- https://git.kernel.org/stable/c/da3da5e1e6f71c21d8e6149d7076d936ef5d4cb9
- https://git.kernel.org/stable/c/ecfb47f13b08b02cf28b7b50d4941eefa21954d2
- https://git.kernel.org/stable/c/20f9310a18e3e99fc031e036fcbed67105ae1859
- https://git.kernel.org/stable/c/22cad8bc1d36547cdae0eef316c47d917ce3147c
- https://git.kernel.org/stable/c/81aa58cd8495b8c3b527f58ccbe19478d8087f61
- https://git.kernel.org/stable/c/86df90f3fea7c5591f05c8a0010871d435e83046
- https://git.kernel.org/stable/c/87c681ab49e99039ff2dd3e71852417381b13878
- https://git.kernel.org/stable/c/88b7894a8f8705bf4e7ea90b10229376abf14514
- https://git.kernel.org/stable/c/a50b796d36719757526ee094c703378895ab5e67
- https://git.kernel.org/stable/c/da3da5e1e6f71c21d8e6149d7076d936ef5d4cb9
- https://git.kernel.org/stable/c/ecfb47f13b08b02cf28b7b50d4941eefa21954d2
Modified: 2025-04-02
CVE-2023-52800
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix htt pktlog locking The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only.
- https://git.kernel.org/stable/c/03ed26935bebf6b6fd8a656490bf3dcc71b72679
- https://git.kernel.org/stable/c/3a51e6b4da71fdfa43ec006d6abc020f3e22d14e
- https://git.kernel.org/stable/c/3f77c7d605b29df277d77e9ee75d96e7ad145d2d
- https://git.kernel.org/stable/c/423762f021825b5e57c3d6f01ff96a9ff19cdcd8
- https://git.kernel.org/stable/c/69cede2a5a5f60e3f5602b901b52cb64edd2ea6c
- https://git.kernel.org/stable/c/e3199b3fac65c9f103055390b6fd07c5cffa5961
- https://git.kernel.org/stable/c/03ed26935bebf6b6fd8a656490bf3dcc71b72679
- https://git.kernel.org/stable/c/3a51e6b4da71fdfa43ec006d6abc020f3e22d14e
- https://git.kernel.org/stable/c/3f77c7d605b29df277d77e9ee75d96e7ad145d2d
- https://git.kernel.org/stable/c/423762f021825b5e57c3d6f01ff96a9ff19cdcd8
- https://git.kernel.org/stable/c/69cede2a5a5f60e3f5602b901b52cb64edd2ea6c
- https://git.kernel.org/stable/c/e3199b3fac65c9f103055390b6fd07c5cffa5961
Modified: 2025-09-23
CVE-2023-52803
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix RPC client cleaned up the freed pipefs dentries RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir() workqueue,which takes care about pipefs superblock locking. In some special scenarios, when kernel frees the pipefs sb of the current client and immediately alloctes a new pipefs sb, rpc_remove_pipedir function would misjudge the existence of pipefs sb which is not the one it used to hold. As a result, the rpc_remove_pipedir would clean the released freed pipefs dentries. To fix this issue, rpc_remove_pipedir should check whether the current pipefs sb is consistent with the original pipefs sb. This error can be catched by KASAN: ========================================================= [ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200 [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503 [ 250.500549] Workqueue: events rpc_free_client_work [ 250.501001] Call Trace: [ 250.502880] kasan_report+0xb6/0xf0 [ 250.503209] ? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] rpc_free_client_work+0xe4/0x230 [ 250.505598] process_one_work+0x8ee/0x13b0 ... [ 22.039056] Allocated by task 244: [ 22.039390] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.040889] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ... [ 22.049524] Freed by task 0: [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] kasan_set_track+0x25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Last potentially related work creation: [ 22.052952] kasan_save_stack+0x22/0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ 22.054540] __dentry_kill+0x3be/0x540 [ 22.054900] shrink_dentry_list+0x199/0x510 [ 22.055293] shrink_dcache_parent+0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] kill_anon_super+0x3a/0x60 [ 22.057234] rpc_kill_sb+0x121/0x200
- https://git.kernel.org/stable/c/17866066b8ac1cc38fb449670bc15dc9fee4b40a
- https://git.kernel.org/stable/c/194454afa6aa9d6ed74f0c57127bc8beb27c20df
- https://git.kernel.org/stable/c/1cdb52ffd6600a37bd355d8dce58ecd03e55e618
- https://git.kernel.org/stable/c/7749fd2dbef72a52b5c9ffdbf877691950ed4680
- https://git.kernel.org/stable/c/7d61d1da2ed1f682c41cae0c8d4719cdaccee5c5
- https://git.kernel.org/stable/c/bfca5fb4e97c46503ddfc582335917b0cc228264
- https://git.kernel.org/stable/c/cc2e7ebbeb1d0601f7f3c8d93b78fcc03a95e44a
- https://git.kernel.org/stable/c/dedf2a0eb9448ae73b270743e6ea9b108189df46
- https://git.kernel.org/stable/c/17866066b8ac1cc38fb449670bc15dc9fee4b40a
- https://git.kernel.org/stable/c/194454afa6aa9d6ed74f0c57127bc8beb27c20df
- https://git.kernel.org/stable/c/1cdb52ffd6600a37bd355d8dce58ecd03e55e618
- https://git.kernel.org/stable/c/7749fd2dbef72a52b5c9ffdbf877691950ed4680
- https://git.kernel.org/stable/c/7d61d1da2ed1f682c41cae0c8d4719cdaccee5c5
- https://git.kernel.org/stable/c/bfca5fb4e97c46503ddfc582335917b0cc228264
- https://git.kernel.org/stable/c/cc2e7ebbeb1d0601f7f3c8d93b78fcc03a95e44a
- https://git.kernel.org/stable/c/dedf2a0eb9448ae73b270743e6ea9b108189df46
Modified: 2025-09-23
CVE-2023-52804
In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Add validity check for db_maxag and db_agpref Both db_maxag and db_agpref are used as the index of the db_agfree array, but there is currently no validity check for db_maxag and db_agpref, which can lead to errors. The following is related bug reported by Syzbot: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20 index 7936 is out of range for type 'atomic_t[128]' Add checking that the values of db_maxag and db_agpref are valid indexes for the db_agfree array.
- https://git.kernel.org/stable/c/1f74d336990f37703a8eee77153463d65b67f70e
- https://git.kernel.org/stable/c/2323de34a3ae61a9f9b544c18583f71cea86721f
- https://git.kernel.org/stable/c/32bd8f1cbcf8b663e29dd1f908ba3a129541a11b
- https://git.kernel.org/stable/c/5013f8269887642cca784adc8db9b5f0b771533f
- https://git.kernel.org/stable/c/64933ab7b04881c6c18b21ff206c12278341c72e
- https://git.kernel.org/stable/c/a0649e2dd4a3595b5595a29d0064d047c2fae2fb
- https://git.kernel.org/stable/c/c6c8863fb3f57700ab583d875adda04caaf2278a
- https://git.kernel.org/stable/c/ce15b0f1a431168f07b1cc6c9f71206a2db5c809
- https://git.kernel.org/stable/c/dca403bb035a565bb98ecc1dda5d30f676feda40
- https://git.kernel.org/stable/c/1f74d336990f37703a8eee77153463d65b67f70e
- https://git.kernel.org/stable/c/2323de34a3ae61a9f9b544c18583f71cea86721f
- https://git.kernel.org/stable/c/32bd8f1cbcf8b663e29dd1f908ba3a129541a11b
- https://git.kernel.org/stable/c/5013f8269887642cca784adc8db9b5f0b771533f
- https://git.kernel.org/stable/c/64933ab7b04881c6c18b21ff206c12278341c72e
- https://git.kernel.org/stable/c/a0649e2dd4a3595b5595a29d0064d047c2fae2fb
- https://git.kernel.org/stable/c/c6c8863fb3f57700ab583d875adda04caaf2278a
- https://git.kernel.org/stable/c/ce15b0f1a431168f07b1cc6c9f71206a2db5c809
- https://git.kernel.org/stable/c/dca403bb035a565bb98ecc1dda5d30f676feda40
Modified: 2025-10-01
CVE-2023-52805
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in diAlloc Currently there is not check against the agno of the iag while allocating new inodes to avoid fragmentation problem. Added the check which is required.
- https://git.kernel.org/stable/c/05d9ea1ceb62a55af6727a69269a4fd310edf483
- https://git.kernel.org/stable/c/1708d0a9917fea579cc9da3d87b154285abd2cd8
- https://git.kernel.org/stable/c/1ba7df5457dc1c1071c5f92ac11323533a6430e1
- https://git.kernel.org/stable/c/2308d0fb0dc32446b4e6ca37cd09c30374bb64e9
- https://git.kernel.org/stable/c/64f062baf202b82f54987a3f614a6c8f3e466641
- https://git.kernel.org/stable/c/665b44e55c2767a4f899c3b18f49e9e1c9983777
- https://git.kernel.org/stable/c/7467ca10a5ff09b0e87edf6c4d2a4bfdee69cf2c
- https://git.kernel.org/stable/c/8c68af2af697ba2ba3b138be0c6d72e2ce3a3d6d
- https://git.kernel.org/stable/c/cf7e3e84df36a9953796c737f080712f631d7083
- https://git.kernel.org/stable/c/05d9ea1ceb62a55af6727a69269a4fd310edf483
- https://git.kernel.org/stable/c/1708d0a9917fea579cc9da3d87b154285abd2cd8
- https://git.kernel.org/stable/c/1ba7df5457dc1c1071c5f92ac11323533a6430e1
- https://git.kernel.org/stable/c/2308d0fb0dc32446b4e6ca37cd09c30374bb64e9
- https://git.kernel.org/stable/c/64f062baf202b82f54987a3f614a6c8f3e466641
- https://git.kernel.org/stable/c/665b44e55c2767a4f899c3b18f49e9e1c9983777
- https://git.kernel.org/stable/c/7467ca10a5ff09b0e87edf6c4d2a4bfdee69cf2c
- https://git.kernel.org/stable/c/8c68af2af697ba2ba3b138be0c6d72e2ce3a3d6d
- https://git.kernel.org/stable/c/cf7e3e84df36a9953796c737f080712f631d7083
Modified: 2024-11-21
CVE-2023-52806
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix possible null-ptr-deref when assigning a stream While AudioDSP drivers assign streams exclusively of HOST or LINK type, nothing blocks a user to attempt to assign a COUPLED stream. As supplied substream instance may be a stub, what is the case when code-loading, such scenario ends with null-ptr-deref.
- https://git.kernel.org/stable/c/2527775616f3638f4fd54649eba8c7b84d5e4250
- https://git.kernel.org/stable/c/25354bae4fc310c3928e8a42fda2d486f67745d7
- https://git.kernel.org/stable/c/43b91df291c8802268ab3cfd8fccfdf135800ed4
- https://git.kernel.org/stable/c/4a320da7f7cbdab2098b103c47f45d5061f42edd
- https://git.kernel.org/stable/c/631a96e9eb4228ff75fce7e72d133ca81194797e
- https://git.kernel.org/stable/c/758c7733cb821041f5fd403b7b97c0b95d319323
- https://git.kernel.org/stable/c/7de25112de8222fd20564769e6c99dc9f9738a0b
- https://git.kernel.org/stable/c/f93dc90c2e8ed664985e366aa6459ac83cdab236
- https://git.kernel.org/stable/c/fe7c1a0c2b25c82807cb46fc3aadbf2664a682b0
- https://git.kernel.org/stable/c/2527775616f3638f4fd54649eba8c7b84d5e4250
- https://git.kernel.org/stable/c/25354bae4fc310c3928e8a42fda2d486f67745d7
- https://git.kernel.org/stable/c/43b91df291c8802268ab3cfd8fccfdf135800ed4
- https://git.kernel.org/stable/c/4a320da7f7cbdab2098b103c47f45d5061f42edd
- https://git.kernel.org/stable/c/631a96e9eb4228ff75fce7e72d133ca81194797e
- https://git.kernel.org/stable/c/758c7733cb821041f5fd403b7b97c0b95d319323
- https://git.kernel.org/stable/c/7de25112de8222fd20564769e6c99dc9f9738a0b
- https://git.kernel.org/stable/c/f93dc90c2e8ed664985e366aa6459ac83cdab236
- https://git.kernel.org/stable/c/fe7c1a0c2b25c82807cb46fc3aadbf2664a682b0
Modified: 2025-03-06
CVE-2023-52807
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs The hns3 driver define an array of string to show the coalesce info, but if the kernel adds a new mode or a new state, out-of-bounds access may occur when coalesce info is read via debugfs, this patch fix the problem.
- https://git.kernel.org/stable/c/07f5b8c47152cadbd9102e053dcb60685820aa09
- https://git.kernel.org/stable/c/53aba458f23846112c0d44239580ff59bc5c36c3
- https://git.kernel.org/stable/c/be1f703f39efa27b7371b9a4cd983317f1366792
- https://git.kernel.org/stable/c/f79d985c69060047426be68b7e4c1663d5d731b4
- https://git.kernel.org/stable/c/07f5b8c47152cadbd9102e053dcb60685820aa09
- https://git.kernel.org/stable/c/53aba458f23846112c0d44239580ff59bc5c36c3
- https://git.kernel.org/stable/c/be1f703f39efa27b7371b9a4cd983317f1366792
- https://git.kernel.org/stable/c/f79d985c69060047426be68b7e4c1663d5d731b4
Modified: 2025-01-14
CVE-2023-52808
In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs If init debugfs failed during device registration due to memory allocation failure, debugfs_remove_recursive() is called, after which debugfs_dir is not set to NULL. debugfs_remove_recursive() will be called again during device removal. As a result, illegal pointer is accessed. [ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs! ... [ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 1669.872669] pc : down_write+0x24/0x70 [ 1669.876315] lr : down_write+0x1c/0x70 [ 1669.879961] sp : ffff000036f53a30 [ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8 [ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000 [ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270 [ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8 [ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310 [ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10 [ 1669.914982] x17: 0000000000000000 x16: 0000000000000000 [ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870 [ 1669.925555] x13: 0000000000000040 x12: 0000000000000228 [ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0 [ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10 [ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff [ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00 [ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000 [ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001 [ 1669.962563] Call trace: [ 1669.965000] down_write+0x24/0x70 [ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0 [ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main] [ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw] [ 1669.984175] pci_device_remove+0x48/0xd8 [ 1669.988082] device_release_driver_internal+0x1b4/0x250 [ 1669.993282] device_release_driver+0x28/0x38 [ 1669.997534] pci_stop_bus_device+0x84/0xb8 [ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40 [ 1670.007244] remove_store+0xfc/0x140 [ 1670.010802] dev_attr_store+0x44/0x60 [ 1670.014448] sysfs_kf_write+0x58/0x80 [ 1670.018095] kernfs_fop_write+0xe8/0x1f0 [ 1670.022000] __vfs_write+0x60/0x190 [ 1670.025472] vfs_write+0xac/0x1c0 [ 1670.028771] ksys_write+0x6c/0xd8 [ 1670.032071] __arm64_sys_write+0x24/0x30 [ 1670.035977] el0_svc_common+0x78/0x130 [ 1670.039710] el0_svc_handler+0x38/0x78 [ 1670.043442] el0_svc+0x8/0xc To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().
- https://git.kernel.org/stable/c/33331b265aac9441ac0c1a5442e3f05d038240ec
- https://git.kernel.org/stable/c/6de426f9276c448e2db7238911c97fb157cb23be
- https://git.kernel.org/stable/c/75a2656260fe8c7eeabda6ff4600b29e183f48db
- https://git.kernel.org/stable/c/b4465009e7d60c6111946db4c8f1e50d401ed7be
- https://git.kernel.org/stable/c/f0bfc8a5561fb0b2c48183dcbfe00bdd6d973bd3
- https://git.kernel.org/stable/c/33331b265aac9441ac0c1a5442e3f05d038240ec
- https://git.kernel.org/stable/c/6de426f9276c448e2db7238911c97fb157cb23be
- https://git.kernel.org/stable/c/75a2656260fe8c7eeabda6ff4600b29e183f48db
- https://git.kernel.org/stable/c/b4465009e7d60c6111946db4c8f1e50d401ed7be
- https://git.kernel.org/stable/c/f0bfc8a5561fb0b2c48183dcbfe00bdd6d973bd3
Modified: 2024-11-21
CVE-2023-52809
In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup() fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed.
- https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba
- https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f
- https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b
- https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106
- https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa
- https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e
- https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00
- https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01
- https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34
- https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba
- https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f
- https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b
- https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106
- https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa
- https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e
- https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00
- https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01
- https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34
Modified: 2025-04-02
CVE-2023-52810
In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Add check for negative db_l2nbperpage l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative. In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent. Syzbot reported this bug: UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative
- https://git.kernel.org/stable/c/0cb567e727339a192f9fd0db00781d73a91d15a6
- https://git.kernel.org/stable/c/1a7c53fdea1d189087544d9a606d249e93c4934b
- https://git.kernel.org/stable/c/491085258185ffc4fb91555b0dba895fe7656a45
- https://git.kernel.org/stable/c/524b4f203afcf87accfe387e846f33f916f0c907
- https://git.kernel.org/stable/c/525b861a008143048535011f3816d407940f4bfa
- https://git.kernel.org/stable/c/5f148b16972e5f4592629b244d5109b15135f53f
- https://git.kernel.org/stable/c/8f2964df6bfce9d92d81ca552010b8677af8d9dc
- https://git.kernel.org/stable/c/a81a56b4cbe3142cc99f6b98e8f9b3a631c768e1
- https://git.kernel.org/stable/c/cc61fcf7d1c99f148fe8ddfb5c6ed0bb75861f01
- https://git.kernel.org/stable/c/0cb567e727339a192f9fd0db00781d73a91d15a6
- https://git.kernel.org/stable/c/1a7c53fdea1d189087544d9a606d249e93c4934b
- https://git.kernel.org/stable/c/491085258185ffc4fb91555b0dba895fe7656a45
- https://git.kernel.org/stable/c/524b4f203afcf87accfe387e846f33f916f0c907
- https://git.kernel.org/stable/c/525b861a008143048535011f3816d407940f4bfa
- https://git.kernel.org/stable/c/5f148b16972e5f4592629b244d5109b15135f53f
- https://git.kernel.org/stable/c/8f2964df6bfce9d92d81ca552010b8677af8d9dc
- https://git.kernel.org/stable/c/a81a56b4cbe3142cc99f6b98e8f9b3a631c768e1
- https://git.kernel.org/stable/c/cc61fcf7d1c99f148fe8ddfb5c6ed0bb75861f01
Modified: 2025-04-02
CVE-2023-52811
In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool In practice the driver should never send more commands than are allocated to a queue's event pool. In the unlikely event that this happens, the code asserts a BUG_ON, and in the case that the kernel is not configured to crash on panic returns a junk event pointer from the empty event list causing things to spiral from there. This BUG_ON is a historical artifact of the ibmvfc driver first being upstreamed, and it is well known now that the use of BUG_ON is bad practice except in the most unrecoverable scenario. There is nothing about this scenario that prevents the driver from recovering and carrying on. Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL pointer in the case of an empty event pool. Update all call sites to ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate failure or recovery action.
- https://git.kernel.org/stable/c/88984ec4792766df5a9de7a2ff2b5f281f94c7d4
- https://git.kernel.org/stable/c/8bbe784c2ff28d56ca0c548aaf3e584edc77052d
- https://git.kernel.org/stable/c/b39f2d10b86d0af353ea339e5815820026bca48f
- https://git.kernel.org/stable/c/d2af4ef80601224b90630c1ddc7cd2c7c8ab4dd8
- https://git.kernel.org/stable/c/e1d1f79b1929dce470a5dc9281c574cd58e8c6c0
- https://git.kernel.org/stable/c/88984ec4792766df5a9de7a2ff2b5f281f94c7d4
- https://git.kernel.org/stable/c/8bbe784c2ff28d56ca0c548aaf3e584edc77052d
- https://git.kernel.org/stable/c/b39f2d10b86d0af353ea339e5815820026bca48f
- https://git.kernel.org/stable/c/d2af4ef80601224b90630c1ddc7cd2c7c8ab4dd8
- https://git.kernel.org/stable/c/e1d1f79b1929dce470a5dc9281c574cd58e8c6c0
Modified: 2025-09-26
CVE-2023-52813
In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix hungtask for PADATA_RESET We found a hungtask bug in test_aead_vec_cfg as follows: INFO: task cryptomgr_test:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks For padata_do_parallel, when the return err is 0 or -EBUSY, it will call wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal case, aead_request_complete() will be called in pcrypt_aead_serial and the return err is 0 for padata_do_parallel. But, when pinst->flags is PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it won't call aead_request_complete(). Therefore, test_aead_vec_cfg will hung at wait_for_completion(&wait->completion), which will cause hungtask. The problem comes as following: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again. v3: remove retry and just change the return err. v2: introduce padata_try_do_parallel() in pcrypt_aead_encrypt and pcrypt_aead_decrypt to solve the hungtask.
- https://git.kernel.org/stable/c/039fec48e062504f14845124a1a25eb199b2ddc0
- https://git.kernel.org/stable/c/372636debe852913529b1716f44addd94fff2d28
- https://git.kernel.org/stable/c/546c1796ad1ed0d87dab3c4b5156d75819be2316
- https://git.kernel.org/stable/c/8f4f68e788c3a7a696546291258bfa5fdb215523
- https://git.kernel.org/stable/c/c55fc098fd9d2dca475b82d00ffbcaf97879d77e
- https://git.kernel.org/stable/c/c9c1334697301c10e6918d747ed38abfbc0c96e7
- https://git.kernel.org/stable/c/e134f3aba98e6c801a693f540912c2d493718ddf
- https://git.kernel.org/stable/c/e97bf4ada7dddacd184c3e196bd063b0dc71b41d
- https://git.kernel.org/stable/c/fb2d3a50a8f29a3c66682bb426144f40e32ab818
- https://git.kernel.org/stable/c/039fec48e062504f14845124a1a25eb199b2ddc0
- https://git.kernel.org/stable/c/372636debe852913529b1716f44addd94fff2d28
- https://git.kernel.org/stable/c/546c1796ad1ed0d87dab3c4b5156d75819be2316
- https://git.kernel.org/stable/c/8f4f68e788c3a7a696546291258bfa5fdb215523
- https://git.kernel.org/stable/c/c55fc098fd9d2dca475b82d00ffbcaf97879d77e
- https://git.kernel.org/stable/c/c9c1334697301c10e6918d747ed38abfbc0c96e7
- https://git.kernel.org/stable/c/e134f3aba98e6c801a693f540912c2d493718ddf
- https://git.kernel.org/stable/c/e97bf4ada7dddacd184c3e196bd063b0dc71b41d
- https://git.kernel.org/stable/c/fb2d3a50a8f29a3c66682bb426144f40e32ab818
Modified: 2025-09-16
CVE-2023-52814
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential null pointer derefernce The amdgpu_ras_get_context may return NULL if device not support ras feature, so add check before using.
- https://git.kernel.org/stable/c/80285ae1ec8717b597b20de38866c29d84d321a1
- https://git.kernel.org/stable/c/9b70fc7d70e8ef7c4a65034c9487f58609e708a1
- https://git.kernel.org/stable/c/b0702ee4d811708251cdf54d4a1d3e888d365111
- https://git.kernel.org/stable/c/b93a25de28af153312f0fc979b0663fc4bd3442b
- https://git.kernel.org/stable/c/c11cf5e117f50f5a767054600885acd981449afe
- https://git.kernel.org/stable/c/da46e63482fdc5e35c008865c22ac64027f6f0c2
- https://git.kernel.org/stable/c/80285ae1ec8717b597b20de38866c29d84d321a1
- https://git.kernel.org/stable/c/9b70fc7d70e8ef7c4a65034c9487f58609e708a1
- https://git.kernel.org/stable/c/b0702ee4d811708251cdf54d4a1d3e888d365111
- https://git.kernel.org/stable/c/b93a25de28af153312f0fc979b0663fc4bd3442b
- https://git.kernel.org/stable/c/c11cf5e117f50f5a767054600885acd981449afe
- https://git.kernel.org/stable/c/da46e63482fdc5e35c008865c22ac64027f6f0c2
Modified: 2024-11-21
CVE-2023-52815
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vkms: fix a possible null pointer dereference In amdgpu_vkms_conn_get_modes(), the return value of drm_cvt_mode() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_cvt_mode(). Add a check to avoid null pointer dereference.
- https://git.kernel.org/stable/c/33fb1a555354bd593f785935ddcb5d9dd4d3847f
- https://git.kernel.org/stable/c/70f831f21155c692bb336c434936fd6f24f3f81a
- https://git.kernel.org/stable/c/8c6c85a073768df68c1a3fea143d013a38c66d34
- https://git.kernel.org/stable/c/cd90511557fdfb394bb4ac4c3b539b007383914c
- https://git.kernel.org/stable/c/eaa03ea366c85ae3cb69c8d4bbc67c8bc2167a27
- https://git.kernel.org/stable/c/33fb1a555354bd593f785935ddcb5d9dd4d3847f
- https://git.kernel.org/stable/c/70f831f21155c692bb336c434936fd6f24f3f81a
- https://git.kernel.org/stable/c/8c6c85a073768df68c1a3fea143d013a38c66d34
- https://git.kernel.org/stable/c/cd90511557fdfb394bb4ac4c3b539b007383914c
- https://git.kernel.org/stable/c/eaa03ea366c85ae3cb69c8d4bbc67c8bc2167a27
Modified: 2025-09-23
CVE-2023-52816
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix shift out-of-bounds issue
[ 567.613292] shift exponent 255 is too large for 64-bit type 'long unsigned int'
[ 567.614498] CPU: 5 PID: 238 Comm: kworker/5:1 Tainted: G OE 6.2.0-34-generic #34~22.04.1-Ubuntu
[ 567.614502] Hardware name: AMD Splinter/Splinter-RPL, BIOS WS43927N_871 09/25/2023
[ 567.614504] Workqueue: events send_exception_work_handler [amdgpu]
[ 567.614748] Call Trace:
[ 567.614750]
- https://git.kernel.org/stable/c/2806f880379232e789957c2078d612669eb7a69c
- https://git.kernel.org/stable/c/282c1d793076c2edac6c3db51b7e8ed2b41d60a5
- https://git.kernel.org/stable/c/3f7a400d5e80f99581e3e8a9843e1f6118bf454f
- https://git.kernel.org/stable/c/56649c43d40ce0147465a2d5756d300e87f9ee1c
- https://git.kernel.org/stable/c/d33a35b13cbfec3238043f196fa87a6384f9d087
- https://git.kernel.org/stable/c/2806f880379232e789957c2078d612669eb7a69c
- https://git.kernel.org/stable/c/282c1d793076c2edac6c3db51b7e8ed2b41d60a5
- https://git.kernel.org/stable/c/3f7a400d5e80f99581e3e8a9843e1f6118bf454f
- https://git.kernel.org/stable/c/56649c43d40ce0147465a2d5756d300e87f9ee1c
- https://git.kernel.org/stable/c/d33a35b13cbfec3238043f196fa87a6384f9d087
Modified: 2025-09-16
CVE-2023-52817
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:
1. Navigate to the directory: /sys/kernel/debug/dri/0
2. Execute command: cat amdgpu_regs_smc
3. Exception Log::
[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000
[4005007.702562] #PF: supervisor instruction fetch in kernel mode
[4005007.702567] #PF: error_code(0x0010) - not-present page
[4005007.702570] PGD 0 P4D 0
[4005007.702576] Oops: 0010 [#1] SMP NOPTI
[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u
[4005007.702590] RIP: 0010:0x0
[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206
[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68
[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000
[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980
[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000
[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000
[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000
[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0
[4005007.702633] Call Trace:
[4005007.702636]
- https://git.kernel.org/stable/c/174f62a0aa15c211e60208b41ee9e7cdfb73d455
- https://git.kernel.org/stable/c/437e0fa907ba39b4d7eda863c03ea9cf48bd93a9
- https://git.kernel.org/stable/c/5104fdf50d326db2c1a994f8b35dcd46e63ae4ad
- https://git.kernel.org/stable/c/6c1b3d89a2dda79881726bb6e37af19c0936d736
- https://git.kernel.org/stable/c/820daf9ffe2b0afb804567b10983fb38bc5ae288
- https://git.kernel.org/stable/c/ba3c0796d292de84f2932cc5bbb0f771fc720996
- https://git.kernel.org/stable/c/bf2d51eedf03bd61e3556e35d74d49e2e6112398
- https://git.kernel.org/stable/c/f475d5502f33a6c5b149b0afe96316ad1962a64a
- https://git.kernel.org/stable/c/174f62a0aa15c211e60208b41ee9e7cdfb73d455
- https://git.kernel.org/stable/c/437e0fa907ba39b4d7eda863c03ea9cf48bd93a9
- https://git.kernel.org/stable/c/5104fdf50d326db2c1a994f8b35dcd46e63ae4ad
- https://git.kernel.org/stable/c/6c1b3d89a2dda79881726bb6e37af19c0936d736
- https://git.kernel.org/stable/c/820daf9ffe2b0afb804567b10983fb38bc5ae288
- https://git.kernel.org/stable/c/ba3c0796d292de84f2932cc5bbb0f771fc720996
- https://git.kernel.org/stable/c/bf2d51eedf03bd61e3556e35d74d49e2e6112398
- https://git.kernel.org/stable/c/f475d5502f33a6c5b149b0afe96316ad1962a64a
Modified: 2024-12-30
CVE-2023-52818
In the Linux kernel, the following vulnerability has been resolved: drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7 For pptable structs that use flexible array sizes, use flexible arrays.
- https://git.kernel.org/stable/c/6dffdddfca818c02a42b6caa1d9845995f0a1f94
- https://git.kernel.org/stable/c/760efbca74a405dc439a013a5efaa9fadc95a8c3
- https://git.kernel.org/stable/c/8af28ae3acb736ada4ce3457662fa446cc913bb4
- https://git.kernel.org/stable/c/92a775e7c9707aed28782bafe636bf87675f5a97
- https://git.kernel.org/stable/c/acdb6830de02cf2873aeaccdf2d9bca4aee50e47
- https://git.kernel.org/stable/c/c847379a5d00078ad6fcb1c24230e72c5609342f
- https://git.kernel.org/stable/c/cfd8cd907fd94538561479a43aea455f5cf16928
- https://git.kernel.org/stable/c/e52e324a21341c97350d5f11de14721c1c609498
- https://git.kernel.org/stable/c/fc9ac0e8e0bcb3740c6eaad3a1a50c20016d422b
- https://git.kernel.org/stable/c/6dffdddfca818c02a42b6caa1d9845995f0a1f94
- https://git.kernel.org/stable/c/760efbca74a405dc439a013a5efaa9fadc95a8c3
- https://git.kernel.org/stable/c/8af28ae3acb736ada4ce3457662fa446cc913bb4
- https://git.kernel.org/stable/c/92a775e7c9707aed28782bafe636bf87675f5a97
- https://git.kernel.org/stable/c/acdb6830de02cf2873aeaccdf2d9bca4aee50e47
- https://git.kernel.org/stable/c/c847379a5d00078ad6fcb1c24230e72c5609342f
- https://git.kernel.org/stable/c/cfd8cd907fd94538561479a43aea455f5cf16928
- https://git.kernel.org/stable/c/e52e324a21341c97350d5f11de14721c1c609498
- https://git.kernel.org/stable/c/fc9ac0e8e0bcb3740c6eaad3a1a50c20016d422b
Modified: 2025-04-02
CVE-2023-52819
In the Linux kernel, the following vulnerability has been resolved: drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga For pptable structs that use flexible array sizes, use flexible arrays.
- https://git.kernel.org/stable/c/0f0e59075b5c22f1e871fbd508d6e4f495048356
- https://git.kernel.org/stable/c/60a00dfc7c5deafd1dd393beaf53224f7256dad6
- https://git.kernel.org/stable/c/7c68283f3166221af3df5791f0e13d3137a72216
- https://git.kernel.org/stable/c/8c1dbddbfcb051e82cea0c197c620f9dcdc38e92
- https://git.kernel.org/stable/c/a237675aa1e62bbfaa341c535331c8656a508fa1
- https://git.kernel.org/stable/c/a63fd579e7b1c3a9ebd6e6c494d49b1b6cf5515e
- https://git.kernel.org/stable/c/b3b8b7c040cf069da7afe11c5bd73b870b8f3d18
- https://git.kernel.org/stable/c/d0725232da777840703f5f1e22f2e3081d712aa4
- https://git.kernel.org/stable/c/d50a56749e5afdc63491b88f5153c1aae00d4679
- https://git.kernel.org/stable/c/0f0e59075b5c22f1e871fbd508d6e4f495048356
- https://git.kernel.org/stable/c/60a00dfc7c5deafd1dd393beaf53224f7256dad6
- https://git.kernel.org/stable/c/7c68283f3166221af3df5791f0e13d3137a72216
- https://git.kernel.org/stable/c/8c1dbddbfcb051e82cea0c197c620f9dcdc38e92
- https://git.kernel.org/stable/c/a237675aa1e62bbfaa341c535331c8656a508fa1
- https://git.kernel.org/stable/c/a63fd579e7b1c3a9ebd6e6c494d49b1b6cf5515e
- https://git.kernel.org/stable/c/b3b8b7c040cf069da7afe11c5bd73b870b8f3d18
- https://git.kernel.org/stable/c/d0725232da777840703f5f1e22f2e3081d712aa4
- https://git.kernel.org/stable/c/d50a56749e5afdc63491b88f5153c1aae00d4679
Modified: 2024-11-21
CVE-2023-52821
In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
- https://git.kernel.org/stable/c/2381f6b628b3214f07375e0adf5ce17093c31190
- https://git.kernel.org/stable/c/4fa930ba046d20fc1899770396ee11e905fa96e4
- https://git.kernel.org/stable/c/79813cd59398015867d51e6d7dcc14d287d4c402
- https://git.kernel.org/stable/c/8a9dd36fcb4f3906982b82593393578db4479992
- https://git.kernel.org/stable/c/924e5814d1f84e6fa5cb19c6eceb69f066225229
- https://git.kernel.org/stable/c/c7dc0aca5962fb37dbea9769dd26ec37813faae1
- https://git.kernel.org/stable/c/2381f6b628b3214f07375e0adf5ce17093c31190
- https://git.kernel.org/stable/c/4fa930ba046d20fc1899770396ee11e905fa96e4
- https://git.kernel.org/stable/c/79813cd59398015867d51e6d7dcc14d287d4c402
- https://git.kernel.org/stable/c/8a9dd36fcb4f3906982b82593393578db4479992
- https://git.kernel.org/stable/c/924e5814d1f84e6fa5cb19c6eceb69f066225229
- https://git.kernel.org/stable/c/c7dc0aca5962fb37dbea9769dd26ec37813faae1
Modified: 2025-04-02
CVE-2023-52825
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix a race condition of vram buffer unref in svm code prange->svm_bo unref can happen in both mmu callback and a callback after migrate to system ram. Both are async call in different tasks. Sync svm_bo unref operation to avoid random "use-after-free".
- https://git.kernel.org/stable/c/50f35a907c4f9ed431fd3dbb8b871ef1cbb0718e
- https://git.kernel.org/stable/c/709c348261618da7ed89d6c303e2ceb9e453ba74
- https://git.kernel.org/stable/c/7d43cdd22cd81a2b079e864c4321b9aba4c6af34
- https://git.kernel.org/stable/c/c772eacbd6d0845fc922af8716bb9d29ae27b8cf
- https://git.kernel.org/stable/c/fc0210720127cc6302e6d6f3de48f49c3fcf5659
- https://git.kernel.org/stable/c/50f35a907c4f9ed431fd3dbb8b871ef1cbb0718e
- https://git.kernel.org/stable/c/709c348261618da7ed89d6c303e2ceb9e453ba74
- https://git.kernel.org/stable/c/7d43cdd22cd81a2b079e864c4321b9aba4c6af34
- https://git.kernel.org/stable/c/c772eacbd6d0845fc922af8716bb9d29ae27b8cf
- https://git.kernel.org/stable/c/fc0210720127cc6302e6d6f3de48f49c3fcf5659
Modified: 2024-12-30
CVE-2023-52826
In the Linux kernel, the following vulnerability has been resolved: drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference In tpg110_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
- https://git.kernel.org/stable/c/84c923d898905187ebfd4c0ef38cd1450af7e0ea
- https://git.kernel.org/stable/c/9268bfd76bebc85ff221691b61498cc16d75451c
- https://git.kernel.org/stable/c/9acc2bc00135e9ecd13a70ce1140e2673e504cdc
- https://git.kernel.org/stable/c/d0bc9ab0a161a9745273f5bf723733a8e6c57aca
- https://git.kernel.org/stable/c/eaede6900c0961b072669d6bd97fe8f90ed1900f
- https://git.kernel.org/stable/c/f22def5970c423ea7f87d5247bd0ef91416b0658
- https://git.kernel.org/stable/c/84c923d898905187ebfd4c0ef38cd1450af7e0ea
- https://git.kernel.org/stable/c/9268bfd76bebc85ff221691b61498cc16d75451c
- https://git.kernel.org/stable/c/9acc2bc00135e9ecd13a70ce1140e2673e504cdc
- https://git.kernel.org/stable/c/d0bc9ab0a161a9745273f5bf723733a8e6c57aca
- https://git.kernel.org/stable/c/eaede6900c0961b072669d6bd97fe8f90ed1900f
- https://git.kernel.org/stable/c/f22def5970c423ea7f87d5247bd0ef91416b0658
Modified: 2025-09-26
CVE-2023-52828
In the Linux kernel, the following vulnerability has been resolved: bpf: Detect IP == ksym.end as part of BPF program Now that bpf_throw kfunc is the first such call instruction that has noreturn semantics within the verifier, this also kicks in dead code elimination in unprecedented ways. For one, any instruction following a bpf_throw call will never be marked as seen. Moreover, if a callchain ends up throwing, any instructions after the call instruction to the eventually throwing subprog in callers will also never be marked as seen. The tempting way to fix this would be to emit extra 'int3' instructions which bump the jited_len of a program, and ensure that during runtime when a program throws, we can discover its boundaries even if the call instruction to bpf_throw (or to subprogs that always throw) is emitted as the final instruction in the program. An example of such a program would be this: do_something(): ... r0 = 0 exit foo(): r1 = 0 call bpf_throw r0 = 0 exit bar(cond): if r1 != 0 goto pc+2 call do_something exit call foo r0 = 0 // Never seen by verifier exit // main(ctx): r1 = ... call bar r0 = 0 exit Here, if we do end up throwing, the stacktrace would be the following: bpf_throw foo bar main In bar, the final instruction emitted will be the call to foo, as such, the return address will be the subsequent instruction (which the JIT emits as int3 on x86). This will end up lying outside the jited_len of the program, thus, when unwinding, we will fail to discover the return address as belonging to any program and end up in a panic due to the unreliable stack unwinding of BPF programs that we never expect. To remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as part of the BPF program, so that is_bpf_text_address returns true when such a case occurs, and we are able to unwind reliably when the final instruction ends up being a call instruction.
- https://git.kernel.org/stable/c/327b92e8cb527ae097961ffd1610c720481947f5
- https://git.kernel.org/stable/c/6058e4829696412457729a00734969acc6fd1d18
- https://git.kernel.org/stable/c/66d9111f3517f85ef2af0337ece02683ce0faf21
- https://git.kernel.org/stable/c/821a7e4143af115b840ec199eb179537e18af922
- https://git.kernel.org/stable/c/aa42a7cb92647786719fe9608685da345883878f
- https://git.kernel.org/stable/c/cf353904a82873e952633fcac4385c2fcd3a46e1
- https://git.kernel.org/stable/c/327b92e8cb527ae097961ffd1610c720481947f5
- https://git.kernel.org/stable/c/6058e4829696412457729a00734969acc6fd1d18
- https://git.kernel.org/stable/c/66d9111f3517f85ef2af0337ece02683ce0faf21
- https://git.kernel.org/stable/c/821a7e4143af115b840ec199eb179537e18af922
- https://git.kernel.org/stable/c/aa42a7cb92647786719fe9608685da345883878f
- https://git.kernel.org/stable/c/cf353904a82873e952633fcac4385c2fcd3a46e1
Modified: 2025-09-23
CVE-2023-52831
In the Linux kernel, the following vulnerability has been resolved: cpu/hotplug: Don't offline the last non-isolated CPU If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARN_ON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partition_sched_domains_locked(). cpuset_hotplug_workfn() rebuild_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN)); Thus results in an empty CPU mask which triggers the warning and then the subsequent crash: WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Call trace: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+0x234/0x880 rebuild_sched_domains_locked+0x37c/0x798 rebuild_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930 Unable to handle kernel paging request at virtual address fffe80027ab37080 partition_sched_domains_locked+0x318/0x880 rebuild_sched_domains_locked+0x37c/0x798 Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU. Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue.
- https://git.kernel.org/stable/c/3073f6df783d9d75f7f69f73e16c7ef85d6cfb63
- https://git.kernel.org/stable/c/335a47ed71e332c82339d1aec0c7f6caccfcda13
- https://git.kernel.org/stable/c/3410b702354702b500bde10e3cc1f9db8731d908
- https://git.kernel.org/stable/c/38685e2a0476127db766f81b1c06019ddc4c9ffa
- https://git.kernel.org/stable/c/3073f6df783d9d75f7f69f73e16c7ef85d6cfb63
- https://git.kernel.org/stable/c/335a47ed71e332c82339d1aec0c7f6caccfcda13
- https://git.kernel.org/stable/c/3410b702354702b500bde10e3cc1f9db8731d908
- https://git.kernel.org/stable/c/38685e2a0476127db766f81b1c06019ddc4c9ffa
Modified: 2026-01-05
CVE-2023-52832
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't return unset power in ieee80211_get_tx_power() We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level". UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] In this case, simply return an error instead, to indicate that no data is available.
- https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846
- https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6
- https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd671fe87c7
- https://git.kernel.org/stable/c/717de20abdcd1d4993fa450e28b8086a352620ea
- https://git.kernel.org/stable/c/adc2474d823fe81d8da759207f4f1d3691aa775a
- https://git.kernel.org/stable/c/e160ab85166e77347d0cbe5149045cb25e83937f
- https://git.kernel.org/stable/c/1571120c44dbe5757aee1612c5b6097cdc42710f
- https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846
- https://git.kernel.org/stable/c/298e767362cade639b7121ecb3cc5345b6529f62
- https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6
- https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd671fe87c7
- https://git.kernel.org/stable/c/717de20abdcd1d4993fa450e28b8086a352620ea
- https://git.kernel.org/stable/c/adc2474d823fe81d8da759207f4f1d3691aa775a
- https://git.kernel.org/stable/c/e160ab85166e77347d0cbe5149045cb25e83937f
- https://git.kernel.org/stable/c/efeae5f4972f75d50002bc50eb112ab9e7069b18
Modified: 2024-12-31
CVE-2023-52833
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: Add date->evt_skb is NULL check fix crash because of null pointers [ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 6104.969667] #PF: supervisor read access in kernel mode [ 6104.969668] #PF: error_code(0x0000) - not-present page [ 6104.969670] PGD 0 P4D 0 [ 6104.969673] Oops: 0000 [#1] SMP NOPTI [ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006 [ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] PKRU: 55555554 [ 6104.969702] Call Trace: [ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb] [ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth] [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth] [ 6104.969753] rfkill_set_block+0x92/0x160 [ 6104.969755] rfkill_fop_write+0x136/0x1e0 [ 6104.969759] __vfs_write+0x18/0x40 [ 6104.969761] vfs_write+0xdf/0x1c0 [ 6104.969763] ksys_write+0xb1/0xe0 [ 6104.969765] __x64_sys_write+0x1a/0x20 [ 6104.969769] do_syscall_64+0x51/0x180 [ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017 [ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0
- https://git.kernel.org/stable/c/0048ddf045bddc4dacb3e783fd869a2f8fb5be30
- https://git.kernel.org/stable/c/13b1ebad4c175e6a9b0748acbf133c21a15d282a
- https://git.kernel.org/stable/c/624820f7c8826dd010e8b1963303c145f99816e9
- https://git.kernel.org/stable/c/9f8e4d1a4ca1179aaeb43f91f3e2a386e7e616b3
- https://git.kernel.org/stable/c/a556f2ef556a04790f67f2fa272f1a77336d15a0
- https://git.kernel.org/stable/c/f9de14bde56dcbb0765284c6dfc35842b021733c
- https://git.kernel.org/stable/c/0048ddf045bddc4dacb3e783fd869a2f8fb5be30
- https://git.kernel.org/stable/c/13b1ebad4c175e6a9b0748acbf133c21a15d282a
- https://git.kernel.org/stable/c/624820f7c8826dd010e8b1963303c145f99816e9
- https://git.kernel.org/stable/c/9f8e4d1a4ca1179aaeb43f91f3e2a386e7e616b3
- https://git.kernel.org/stable/c/a556f2ef556a04790f67f2fa272f1a77336d15a0
- https://git.kernel.org/stable/c/f9de14bde56dcbb0765284c6dfc35842b021733c
Modified: 2025-09-26
CVE-2023-52834
In the Linux kernel, the following vulnerability has been resolved: atl1c: Work around the DMA RX overflow issue This is based on alx driver commit 881d0327db37 ("net: alx: Work around the DMA RX overflow issue"). The alx and atl1c drivers had RX overflow error which was why a custom allocator was created to avoid certain addresses. The simpler workaround then created for alx driver, but not for atl1c due to lack of tester. Instead of using a custom allocator, check the allocated skb address and use skb_reserve() to move away from problematic 0x...fc0 address. Tested on AR8131 on Acer 4540.
- https://git.kernel.org/stable/c/32f08b7b430ee01ec47d730f961a3306c1c7b6fb
- https://git.kernel.org/stable/c/54a6152da4993ec8e4b53dc3cf577f5a2c829afa
- https://git.kernel.org/stable/c/57e44ff9c2c9747b2b1a53556810b0e5192655d6
- https://git.kernel.org/stable/c/86565682e9053e5deb128193ea9e88531bbae9cf
- https://git.kernel.org/stable/c/c29a89b23f67ee592f4dee61f9d7efbf86d60315
- https://git.kernel.org/stable/c/32f08b7b430ee01ec47d730f961a3306c1c7b6fb
- https://git.kernel.org/stable/c/54a6152da4993ec8e4b53dc3cf577f5a2c829afa
- https://git.kernel.org/stable/c/57e44ff9c2c9747b2b1a53556810b0e5192655d6
- https://git.kernel.org/stable/c/86565682e9053e5deb128193ea9e88531bbae9cf
- https://git.kernel.org/stable/c/c29a89b23f67ee592f4dee61f9d7efbf86d60315
Modified: 2025-09-23
CVE-2023-52835
In the Linux kernel, the following vulnerability has been resolved: perf/core: Bail out early if the request AUX area is out of bound When perf-record with a large AUX area, e.g 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory) and it reveals a WARNING with __alloc_pages(): ------------[ cut here ]------------ WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Call trace: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 __arm64_sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING. So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory)
- https://git.kernel.org/stable/c/1a2a4202c60fcdffbf04f259002ce9bff39edece
- https://git.kernel.org/stable/c/2424410f94a94d91230ced094062d859714c984a
- https://git.kernel.org/stable/c/2e905e608e38cf7f8dcddcf8a6036e91a78444cb
- https://git.kernel.org/stable/c/54aee5f15b83437f23b2b2469bcf21bdd9823916
- https://git.kernel.org/stable/c/788c0b3442ead737008934947730a6d1ff703734
- https://git.kernel.org/stable/c/8c504f615d7ed60ae035c51d0c789137ced6797f
- https://git.kernel.org/stable/c/9ce4e87a8efd37c85766ec08b15e885cab08553a
- https://git.kernel.org/stable/c/fd0df3f8719201dbe61a4d39083d5aecd705399a
- https://git.kernel.org/stable/c/1a2a4202c60fcdffbf04f259002ce9bff39edece
- https://git.kernel.org/stable/c/2424410f94a94d91230ced094062d859714c984a
- https://git.kernel.org/stable/c/2e905e608e38cf7f8dcddcf8a6036e91a78444cb
- https://git.kernel.org/stable/c/54aee5f15b83437f23b2b2469bcf21bdd9823916
- https://git.kernel.org/stable/c/788c0b3442ead737008934947730a6d1ff703734
- https://git.kernel.org/stable/c/8c504f615d7ed60ae035c51d0c789137ced6797f
- https://git.kernel.org/stable/c/9ce4e87a8efd37c85766ec08b15e885cab08553a
- https://git.kernel.org/stable/c/fd0df3f8719201dbe61a4d39083d5aecd705399a
Modified: 2025-09-23
CVE-2023-52836
In the Linux kernel, the following vulnerability has been resolved: locking/ww_mutex/test: Fix potential workqueue corruption In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished. Often this would cause strange crashes as the mutexes would be freed while they were being used. Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them. Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting. It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely. So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns.
- https://git.kernel.org/stable/c/304a2c4aad0fff887ce493e4197bf9cbaf394479
- https://git.kernel.org/stable/c/9ed2d68b3925145f5f51c46559484881d6082f75
- https://git.kernel.org/stable/c/bccdd808902f8c677317cec47c306e42b93b849e
- https://git.kernel.org/stable/c/c56df79d68677cf062da1b6e3b33e74299a92dfc
- https://git.kernel.org/stable/c/d4d37c9e6a4dbcca958dabd99216550525c7e389
- https://git.kernel.org/stable/c/d8267cabbe1bed15ccf8b0e684c528bf8eeef715
- https://git.kernel.org/stable/c/dcd85e3c929368076a7592b27f541e0da8b427f5
- https://git.kernel.org/stable/c/e36407713163363e65566e7af0abe207d5f59a0c
- https://git.kernel.org/stable/c/e89d0ed45a419c485bae999426ecf92697cbdda3
- https://git.kernel.org/stable/c/304a2c4aad0fff887ce493e4197bf9cbaf394479
- https://git.kernel.org/stable/c/9ed2d68b3925145f5f51c46559484881d6082f75
- https://git.kernel.org/stable/c/bccdd808902f8c677317cec47c306e42b93b849e
- https://git.kernel.org/stable/c/c56df79d68677cf062da1b6e3b33e74299a92dfc
- https://git.kernel.org/stable/c/d4d37c9e6a4dbcca958dabd99216550525c7e389
- https://git.kernel.org/stable/c/d8267cabbe1bed15ccf8b0e684c528bf8eeef715
- https://git.kernel.org/stable/c/dcd85e3c929368076a7592b27f541e0da8b427f5
- https://git.kernel.org/stable/c/e36407713163363e65566e7af0abe207d5f59a0c
- https://git.kernel.org/stable/c/e89d0ed45a419c485bae999426ecf92697cbdda3
Modified: 2025-01-15
CVE-2023-52837
In the Linux kernel, the following vulnerability has been resolved: nbd: fix uaf in nbd_open Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set disk->private_data as NULL as before. UAF may be triggered in nbd_open() if someone tries to open nbd device right after nbd_put() since nbd has been free in nbd_dev_remove(). Fix this by implementing ->free_disk and free private data in it.
- https://git.kernel.org/stable/c/327462725b0f759f093788dfbcb2f1fd132f956b
- https://git.kernel.org/stable/c/4e9b3ec84dc97909876641dad14e0a2300d6c2a3
- https://git.kernel.org/stable/c/56bd7901b5e9dbc9112036ea615ebcba1565fafe
- https://git.kernel.org/stable/c/879947f4180bc6e83af64eb0515e0cf57fce15db
- https://git.kernel.org/stable/c/327462725b0f759f093788dfbcb2f1fd132f956b
- https://git.kernel.org/stable/c/4e9b3ec84dc97909876641dad14e0a2300d6c2a3
- https://git.kernel.org/stable/c/56bd7901b5e9dbc9112036ea615ebcba1565fafe
- https://git.kernel.org/stable/c/879947f4180bc6e83af64eb0515e0cf57fce15db
Modified: 2024-12-31
CVE-2023-52840
In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix use after free in rmi_unregister_function() The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this.
- https://git.kernel.org/stable/c/2f236d8638f5b43e0c72919a6a27fe286c32053f
- https://git.kernel.org/stable/c/303766bb92c5c225cf40f9bbbe7e29749406e2f2
- https://git.kernel.org/stable/c/50d12253666195a14c6cd2b81c376e2dbeedbdff
- https://git.kernel.org/stable/c/6c71e065befb2fae8f1461559b940c04e1071bd5
- https://git.kernel.org/stable/c/7082b1fb5321037bc11ba1cf2d7ed23c6b2b521f
- https://git.kernel.org/stable/c/c8e639f5743cf4b01f8c65e0df075fe4d782b585
- https://git.kernel.org/stable/c/cc56c4d17721dcb10ad4e9c9266e449be1462683
- https://git.kernel.org/stable/c/eb988e46da2e4eae89f5337e047ce372fe33d5b1
- https://git.kernel.org/stable/c/2f236d8638f5b43e0c72919a6a27fe286c32053f
- https://git.kernel.org/stable/c/303766bb92c5c225cf40f9bbbe7e29749406e2f2
- https://git.kernel.org/stable/c/50d12253666195a14c6cd2b81c376e2dbeedbdff
- https://git.kernel.org/stable/c/6c71e065befb2fae8f1461559b940c04e1071bd5
- https://git.kernel.org/stable/c/7082b1fb5321037bc11ba1cf2d7ed23c6b2b521f
- https://git.kernel.org/stable/c/c8e639f5743cf4b01f8c65e0df075fe4d782b585
- https://git.kernel.org/stable/c/cc56c4d17721dcb10ad4e9c9266e449be1462683
- https://git.kernel.org/stable/c/eb988e46da2e4eae89f5337e047ce372fe33d5b1
Modified: 2024-12-31
CVE-2023-52841
In the Linux kernel, the following vulnerability has been resolved: media: vidtv: mux: Add check and kfree for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak.
- https://git.kernel.org/stable/c/1fd6eb12642e0c32692924ff359c07de4b781d78
- https://git.kernel.org/stable/c/64863ba8e6b7651d994c6e6d506cc8aa2ac45edb
- https://git.kernel.org/stable/c/980be4c3b0d51c0f873fd750117774561c66cf68
- https://git.kernel.org/stable/c/a254ee1ddc592ae1efcce96b8c014e1bd2d5a2b4
- https://git.kernel.org/stable/c/aae7598aff291d4d140be1355aa20930af948785
- https://git.kernel.org/stable/c/cb13001411999adb158b39e76d94705eb2da100d
- https://git.kernel.org/stable/c/1fd6eb12642e0c32692924ff359c07de4b781d78
- https://git.kernel.org/stable/c/64863ba8e6b7651d994c6e6d506cc8aa2ac45edb
- https://git.kernel.org/stable/c/980be4c3b0d51c0f873fd750117774561c66cf68
- https://git.kernel.org/stable/c/a254ee1ddc592ae1efcce96b8c014e1bd2d5a2b4
- https://git.kernel.org/stable/c/aae7598aff291d4d140be1355aa20930af948785
- https://git.kernel.org/stable/c/cb13001411999adb158b39e76d94705eb2da100d
Modified: 2025-09-24
CVE-2023-52843
In the Linux kernel, the following vulnerability has been resolved: llc: verify mac len before reading mac header LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header. Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI). BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002 Add a mac_len test before all three eth_hdr(skb) calls under net/llc. There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario. But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code. It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring. At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.
- https://git.kernel.org/stable/c/0a720d0259ad3521ec6c9e4199f9f6fc75bac77a
- https://git.kernel.org/stable/c/352887b3edd007cf9b0abc30fe9d98622acd859b
- https://git.kernel.org/stable/c/3a2653828ffc6101aef80bf58d5b77484239f779
- https://git.kernel.org/stable/c/7b3ba18703a63f6fd487183b9262b08e5632da1b
- https://git.kernel.org/stable/c/900a4418e3f66a32db6baaf23f92b99c20ae6535
- https://git.kernel.org/stable/c/9a3f9054a5227d7567cba1fb821df48ccecad10c
- https://git.kernel.org/stable/c/cbdcdf42d15dac74c7287679fb2a9d955f8feb1f
- https://git.kernel.org/stable/c/f980e9a57dfb9530f1f4ee41a2420f2a256d7b29
- https://git.kernel.org/stable/c/ff5cb6a4f0c6d7fbdc84858323fb4b7af32cfd79
- https://git.kernel.org/stable/c/0a720d0259ad3521ec6c9e4199f9f6fc75bac77a
- https://git.kernel.org/stable/c/352887b3edd007cf9b0abc30fe9d98622acd859b
- https://git.kernel.org/stable/c/3a2653828ffc6101aef80bf58d5b77484239f779
- https://git.kernel.org/stable/c/7b3ba18703a63f6fd487183b9262b08e5632da1b
- https://git.kernel.org/stable/c/900a4418e3f66a32db6baaf23f92b99c20ae6535
- https://git.kernel.org/stable/c/9a3f9054a5227d7567cba1fb821df48ccecad10c
- https://git.kernel.org/stable/c/cbdcdf42d15dac74c7287679fb2a9d955f8feb1f
- https://git.kernel.org/stable/c/f980e9a57dfb9530f1f4ee41a2420f2a256d7b29
- https://git.kernel.org/stable/c/ff5cb6a4f0c6d7fbdc84858323fb4b7af32cfd79
Modified: 2025-04-02
CVE-2023-52844
In the Linux kernel, the following vulnerability has been resolved: media: vidtv: psi: Add check for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/3387490c89b10aeb4e71d78b65dbc9ba4b2385b9
- https://git.kernel.org/stable/c/5c26aae3723965c291c65dd2ecad6a3240d422b0
- https://git.kernel.org/stable/c/5cfcc8de7d733a1137b86954cc28ce99972311ad
- https://git.kernel.org/stable/c/76a2c5df6ca8bd8ada45e953b8c72b746f42918d
- https://git.kernel.org/stable/c/a51335704a3f90eaf23a6864faefca34b382490a
- https://git.kernel.org/stable/c/d17269fb9161995303985ab2fe6f16cfb72152f9
- https://git.kernel.org/stable/c/3387490c89b10aeb4e71d78b65dbc9ba4b2385b9
- https://git.kernel.org/stable/c/5c26aae3723965c291c65dd2ecad6a3240d422b0
- https://git.kernel.org/stable/c/5cfcc8de7d733a1137b86954cc28ce99972311ad
- https://git.kernel.org/stable/c/76a2c5df6ca8bd8ada45e953b8c72b746f42918d
- https://git.kernel.org/stable/c/a51335704a3f90eaf23a6864faefca34b382490a
- https://git.kernel.org/stable/c/d17269fb9161995303985ab2fe6f16cfb72152f9
Modified: 2025-01-31
CVE-2023-52845
In the Linux kernel, the following vulnerability has been resolved: tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING syzbot reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue. This patch changes the nla_policy for bearer-related names from NLA_STRING to NLA_NUL_STRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names. syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue.
- https://git.kernel.org/stable/c/19b3f72a41a8751e26bffc093bb7e1cef29ad579
- https://git.kernel.org/stable/c/2199260c42e6fbc5af8adae3bf78e623407c91b0
- https://git.kernel.org/stable/c/2426425d686b43adbc4f2f4a367b494f06f159d6
- https://git.kernel.org/stable/c/3907b89cd17fcc23e9a80789c36856f00ece0ba8
- https://git.kernel.org/stable/c/4c731e98fe4d678e87ba3e4d45d3cf0a5a193dc4
- https://git.kernel.org/stable/c/560992f41c0cea44b7603bc9e6c73bffbf6b5709
- https://git.kernel.org/stable/c/6744008c354bca2e4686a5b6056ee6b535d9f67d
- https://git.kernel.org/stable/c/abc1582119e8c4af14cedb0db6541fd603f45a04
- https://git.kernel.org/stable/c/b33d130f07f1decd756b849ab03c23d11d4dd294
- https://git.kernel.org/stable/c/19b3f72a41a8751e26bffc093bb7e1cef29ad579
- https://git.kernel.org/stable/c/2199260c42e6fbc5af8adae3bf78e623407c91b0
- https://git.kernel.org/stable/c/2426425d686b43adbc4f2f4a367b494f06f159d6
- https://git.kernel.org/stable/c/3907b89cd17fcc23e9a80789c36856f00ece0ba8
- https://git.kernel.org/stable/c/4c731e98fe4d678e87ba3e4d45d3cf0a5a193dc4
- https://git.kernel.org/stable/c/560992f41c0cea44b7603bc9e6c73bffbf6b5709
- https://git.kernel.org/stable/c/6744008c354bca2e4686a5b6056ee6b535d9f67d
- https://git.kernel.org/stable/c/abc1582119e8c4af14cedb0db6541fd603f45a04
- https://git.kernel.org/stable/c/b33d130f07f1decd756b849ab03c23d11d4dd294
Modified: 2024-12-31
CVE-2023-52846
In the Linux kernel, the following vulnerability has been resolved: hsr: Prevent use after free in prp_create_tagged_frame() The prp_fill_rct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value.
- https://git.kernel.org/stable/c/1787b9f0729d318d67cf7c5a95f0c3dba9a7cc18
- https://git.kernel.org/stable/c/6086258bd5ea7b5c706ff62da42b8e271b2401db
- https://git.kernel.org/stable/c/876f8ab52363f649bcc74072157dfd7adfbabc0d
- https://git.kernel.org/stable/c/a1a485e45d24b1cd8fe834fd6f1b06e2903827da
- https://git.kernel.org/stable/c/d103fb6726904e353b4773188ee3d3acb4078363
- https://git.kernel.org/stable/c/ddf4e04e946aaa6c458b8b6829617cc44af2bffd
- https://git.kernel.org/stable/c/1787b9f0729d318d67cf7c5a95f0c3dba9a7cc18
- https://git.kernel.org/stable/c/6086258bd5ea7b5c706ff62da42b8e271b2401db
- https://git.kernel.org/stable/c/876f8ab52363f649bcc74072157dfd7adfbabc0d
- https://git.kernel.org/stable/c/a1a485e45d24b1cd8fe834fd6f1b06e2903827da
- https://git.kernel.org/stable/c/d103fb6726904e353b4773188ee3d3acb4078363
- https://git.kernel.org/stable/c/ddf4e04e946aaa6c458b8b6829617cc44af2bffd
Modified: 2025-03-04
CVE-2023-52847
In the Linux kernel, the following vulnerability has been resolved: media: bttv: fix use after free error due to btv->timeout timer There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug. This bug is found by static analysis, it may be false positive. Fix it by adding del_timer_sync invoking to the remove function. cpu0 cpu1 bttv_probe ->timer_setup ->bttv_set_dma ->mod_timer; bttv_remove ->kfree(btv); ->bttv_irq_timeout ->USE btv
- https://git.kernel.org/stable/c/1871014d6ef4812ad11ef7d838d73ce09d632267
- https://git.kernel.org/stable/c/20568d06f6069cb835e05eed432edf962645d226
- https://git.kernel.org/stable/c/2f3d9198cdae1cb079ec8652f4defacd481eab2b
- https://git.kernel.org/stable/c/51c94256a83fe4e17406c66ff3e1ad7d242d8574
- https://git.kernel.org/stable/c/847599fffa528b2cdec4e21b6bf7586dad982132
- https://git.kernel.org/stable/c/b35fdade92c5058a5e727e233fe263b828de2c9a
- https://git.kernel.org/stable/c/bbc3b8dd2cb7817e703f112d988e4f4728f0f2a9
- https://git.kernel.org/stable/c/bd5b50b329e850d467e7bcc07b2b6bde3752fbda
- https://git.kernel.org/stable/c/1871014d6ef4812ad11ef7d838d73ce09d632267
- https://git.kernel.org/stable/c/20568d06f6069cb835e05eed432edf962645d226
- https://git.kernel.org/stable/c/2f3d9198cdae1cb079ec8652f4defacd481eab2b
- https://git.kernel.org/stable/c/51c94256a83fe4e17406c66ff3e1ad7d242d8574
- https://git.kernel.org/stable/c/847599fffa528b2cdec4e21b6bf7586dad982132
- https://git.kernel.org/stable/c/b35fdade92c5058a5e727e233fe263b828de2c9a
- https://git.kernel.org/stable/c/bbc3b8dd2cb7817e703f112d988e4f4728f0f2a9
- https://git.kernel.org/stable/c/bd5b50b329e850d467e7bcc07b2b6bde3752fbda
Modified: 2024-12-30
CVE-2023-52849
In the Linux kernel, the following vulnerability has been resolved:
cxl/mem: Fix shutdown order
Ira reports that removing cxl_mock_mem causes a crash with the following
trace:
BUG: kernel NULL pointer dereference, address: 0000000000000044
[..]
RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core]
[..]
Call Trace:
- https://git.kernel.org/stable/c/0ca074f7d788627a4e0b047ca5fbdb5fc567220c
- https://git.kernel.org/stable/c/20bd0198bebdd706bd4614b3933ef70d7c19618f
- https://git.kernel.org/stable/c/7c7371b41a14e86f53e7dbe5baa7b1d3e0ab324b
- https://git.kernel.org/stable/c/88d3917f82ed4215a2154432c26de1480a61b209
- https://git.kernel.org/stable/c/cad22a757029c3a1985c221a2d4a6491ad4035ae
- https://git.kernel.org/stable/c/0ca074f7d788627a4e0b047ca5fbdb5fc567220c
- https://git.kernel.org/stable/c/20bd0198bebdd706bd4614b3933ef70d7c19618f
- https://git.kernel.org/stable/c/7c7371b41a14e86f53e7dbe5baa7b1d3e0ab324b
- https://git.kernel.org/stable/c/88d3917f82ed4215a2154432c26de1480a61b209
- https://git.kernel.org/stable/c/cad22a757029c3a1985c221a2d4a6491ad4035ae
Modified: 2024-12-30
CVE-2023-52850
In the Linux kernel, the following vulnerability has been resolved: media: hantro: Check whether reset op is defined before use The i.MX8MM/N/P does not define the .reset op since reset of the VPU is done by genpd. Check whether the .reset op is defined before calling it to avoid NULL pointer dereference. Note that the Fixes tag is set to the commit which removed the reset op from i.MX8M Hantro G2 implementation, this is because before this commit all the implementations did define the .reset op.
- https://git.kernel.org/stable/c/24c06295f28335ced3aad53dd4b0a0bae7b9b100
- https://git.kernel.org/stable/c/64f55cebb4339ae771e9e7f3f42bee2489e2fa00
- https://git.kernel.org/stable/c/66b4c5f980d741f3a47e4b65eeaf2797f2d59294
- https://git.kernel.org/stable/c/88d4b23a629ebd34f682f770cb6c2116c851f7b8
- https://git.kernel.org/stable/c/24c06295f28335ced3aad53dd4b0a0bae7b9b100
- https://git.kernel.org/stable/c/64f55cebb4339ae771e9e7f3f42bee2489e2fa00
- https://git.kernel.org/stable/c/66b4c5f980d741f3a47e4b65eeaf2797f2d59294
- https://git.kernel.org/stable/c/88d4b23a629ebd34f682f770cb6c2116c851f7b8
Modified: 2025-01-10
CVE-2023-52851
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF
In the unlikely event that workqueue allocation fails and returns NULL in
mlx5_mkey_cache_init(), delete the call to
mlx5r_umr_resource_cleanup() (which frees the QP) in
mlx5_ib_stage_post_ib_reg_umr_init(). This will avoid attempted double
free of the same QP when __mlx5_ib_add() does its cleanup.
Resolves a splat:
Syzkaller reported a UAF in ib_destroy_qp_user
workqueue: Failed to create a rescuer kthread for wq "mkey_cache": -EINTR
infiniband mlx5_0: mlx5_mkey_cache_init:981:(pid 1642):
failed to create work queue
infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_init:4075:(pid 1642):
mr cache init failed -12
==================================================================
BUG: KASAN: slab-use-after-free in ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)
Read of size 8 at addr ffff88810da310a8 by task repro_upstream/1642
Call Trace:
- https://git.kernel.org/stable/c/2ef422f063b74adcc4a4a9004b0a87bb55e0a836
- https://git.kernel.org/stable/c/437f033e30c897bb3723eac9e9003cd9f88d00a3
- https://git.kernel.org/stable/c/4f4a7a7d1404297f2a92df0046f7e64dc5c52dd9
- https://git.kernel.org/stable/c/6387f269d84e6e149499408c4d1fc805017729b2
- https://git.kernel.org/stable/c/2ef422f063b74adcc4a4a9004b0a87bb55e0a836
- https://git.kernel.org/stable/c/437f033e30c897bb3723eac9e9003cd9f88d00a3
- https://git.kernel.org/stable/c/4f4a7a7d1404297f2a92df0046f7e64dc5c52dd9
- https://git.kernel.org/stable/c/6387f269d84e6e149499408c4d1fc805017729b2
Modified: 2024-12-30
CVE-2023-52852
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to avoid use-after-free on dic Call trace: __memcpy+0x128/0x250 f2fs_read_multi_pages+0x940/0xf7c f2fs_mpage_readpages+0x5a8/0x624 f2fs_readahead+0x5c/0x110 page_cache_ra_unbounded+0x1b8/0x590 do_sync_mmap_readahead+0x1dc/0x2e4 filemap_fault+0x254/0xa8c f2fs_filemap_fault+0x2c/0x104 __do_fault+0x7c/0x238 do_handle_mm_fault+0x11bc/0x2d14 do_mem_abort+0x3a8/0x1004 el0_da+0x3c/0xa0 el0t_64_sync_handler+0xc4/0xec el0t_64_sync+0x1b4/0x1b8 In f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if we hit cached page in compress_inode's cache, dic may be released, it needs break the loop rather than continuing it, in order to avoid accessing invalid dic pointer.
- https://git.kernel.org/stable/c/8c4504cc0c64862740a6acb301e0cfa59580dbc5
- https://git.kernel.org/stable/c/932ddb5c29e884cc6fac20417ece72ba4a35c401
- https://git.kernel.org/stable/c/9375ea7f269093d7c884857ae1f47633a91f429c
- https://git.kernel.org/stable/c/9d065aa52b6ee1b06f9c4eca881c9b4425a12ba2
- https://git.kernel.org/stable/c/b0327c84e91a0f4f0abced8cb83ec86a7083f086
- https://git.kernel.org/stable/c/8c4504cc0c64862740a6acb301e0cfa59580dbc5
- https://git.kernel.org/stable/c/932ddb5c29e884cc6fac20417ece72ba4a35c401
- https://git.kernel.org/stable/c/9375ea7f269093d7c884857ae1f47633a91f429c
- https://git.kernel.org/stable/c/9d065aa52b6ee1b06f9c4eca881c9b4425a12ba2
- https://git.kernel.org/stable/c/b0327c84e91a0f4f0abced8cb83ec86a7083f086
Modified: 2025-09-26
CVE-2023-52853
In the Linux kernel, the following vulnerability has been resolved: hid: cp2112: Fix duplicate workqueue initialization Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c. Initialize the workqueue within _probe instead.
- https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf
- https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd
- https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819
- https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38
- https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6
- https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42
- https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c
- https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592
- https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf
- https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd
- https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819
- https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38
- https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6
- https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42
- https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c
- https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592
Modified: 2025-02-03
CVE-2023-52854
In the Linux kernel, the following vulnerability has been resolved: padata: Fix refcnt handling in padata_free_shell() In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcrypt_aead01 function call, I'll describe the problem scenario using a simplified model: Suppose there's a user of padata named `user_function` that adheres to the padata requirement of calling `padata_free_shell` after `serial()` has been invoked, as demonstrated in the following code: ```c struct request { struct padata_priv padata; struct completion *done; }; void parallel(struct padata_priv *padata) { do_something(); } void serial(struct padata_priv *padata) { struct request *request = container_of(padata, struct request, padata); complete(request->done); } void user_function() { DECLARE_COMPLETION(done) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&done); padata_free_shell(); } ``` In the corresponding padata.c file, there's the following code: ```c static void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd); } ``` Because of the high system load and the accumulation of unexecuted softirq at this moment, `local_bh_enable()` in padata takes longer to execute than usual. Subsequently, when accessing `pd->refcnt`, `pd` has already been released by `padata_free_shell()`, resulting in a UAF issue with `pd->refcnt`. The fix is straightforward: add `refcount_dec_and_test` before calling `padata_free_pd` in `padata_free_shell`.
- https://git.kernel.org/stable/c/0dd34a7ad395dbcf6ae60e48e9786050e25b9bc5
- https://git.kernel.org/stable/c/1734a79e951914f1db2c65e635012a35db1c674b
- https://git.kernel.org/stable/c/1e901bcb8af19416b65f5063a4af7996e5a51d7f
- https://git.kernel.org/stable/c/41aad9d6953984d134fc50f631f24ef476875d4d
- https://git.kernel.org/stable/c/7ddc21e317b360c3444de3023bcc83b85fabae2f
- https://git.kernel.org/stable/c/c7c26d0ef5d20f00dbb2ae3befcabbe0efa77275
- https://git.kernel.org/stable/c/0dd34a7ad395dbcf6ae60e48e9786050e25b9bc5
- https://git.kernel.org/stable/c/1734a79e951914f1db2c65e635012a35db1c674b
- https://git.kernel.org/stable/c/1e901bcb8af19416b65f5063a4af7996e5a51d7f
- https://git.kernel.org/stable/c/41aad9d6953984d134fc50f631f24ef476875d4d
- https://git.kernel.org/stable/c/7ddc21e317b360c3444de3023bcc83b85fabae2f
- https://git.kernel.org/stable/c/c7c26d0ef5d20f00dbb2ae3befcabbe0efa77275
Modified: 2025-04-02
CVE-2023-52855
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference. This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5. To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic.
- https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72
- https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82622986d
- https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e
- https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790
- https://git.kernel.org/stable/c/a7bee9598afb38004841a41dd8fe68c1faff4e90
- https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6
- https://git.kernel.org/stable/c/ef307bc6ef04e8c1ea843231db58e3afaafa9fa6
- https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001
- https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d
- https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72
- https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82622986d
- https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e
- https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790
- https://git.kernel.org/stable/c/a7bee9598afb38004841a41dd8fe68c1faff4e90
- https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6
- https://git.kernel.org/stable/c/ef307bc6ef04e8c1ea843231db58e3afaafa9fa6
- https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001
- https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d
Modified: 2025-01-31
CVE-2023-52856
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: lt8912b: Fix crash on bridge detach The lt8912b driver, in its bridge detach function, calls drm_connector_unregister() and drm_connector_cleanup(). drm_connector_unregister() should be called only for connectors explicitly registered with drm_connector_register(), which is not the case in lt8912b. The driver's drm_connector_funcs.destroy hook is set to drm_connector_cleanup(). Thus the driver should not call either drm_connector_unregister() nor drm_connector_cleanup() in its lt8912_bridge_detach(), as they cause a crash on bridge detach: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000000858f3000 [0000000000000000] pgd=0800000085918003, p4d=0800000085918003, pud=0800000085431003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Modules linked in: tidss(-) display_connector lontium_lt8912b tc358768 panel_lvds panel_simple drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks CPU: 3 PID: 462 Comm: rmmod Tainted: G W 6.5.0-rc2+ #2 Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_connector_cleanup+0x78/0x2d4 [drm] lr : lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b] sp : ffff800082ed3a90 x29: ffff800082ed3a90 x28: ffff0000040c1940 x27: 0000000000000000 x26: 0000000000000000 x25: dead000000000122 x24: dead000000000122 x23: dead000000000100 x22: ffff000003fb6388 x21: 0000000000000000 x20: 0000000000000000 x19: ffff000003fb6260 x18: fffffffffffe56e8 x17: 0000000000000000 x16: 0010000000000000 x15: 0000000000000038 x14: 0000000000000000 x13: ffff800081914b48 x12: 000000000000040e x11: 000000000000015a x10: ffff80008196ebb8 x9 : ffff800081914b48 x8 : 00000000ffffefff x7 : ffff0000040c1940 x6 : ffff80007aa649d0 x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff80008159e008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: drm_connector_cleanup+0x78/0x2d4 [drm] lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b] drm_bridge_detach+0x44/0x84 [drm] drm_encoder_cleanup+0x40/0xb8 [drm] drmm_encoder_alloc_release+0x1c/0x30 [drm] drm_managed_release+0xac/0x148 [drm] drm_dev_put.part.0+0x88/0xb8 [drm] devm_drm_dev_init_release+0x14/0x24 [drm] devm_action_release+0x14/0x20 release_nodes+0x5c/0x90 devres_release_all+0x8c/0xe0 device_unbind_cleanup+0x18/0x68 device_release_driver_internal+0x208/0x23c driver_detach+0x4c/0x94 bus_remove_driver+0x70/0xf4 driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 tidss_platform_driver_exit+0x18/0xb2c [tidss] __arm64_sys_delete_module+0x1a0/0x2b4 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x60/0x10c do_el0_svc_compat+0x1c/0x40 el0_svc_compat+0x40/0xac el0t_32_sync_handler+0xb0/0x138 el0t_32_sync+0x194/0x198 Code: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420)
- https://git.kernel.org/stable/c/42071feab712ba2a139b8928f7e0f8d3a6fc719e
- https://git.kernel.org/stable/c/44283993144a03af9df31934d6c32bbd42d1a347
- https://git.kernel.org/stable/c/7bf0cb8f40280a85034990dfe42be8ca8f80f37a
- https://git.kernel.org/stable/c/b65e3249f3ca96e3c736af889461d80d675feab6
- https://git.kernel.org/stable/c/fcd9895e365474709844eeb31cfe53d912c3596e
- https://git.kernel.org/stable/c/42071feab712ba2a139b8928f7e0f8d3a6fc719e
- https://git.kernel.org/stable/c/44283993144a03af9df31934d6c32bbd42d1a347
- https://git.kernel.org/stable/c/7bf0cb8f40280a85034990dfe42be8ca8f80f37a
- https://git.kernel.org/stable/c/b65e3249f3ca96e3c736af889461d80d675feab6
- https://git.kernel.org/stable/c/fcd9895e365474709844eeb31cfe53d912c3596e
Modified: 2025-04-02
CVE-2023-52858
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/1d89430fc3158f872d492f1b88d07262f48290c0
- https://git.kernel.org/stable/c/2befa515c1bb6cdd33c262b909d93d1973a219aa
- https://git.kernel.org/stable/c/4f861b63945e076f9f003a5fad958174096df1ee
- https://git.kernel.org/stable/c/5fbea47eebff5daeca7d918c99289bcd3ae4dc8d
- https://git.kernel.org/stable/c/a836efc21ef04608333d6d05753e558ebd1f85d0
- https://git.kernel.org/stable/c/e8ae4b49dd9cfde69d8de8c0c0cd7cf1b004482e
- https://git.kernel.org/stable/c/e964d21dc034b650d719c4ea39564bec72b42f94
- https://git.kernel.org/stable/c/1d89430fc3158f872d492f1b88d07262f48290c0
- https://git.kernel.org/stable/c/2befa515c1bb6cdd33c262b909d93d1973a219aa
- https://git.kernel.org/stable/c/4f861b63945e076f9f003a5fad958174096df1ee
- https://git.kernel.org/stable/c/5fbea47eebff5daeca7d918c99289bcd3ae4dc8d
- https://git.kernel.org/stable/c/a836efc21ef04608333d6d05753e558ebd1f85d0
- https://git.kernel.org/stable/c/e8ae4b49dd9cfde69d8de8c0c0cd7cf1b004482e
- https://git.kernel.org/stable/c/e964d21dc034b650d719c4ea39564bec72b42f94
Modified: 2025-01-14
CVE-2023-52859
In the Linux kernel, the following vulnerability has been resolved: perf: hisi: Fix use-after-free when register pmu fails When we fail to register the uncore pmu, the pmu context may not been allocated. The error handing will call cpuhp_state_remove_instance() to call uncore pmu offline callback, which migrate the pmu context. Since that's liable to lead to some kind of use-after-free. Use cpuhp_state_remove_instance_nocalls() instead of cpuhp_state_remove_instance() so that the notifiers don't execute after the PMU device has been failed to register.
- https://git.kernel.org/stable/c/0e1e88bba286621b886218363de07b319d6208b2
- https://git.kernel.org/stable/c/3405f364f82d4f5407a8b4c519dc15d24b847fda
- https://git.kernel.org/stable/c/75bab28ffd05ec8879c197890b1bd1dfec8d3f63
- https://git.kernel.org/stable/c/b660420f449d094b1fabfa504889810b3a63cdd5
- https://git.kernel.org/stable/c/b805cafc604bfdb671fae7347a57f51154afa735
- https://git.kernel.org/stable/c/0e1e88bba286621b886218363de07b319d6208b2
- https://git.kernel.org/stable/c/3405f364f82d4f5407a8b4c519dc15d24b847fda
- https://git.kernel.org/stable/c/75bab28ffd05ec8879c197890b1bd1dfec8d3f63
- https://git.kernel.org/stable/c/b660420f449d094b1fabfa504889810b3a63cdd5
- https://git.kernel.org/stable/c/b805cafc604bfdb671fae7347a57f51154afa735
Modified: 2025-02-03
CVE-2023-52860
In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug callbacks after the device has been unregistered, leading to fireworks when we try to execute empty function callbacks within the driver: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G W O 5.12.0-rc4+ #1 | Hardware name: , BIOS KpxxxFPGA 1P B600 V143 04/22/2021 | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) | pc : perf_pmu_migrate_context+0x98/0x38c | lr : perf_pmu_migrate_context+0x94/0x38c | | Call trace: | perf_pmu_migrate_context+0x98/0x38c | hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu] Use cpuhp_state_remove_instance_nocalls() instead of cpuhp_state_remove_instance() so that the notifiers don't execute after the PMU device has been unregistered. [will: Rewrote commit message]
- https://git.kernel.org/stable/c/3f5827371763f2d9c70719c270055a81d030f3d0
- https://git.kernel.org/stable/c/4589403a343bb0c72a6faf5898386ff964d4e01a
- https://git.kernel.org/stable/c/50b560783f7f71790bcf70e9e9855155fb0af8c1
- https://git.kernel.org/stable/c/d04ff5437a45f275db5530efb49b68d0ec851f6f
- https://git.kernel.org/stable/c/3f5827371763f2d9c70719c270055a81d030f3d0
- https://git.kernel.org/stable/c/4589403a343bb0c72a6faf5898386ff964d4e01a
- https://git.kernel.org/stable/c/50b560783f7f71790bcf70e9e9855155fb0af8c1
- https://git.kernel.org/stable/c/d04ff5437a45f275db5530efb49b68d0ec851f6f
Modified: 2025-04-02
CVE-2023-52861
In the Linux kernel, the following vulnerability has been resolved: drm: bridge: it66121: Fix invalid connector dereference Fix the NULL pointer dereference when no monitor is connected, and the sound card is opened from userspace. Instead return an empty buffer (of zeroes) as the EDID information to the sound framework if there is no connector attached.
- https://git.kernel.org/stable/c/1374561a7cbc9a000b77bb0473bb2c19daf18d86
- https://git.kernel.org/stable/c/1669d7b21a664aa531856ce85b01359a376baebc
- https://git.kernel.org/stable/c/2c80c4f0d2845645f41cbb7c9304c8efbdbd4331
- https://git.kernel.org/stable/c/d0375f6858c4ff7244b62b02eb5e93428e1916cd
- https://git.kernel.org/stable/c/1374561a7cbc9a000b77bb0473bb2c19daf18d86
- https://git.kernel.org/stable/c/1669d7b21a664aa531856ce85b01359a376baebc
- https://git.kernel.org/stable/c/2c80c4f0d2845645f41cbb7c9304c8efbdbd4331
- https://git.kernel.org/stable/c/d0375f6858c4ff7244b62b02eb5e93428e1916cd
Modified: 2025-01-14
CVE-2023-52863
In the Linux kernel, the following vulnerability has been resolved: hwmon: (axi-fan-control) Fix possible NULL pointer dereference axi_fan_control_irq_handler(), dependent on the private axi_fan_control_data structure, might be called before the hwmon device is registered. That will cause an "Unable to handle kernel NULL pointer dereference" error.
- https://git.kernel.org/stable/c/2a5b3370a1d9750eca325292e291c8c7cb8cf2e0
- https://git.kernel.org/stable/c/33de53a2706066d526173dc743faf43d92c62105
- https://git.kernel.org/stable/c/7d870088db4863c514a7f8751cd593751983029a
- https://git.kernel.org/stable/c/b3e7eb23a6e97642ff3190431c06475d9ca1e062
- https://git.kernel.org/stable/c/c49f14cc1bb12c625a1c572e8a95b6adefd4d8eb
- https://git.kernel.org/stable/c/f62b8969847850ba7596cb145cc47c65ea57dae0
- https://git.kernel.org/stable/c/2a5b3370a1d9750eca325292e291c8c7cb8cf2e0
- https://git.kernel.org/stable/c/33de53a2706066d526173dc743faf43d92c62105
- https://git.kernel.org/stable/c/7d870088db4863c514a7f8751cd593751983029a
- https://git.kernel.org/stable/c/b3e7eb23a6e97642ff3190431c06475d9ca1e062
- https://git.kernel.org/stable/c/c49f14cc1bb12c625a1c572e8a95b6adefd4d8eb
- https://git.kernel.org/stable/c/f62b8969847850ba7596cb145cc47c65ea57dae0
Modified: 2025-09-24
CVE-2023-52864
In the Linux kernel, the following vulnerability has been resolved: platform/x86: wmi: Fix opening of char device Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices(). Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver.
- https://git.kernel.org/stable/c/36d85fa7ae0d6be651c1a745191fa7ef055db43e
- https://git.kernel.org/stable/c/44a96796d25809502c75771d40ee693c2e44724e
- https://git.kernel.org/stable/c/9fb0eed09e1470cd4021ff52b2b9dfcbcee4c203
- https://git.kernel.org/stable/c/cf098e937dd125c0317a0d6f261ac2a950a233d6
- https://git.kernel.org/stable/c/d426a2955e45a95b2282764105fcfb110a540453
- https://git.kernel.org/stable/c/e0bf076b734a2fab92d8fddc2b8b03462eee7097
- https://git.kernel.org/stable/c/eba9ac7abab91c8f6d351460239108bef5e7a0b6
- https://git.kernel.org/stable/c/fb7b06b59c6887659c6ed0ecd3110835eecbb6a3
- https://git.kernel.org/stable/c/36d85fa7ae0d6be651c1a745191fa7ef055db43e
- https://git.kernel.org/stable/c/44a96796d25809502c75771d40ee693c2e44724e
- https://git.kernel.org/stable/c/9fb0eed09e1470cd4021ff52b2b9dfcbcee4c203
- https://git.kernel.org/stable/c/cf098e937dd125c0317a0d6f261ac2a950a233d6
- https://git.kernel.org/stable/c/d426a2955e45a95b2282764105fcfb110a540453
- https://git.kernel.org/stable/c/e0bf076b734a2fab92d8fddc2b8b03462eee7097
- https://git.kernel.org/stable/c/eba9ac7abab91c8f6d351460239108bef5e7a0b6
- https://git.kernel.org/stable/c/fb7b06b59c6887659c6ed0ecd3110835eecbb6a3
Modified: 2025-01-14
CVE-2023-52865
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/122ac6496e4975ddd7ec1edba4f6fc1e15e39478
- https://git.kernel.org/stable/c/2705c5b97f504e831ae1935c05f0e44f80dfa6b3
- https://git.kernel.org/stable/c/357df1c2f6ace96defd557fad709ed1f9f70e16c
- https://git.kernel.org/stable/c/3aefc6fcfbada57fac27f470602d5565e5b76cb4
- https://git.kernel.org/stable/c/4c79cbfb8e9e2311be77182893fda5ea4068c836
- https://git.kernel.org/stable/c/606f6366a35a3329545e38129804d65ef26ed7d2
- https://git.kernel.org/stable/c/81b16286110728674dcf81137be0687c5055e7bf
- https://git.kernel.org/stable/c/be3f12f16038a558f08fa93cc32fa715746a5235
- https://git.kernel.org/stable/c/c26feedbc561f2a3cee1a4f717e61bdbdfb4fa92
- https://git.kernel.org/stable/c/122ac6496e4975ddd7ec1edba4f6fc1e15e39478
- https://git.kernel.org/stable/c/2705c5b97f504e831ae1935c05f0e44f80dfa6b3
- https://git.kernel.org/stable/c/357df1c2f6ace96defd557fad709ed1f9f70e16c
- https://git.kernel.org/stable/c/3aefc6fcfbada57fac27f470602d5565e5b76cb4
- https://git.kernel.org/stable/c/4c79cbfb8e9e2311be77182893fda5ea4068c836
- https://git.kernel.org/stable/c/606f6366a35a3329545e38129804d65ef26ed7d2
- https://git.kernel.org/stable/c/81b16286110728674dcf81137be0687c5055e7bf
- https://git.kernel.org/stable/c/be3f12f16038a558f08fa93cc32fa715746a5235
- https://git.kernel.org/stable/c/c26feedbc561f2a3cee1a4f717e61bdbdfb4fa92
Modified: 2025-09-24
CVE-2023-52867
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: possible buffer overflow Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is checked after access.
- https://git.kernel.org/stable/c/112d4b02d94bf9fa4f1d3376587878400dd74783
- https://git.kernel.org/stable/c/19534a7a225f1bf2da70a9a90d41d0215f8f6b45
- https://git.kernel.org/stable/c/341e79f8aec6af6b0061b8171d77b085835c6a58
- https://git.kernel.org/stable/c/347f025a02b3a5d715a0b471fc3b1439c338ad94
- https://git.kernel.org/stable/c/7b063c93bece827fde237fae1c101bceeee4e896
- https://git.kernel.org/stable/c/caaa74541459c4c9e2c10046cf66ad2890483d0f
- https://git.kernel.org/stable/c/d9b4fa249deaae1145d6fc2b64dae718e5c7a855
- https://git.kernel.org/stable/c/dd05484f99d16715a88eedfca363828ef9a4c2d4
- https://git.kernel.org/stable/c/ddc42881f170f1f518496f5a70447501335fc783
- https://git.kernel.org/stable/c/112d4b02d94bf9fa4f1d3376587878400dd74783
- https://git.kernel.org/stable/c/19534a7a225f1bf2da70a9a90d41d0215f8f6b45
- https://git.kernel.org/stable/c/341e79f8aec6af6b0061b8171d77b085835c6a58
- https://git.kernel.org/stable/c/347f025a02b3a5d715a0b471fc3b1439c338ad94
- https://git.kernel.org/stable/c/7b063c93bece827fde237fae1c101bceeee4e896
- https://git.kernel.org/stable/c/caaa74541459c4c9e2c10046cf66ad2890483d0f
- https://git.kernel.org/stable/c/d9b4fa249deaae1145d6fc2b64dae718e5c7a855
- https://git.kernel.org/stable/c/dd05484f99d16715a88eedfca363828ef9a4c2d4
- https://git.kernel.org/stable/c/ddc42881f170f1f518496f5a70447501335fc783
Modified: 2025-09-26
CVE-2023-52868
In the Linux kernel, the following vulnerability has been resolved: thermal: core: prevent potential string overflow The dev->id value comes from ida_alloc() so it's a number between zero and INT_MAX. If it's too high then these sprintf()s will overflow.
- https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97
- https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb
- https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c
- https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c
- https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521
- https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8
- https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8
- https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5
- https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686
- https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97
- https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb
- https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c
- https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c
- https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521
- https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8
- https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8
- https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5
- https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686
Modified: 2025-04-02
CVE-2023-52869
In the Linux kernel, the following vulnerability has been resolved: pstore/platform: Add check for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/1c426da79f9fc7b761021b5eb44185ba119cd44a
- https://git.kernel.org/stable/c/379b120e4f27fd1cf636a5f85570c4d240a3f688
- https://git.kernel.org/stable/c/63f637309baadf81a095f2653e3b807d4b5814b9
- https://git.kernel.org/stable/c/a19d48f7c5d57c0f0405a7d4334d1d38fe9d3c1c
- https://git.kernel.org/stable/c/ad5cb6deb41417ef41b9d6ff54f789212108606f
- https://git.kernel.org/stable/c/bb166bdae1a7d7db30e9be7e6ccaba606debc05f
- https://git.kernel.org/stable/c/1c426da79f9fc7b761021b5eb44185ba119cd44a
- https://git.kernel.org/stable/c/379b120e4f27fd1cf636a5f85570c4d240a3f688
- https://git.kernel.org/stable/c/63f637309baadf81a095f2653e3b807d4b5814b9
- https://git.kernel.org/stable/c/a19d48f7c5d57c0f0405a7d4334d1d38fe9d3c1c
- https://git.kernel.org/stable/c/ad5cb6deb41417ef41b9d6ff54f789212108606f
- https://git.kernel.org/stable/c/bb166bdae1a7d7db30e9be7e6ccaba606debc05f
Modified: 2025-04-02
CVE-2023-52870
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/10cc81124407d862f0f747db4baa9c006510b480
- https://git.kernel.org/stable/c/2617aa8ceaf30e41d3eb7f5fef3445542bef193a
- https://git.kernel.org/stable/c/533ca5153ad6c7b7d47ae0114b14d0333964b946
- https://git.kernel.org/stable/c/b5ff3e89b4e7f46ad2aa0de7e08d18e6f87d71bc
- https://git.kernel.org/stable/c/b82681042724924ae3ba0f2f2eeec217fa31e830
- https://git.kernel.org/stable/c/dd1f30d68fa98eb672c0a259297b761656a9025f
- https://git.kernel.org/stable/c/10cc81124407d862f0f747db4baa9c006510b480
- https://git.kernel.org/stable/c/2617aa8ceaf30e41d3eb7f5fef3445542bef193a
- https://git.kernel.org/stable/c/533ca5153ad6c7b7d47ae0114b14d0333964b946
- https://git.kernel.org/stable/c/b5ff3e89b4e7f46ad2aa0de7e08d18e6f87d71bc
- https://git.kernel.org/stable/c/b82681042724924ae3ba0f2f2eeec217fa31e830
- https://git.kernel.org/stable/c/dd1f30d68fa98eb672c0a259297b761656a9025f
Modified: 2025-09-26
CVE-2023-52871
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: llcc: Handle a second device without data corruption Usually there is only one llcc device. But if there were a second, even a failed probe call would modify the global drv_data pointer. So check if drv_data is valid before overwriting it.
- https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493
- https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2
- https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0
- https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c
- https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c
- https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8
- https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d
- https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493
- https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2
- https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0
- https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c
- https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c
- https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8
- https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d
Modified: 2025-04-02
CVE-2023-52872
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix race condition in status line change on dead connections gsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all timers, removing the virtual tty devices and clearing the data queues. This procedure, however, may cause subsequent changes of the virtual modem status lines of a DLCI. More data is being added the outgoing data queue and the deleted kick timer is restarted to handle this. At this point many resources have already been removed by the cleanup procedure. Thus, a kernel panic occurs. Fix this by proving in gsm_modem_update() that the cleanup procedure has not been started and the mux is still alive. Note that writing to a virtual tty is already protected by checks against the DLCI specific connection state.
- https://git.kernel.org/stable/c/19d34b73234af542cc8a218cf398dee73cdb1890
- https://git.kernel.org/stable/c/3a75b205de43365f80a33b98ec9289785da56243
- https://git.kernel.org/stable/c/81a4dd5e6c78f5d8952fa8c9d36565db1fe01444
- https://git.kernel.org/stable/c/ce4df90333c4fe65acb8b5089fdfe9b955ce976a
- https://git.kernel.org/stable/c/df6cfab66ff2a44bd23ad5dd5309cb3421bb6593
- https://git.kernel.org/stable/c/19d34b73234af542cc8a218cf398dee73cdb1890
- https://git.kernel.org/stable/c/3a75b205de43365f80a33b98ec9289785da56243
- https://git.kernel.org/stable/c/81a4dd5e6c78f5d8952fa8c9d36565db1fe01444
- https://git.kernel.org/stable/c/ce4df90333c4fe65acb8b5089fdfe9b955ce976a
- https://git.kernel.org/stable/c/df6cfab66ff2a44bd23ad5dd5309cb3421bb6593
Modified: 2025-01-06
CVE-2023-52873
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/1f57f78fbacf630430bf954e5a84caafdfea30c0
- https://git.kernel.org/stable/c/3994387ba3564976731179c4d4a6d7850ddda71a
- https://git.kernel.org/stable/c/a90239551abc181687f8c0ba60b276f7d75c141e
- https://git.kernel.org/stable/c/ca6d565a2319d69d9766e6ecbb5af827fc4afb2b
- https://git.kernel.org/stable/c/df1c4a9efa3f5b6fb5e0ae63890230dbe2190b7e
- https://git.kernel.org/stable/c/f6a7c51cf07a399ec067d39f0a22f1817c5c7d2b
- https://git.kernel.org/stable/c/fbe466f06d4ea18745da0d57540539b7b36936ae
- https://git.kernel.org/stable/c/1f57f78fbacf630430bf954e5a84caafdfea30c0
- https://git.kernel.org/stable/c/3994387ba3564976731179c4d4a6d7850ddda71a
- https://git.kernel.org/stable/c/a90239551abc181687f8c0ba60b276f7d75c141e
- https://git.kernel.org/stable/c/ca6d565a2319d69d9766e6ecbb5af827fc4afb2b
- https://git.kernel.org/stable/c/df1c4a9efa3f5b6fb5e0ae63890230dbe2190b7e
- https://git.kernel.org/stable/c/f6a7c51cf07a399ec067d39f0a22f1817c5c7d2b
- https://git.kernel.org/stable/c/fbe466f06d4ea18745da0d57540539b7b36936ae
Modified: 2025-01-06
CVE-2023-52875
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/001e5def774fa1a8f2b29567c0b0cd3e3a859a96
- https://git.kernel.org/stable/c/0d6e24b422a2166a9297a8286ff2e6ab9a5e8cd3
- https://git.kernel.org/stable/c/1953e62366da5460dc712e045f94fb0d8918999d
- https://git.kernel.org/stable/c/1bf9c204aef4cc55ce46a7ff2d4dc7e5f86551a7
- https://git.kernel.org/stable/c/2a18dd653284550900b02107c3c7b3ac5e0eb802
- https://git.kernel.org/stable/c/6fccee2af400edaed9cf349d506c5971d4762739
- https://git.kernel.org/stable/c/d1175cf4bd2b4c5f7c43f677ea1ce9ad2c18d055
- https://git.kernel.org/stable/c/d1461f0c9ca0827c03730fe9652ebbf6316a2a95
- https://git.kernel.org/stable/c/e61934720af4a58ffd43a63ffdd6f3a0bd7d7b47
- https://git.kernel.org/stable/c/001e5def774fa1a8f2b29567c0b0cd3e3a859a96
- https://git.kernel.org/stable/c/0d6e24b422a2166a9297a8286ff2e6ab9a5e8cd3
- https://git.kernel.org/stable/c/1953e62366da5460dc712e045f94fb0d8918999d
- https://git.kernel.org/stable/c/1bf9c204aef4cc55ce46a7ff2d4dc7e5f86551a7
- https://git.kernel.org/stable/c/2a18dd653284550900b02107c3c7b3ac5e0eb802
- https://git.kernel.org/stable/c/6fccee2af400edaed9cf349d506c5971d4762739
- https://git.kernel.org/stable/c/d1175cf4bd2b4c5f7c43f677ea1ce9ad2c18d055
- https://git.kernel.org/stable/c/d1461f0c9ca0827c03730fe9652ebbf6316a2a95
- https://git.kernel.org/stable/c/e61934720af4a58ffd43a63ffdd6f3a0bd7d7b47
Modified: 2025-01-06
CVE-2023-52876
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/0884393c63cc9a1772f7121a6645ba7bd76feeb9
- https://git.kernel.org/stable/c/1639072f6260babd017556e9f236ca2ad589d1e7
- https://git.kernel.org/stable/c/96e9544a0c4faca616b3f9f4034dcd83a14e7f22
- https://git.kernel.org/stable/c/a540ca0aeae83c2f3964bcb4e383f64ce2ec1783
- https://git.kernel.org/stable/c/b20cfe007a46f8c165d42a05c50a8d3d893e6592
- https://git.kernel.org/stable/c/c4070ada5d5155c8d4d17ea64bd246949889f25b
- https://git.kernel.org/stable/c/cfa68e0ac5dcde43577adadf6f0f26f3b365ad68
- https://git.kernel.org/stable/c/0884393c63cc9a1772f7121a6645ba7bd76feeb9
- https://git.kernel.org/stable/c/1639072f6260babd017556e9f236ca2ad589d1e7
- https://git.kernel.org/stable/c/96e9544a0c4faca616b3f9f4034dcd83a14e7f22
- https://git.kernel.org/stable/c/a540ca0aeae83c2f3964bcb4e383f64ce2ec1783
- https://git.kernel.org/stable/c/b20cfe007a46f8c165d42a05c50a8d3d893e6592
- https://git.kernel.org/stable/c/c4070ada5d5155c8d4d17ea64bd246949889f25b
- https://git.kernel.org/stable/c/cfa68e0ac5dcde43577adadf6f0f26f3b365ad68
Modified: 2025-01-06
CVE-2023-52877
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm() It is possible that typec_register_partner() returns ERR_PTR on failure. When port->partner is an error, a NULL pointer dereference may occur as shown below. [91222.095236][ T319] typec port0: failed to register partner (-17) ... [91225.061491][ T319] Unable to handle kernel NULL pointer dereference at virtual address 000000000000039f [91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc [91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc [91225.308067][ T319] Call trace: [91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc [91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8 [91225.355900][ T319] kthread_worker_fn+0x178/0x58c [91225.355902][ T319] kthread+0x150/0x200 [91225.355905][ T319] ret_from_fork+0x10/0x30 Add a check for port->partner to avoid dereferencing a NULL pointer.
- https://git.kernel.org/stable/c/4987daf86c152ff882d51572d154ad12e4ff3a4b
- https://git.kernel.org/stable/c/9ee038590d808a95d16adf92818dcd4752273c08
- https://git.kernel.org/stable/c/b37a168c0137156042a0ca9626651b5a789e822b
- https://git.kernel.org/stable/c/e5f53a68a596e04df3fde3099273435a30b6fdac
- https://git.kernel.org/stable/c/e7a802447c491903aa7cb45967aa2a934a4e63fc
- https://git.kernel.org/stable/c/4987daf86c152ff882d51572d154ad12e4ff3a4b
- https://git.kernel.org/stable/c/9ee038590d808a95d16adf92818dcd4752273c08
- https://git.kernel.org/stable/c/b37a168c0137156042a0ca9626651b5a789e822b
- https://git.kernel.org/stable/c/e5f53a68a596e04df3fde3099273435a30b6fdac
- https://git.kernel.org/stable/c/e7a802447c491903aa7cb45967aa2a934a4e63fc
Modified: 2025-03-05
CVE-2023-52878
In the Linux kernel, the following vulnerability has been resolved: can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error.
- https://git.kernel.org/stable/c/0d30931f1fa0fb893fb7d5dc32b6b7edfb775be4
- https://git.kernel.org/stable/c/53c468008a7c9ca3f5fc985951f35ec2acae85bc
- https://git.kernel.org/stable/c/6411959c10fe917288cbb1038886999148560057
- https://git.kernel.org/stable/c/826120c9ba68f2d0dbae58e99013929c883d1444
- https://git.kernel.org/stable/c/8ab67da060157362b2e0926692c659808784708f
- https://git.kernel.org/stable/c/0d30931f1fa0fb893fb7d5dc32b6b7edfb775be4
- https://git.kernel.org/stable/c/53c468008a7c9ca3f5fc985951f35ec2acae85bc
- https://git.kernel.org/stable/c/6411959c10fe917288cbb1038886999148560057
- https://git.kernel.org/stable/c/826120c9ba68f2d0dbae58e99013929c883d1444
- https://git.kernel.org/stable/c/8ab67da060157362b2e0926692c659808784708f
Modified: 2025-09-27
CVE-2023-52881
In the Linux kernel, the following vulnerability has been resolved:
tcp: do not accept ACK of bytes we never sent
This patch is based on a detailed report and ideas from Yepeng Pan
and Christian Rossow.
ACK seq validation is currently following RFC 5961 5.2 guidelines:
The ACK value is considered acceptable only if
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
SND.NXT). All incoming segments whose ACK value doesn't satisfy the
above condition MUST be discarded and an ACK sent back. It needs to
be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
ACK, drop the segment, and return". The "ignored" above implies that
the processing of the incoming data segment continues, which means
the ACK value is treated as acceptable. This mitigation makes the
ACK check more stringent since any ACK < SND.UNA wouldn't be
accepted, instead only ACKs that are in the range ((SND.UNA -
MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
This can be refined for new (and possibly spoofed) flows,
by not accepting ACK for bytes that were never sent.
This greatly improves TCP security at a little cost.
I added a Fixes: tag to make sure this patch will reach stable trees,
even if the 'blamed' patch was adhering to the RFC.
tp->bytes_acked was added in linux-4.2
Following packetdrill test (courtesy of Yepeng Pan) shows
the issue at hand:
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1024) = 0
// ---------------- Handshake ------------------- //
// when window scale is set to 14 the window size can be extended to
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
// ,though this ack number acknowledges some data never
// sent by the server.
+0 < S 0:0(0) win 65535
- https://git.kernel.org/stable/c/008b807fe487e0b15a3a6c39add4eb477f73e440
- https://git.kernel.org/stable/c/0d4e0afdd6658cd21dd5be61880411a2553fd1fc
- https://git.kernel.org/stable/c/2087d53a66e97a5eb5d1bf558d5bef9e5f891757
- https://git.kernel.org/stable/c/3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27
- https://git.kernel.org/stable/c/458f07ffeccd17f99942311e09ef574ddf4a414a
- https://git.kernel.org/stable/c/69eae75ca5255e876628ac5cee9eaab31f644b57
- https://git.kernel.org/stable/c/7ffff0cc929fdfc62a74b384c4903d6496c910f0
- https://git.kernel.org/stable/c/b17a886ed29f3b70b78ccf632dad03e0c69e3c1a
- https://git.kernel.org/stable/c/008b807fe487e0b15a3a6c39add4eb477f73e440
- https://git.kernel.org/stable/c/0d4e0afdd6658cd21dd5be61880411a2553fd1fc
- https://git.kernel.org/stable/c/2087d53a66e97a5eb5d1bf558d5bef9e5f891757
- https://git.kernel.org/stable/c/3d501dd326fb1c73f1b8206d4c6e1d7b15c07e27
- https://git.kernel.org/stable/c/458f07ffeccd17f99942311e09ef574ddf4a414a
- https://git.kernel.org/stable/c/69eae75ca5255e876628ac5cee9eaab31f644b57
- https://git.kernel.org/stable/c/7ffff0cc929fdfc62a74b384c4903d6496c910f0
- https://git.kernel.org/stable/c/b17a886ed29f3b70b78ccf632dad03e0c69e3c1a
Modified: 2024-11-21
CVE-2023-52885
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix UAF in svc_tcp_listen_data_ready()
After the listener svc_sock is freed, and before invoking svc_tcp_accept()
for the established child sock, there is a window that the newsock
retaining a freed listener svc_sock in sk_user_data which cloning from
parent. In the race window, if data is received on the newsock, we will
observe use-after-free report in svc_tcp_listen_data_ready().
Reproduce by two tasks:
1. while :; do rpc.nfsd 0 ; rpc.nfsd; done
2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; done
KASAN report:
==================================================================
BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]
Read of size 8 at addr ffff888139d96228 by task nc/102553
CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
- https://git.kernel.org/stable/c/42725e5c1b181b757ba11d804443922982334d9b
- https://git.kernel.org/stable/c/7e1f989055622fd086c5dfb291fc72adf5660b6f
- https://git.kernel.org/stable/c/c7b8c2d06e437639694abe76978e915cfb73f428
- https://git.kernel.org/stable/c/cd5ec3ee52ce4b7e283cc11facfa420c297c8065
- https://git.kernel.org/stable/c/dfc896c4a75cb8cd7cb2dfd9b469cf1e3f004254
- https://git.kernel.org/stable/c/ef047411887ff0845afd642d6a687819308e1a4e
- https://git.kernel.org/stable/c/fbf4ace39b2e4f3833236afbb2336edbafd75eee
- https://git.kernel.org/stable/c/fc80fc2d4e39137869da3150ee169b40bf879287
- https://git.kernel.org/stable/c/42725e5c1b181b757ba11d804443922982334d9b
- https://git.kernel.org/stable/c/7e1f989055622fd086c5dfb291fc72adf5660b6f
- https://git.kernel.org/stable/c/c7b8c2d06e437639694abe76978e915cfb73f428
- https://git.kernel.org/stable/c/cd5ec3ee52ce4b7e283cc11facfa420c297c8065
- https://git.kernel.org/stable/c/dfc896c4a75cb8cd7cb2dfd9b469cf1e3f004254
- https://git.kernel.org/stable/c/ef047411887ff0845afd642d6a687819308e1a4e
- https://git.kernel.org/stable/c/fbf4ace39b2e4f3833236afbb2336edbafd75eee
- https://git.kernel.org/stable/c/fc80fc2d4e39137869da3150ee169b40bf879287
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-52897
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: do not warn on record without old_roots populated
[BUG]
There are some reports from the mailing list that since v6.1 kernel, the
WARN_ON() inside btrfs_qgroup_account_extent() gets triggered during
rescan:
WARNING: CPU: 3 PID: 6424 at fs/btrfs/qgroup.c:2756 btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]
CPU: 3 PID: 6424 Comm: snapperd Tainted: P OE 6.1.2-1-default #1 openSUSE Tumbleweed 05c7a1b1b61d5627475528f71f50444637b5aad7
RIP: 0010:btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]
Call Trace:
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-52902
In the Linux kernel, the following vulnerability has been resolved: nommu: fix memory leak in do_mmap() error path The preallocation of the maple tree nodes may leak if the error path to "error_just_free" is taken. Fix this by moving the freeing of the maple tree nodes to a shared location for all error paths.
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-52905
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix resource leakage in VF driver unbind resources allocated like mcam entries to support the Ntuple feature and hash tables for the tc feature are not getting freed in driver unbind. This patch fixes the issue.
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: 2024-09-12
CVE-2023-52909
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix handling of cached open files in nfsd4_open codepath Commit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a regular NFSv4 file") added the ability to cache an open fd over a compound. There are a couple of problems with the way this currently works: It's racy, as a newly-created nfsd_file can end up with its PENDING bit cleared while the nf is hashed, and the nf_file pointer is still zeroed out. Other tasks can find it in this state and they expect to see a valid nf_file, and can oops if nf_file is NULL. Also, there is no guarantee that we'll end up creating a new nfsd_file if one is already in the hash. If an extant entry is in the hash with a valid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with the value of op_file and the old nf_file will leak. Fix both issues by making a new nfsd_file_acquirei_opened variant that takes an optional file pointer. If one is present when this is called, we'll take a new reference to it instead of trying to open the file. If the nfsd_file already has a valid nf_file, we'll just ignore the optional file and pass the nfsd_file back as-is. Also rework the tracepoints a bit to allow for an "opened" variant and don't try to avoid counting acquisitions in the case where we already have a cached open file.
Modified: 2024-09-12
CVE-2023-52910
In the Linux kernel, the following vulnerability has been resolved: iommu/iova: Fix alloc iova overflows issue In __alloc_and_insert_iova_range, there is an issue that retry_pfn overflows. The value of iovad->anchor.pfn_hi is ~0UL, then when iovad->cached_node is iovad->anchor, curr_iova->pfn_hi + 1 will overflow. As a result, if the retry logic is executed, low_pfn is updated to 0, and then new_pfn < low_pfn returns false to make the allocation successful. This issue occurs in the following two situations: 1. The first iova size exceeds the domain size. When initializing iova domain, iovad->cached_node is assigned as iovad->anchor. For example, the iova domain size is 10M, start_pfn is 0x1_F000_0000, and the iova size allocated for the first time is 11M. The following is the log information, new->pfn_lo is smaller than iovad->cached_node. Example log as follows: [ 223.798112][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00 [ 223.799590][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range success start_pfn:0x1f0000,new->pfn_lo:0x1efe00,new->pfn_hi:0x1f08ff 2. The node with the largest iova->pfn_lo value in the iova domain is deleted, iovad->cached_node will be updated to iovad->anchor, and then the alloc iova size exceeds the maximum iova size that can be allocated in the domain. After judging that retry_pfn is less than limit_pfn, call retry_pfn+1 to fix the overflow issue.
Modified: 2024-09-12
CVE-2023-52911
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: another fix for the headless Adreno GPU
Fix another oops reproducible when rebooting the board with the Adreno
GPU working in the headless mode (e.g. iMX platforms).
Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[00000000] *pgd=74936831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] ARM
CPU: 0 PID: 51 Comm: reboot Not tainted 6.2.0-rc1-dirty #11
Hardware name: Freescale i.MX53 (Device Tree Support)
PC is at msm_atomic_commit_tail+0x50/0x970
LR is at commit_tail+0x9c/0x188
pc : [
Modified: 2024-09-12
CVE-2023-52912
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fixed bug on error when unloading amdgpu
Fixed bug on error when unloading amdgpu.
The error message is as follows:
[ 377.706202] kernel BUG at drivers/gpu/drm/drm_buddy.c:278!
[ 377.706215] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 377.706222] CPU: 4 PID: 8610 Comm: modprobe Tainted: G IOE 6.0.0-thomas #1
[ 377.706231] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 11/02/2021
[ 377.706238] RIP: 0010:drm_buddy_free_block+0x26/0x30 [drm_buddy]
[ 377.706264] Code: 00 00 00 90 0f 1f 44 00 00 48 8b 0e 89 c8 25 00 0c 00 00 3d 00 04 00 00 75 10 48 8b 47 18 48 d3 e0 48 01 47 28 e9 fa fe ff ff <0f> 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 48 89 f5 53
[ 377.706282] RSP: 0018:ffffad2dc4683cb8 EFLAGS: 00010287
[ 377.706289] RAX: 0000000000000000 RBX: ffff8b1743bd5138 RCX: 0000000000000000
[ 377.706297] RDX: ffff8b1743bd5160 RSI: ffff8b1743bd5c78 RDI: ffff8b16d1b25f70
[ 377.706304] RBP: ffff8b1743bd59e0 R08: 0000000000000001 R09: 0000000000000001
[ 377.706311] R10: ffff8b16c8572400 R11: ffffad2dc4683cf0 R12: ffff8b16d1b25f70
[ 377.706318] R13: ffff8b16d1b25fd0 R14: ffff8b1743bd59c0 R15: ffff8b16d1b25f70
[ 377.706325] FS: 00007fec56c72c40(0000) GS:ffff8b1836500000(0000) knlGS:0000000000000000
[ 377.706334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 377.706340] CR2: 00007f9b88c1ba50 CR3: 0000000110450004 CR4: 00000000003706e0
[ 377.706347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 377.706354] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 377.706361] Call Trace:
[ 377.706365]
Modified: 2024-11-08
CVE-2023-52913
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)
Modified: 2024-09-12
CVE-2023-52914
In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: add hash if ready poll request can't complete inline If we don't, then we may lose access to it completely, leading to a request leak. This will eventually stall the ring exit process as well.
Modified: 2024-09-10
CVE-2023-52915
In the Linux kernel, the following vulnerability has been resolved: media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
- https://git.kernel.org/stable/c/0143f282b15f7cedc0392ea10050fb6000fd16e6
- https://git.kernel.org/stable/c/41b7181a40af84448a2b144fb02d8bf32b7e9a23
- https://git.kernel.org/stable/c/6c01ef65de0b321b2db1ef9abf8f1d15862b937e
- https://git.kernel.org/stable/c/7bf744f2de0a848fb1d717f5831b03db96feae89
- https://git.kernel.org/stable/c/b2f54ed7739dfdf42c4df0a11131aad7c8635464
- https://git.kernel.org/stable/c/b49c6e5dd236787f13a062ec528d724169f11152
- https://git.kernel.org/stable/c/d9ef84a7c222497ecb5fdf93361c76931804825e
- https://git.kernel.org/stable/c/fa58d9db5cad4bb7bb694b6837e3b96d87554f2b
Modified: 2024-10-24
CVE-2023-52919
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.
- https://git.kernel.org/stable/c/2b2edf089df3a69f0072c6e71563394c5a94e62e
- https://git.kernel.org/stable/c/5622592f8f74ae3e594379af02e64ea84772d0dd
- https://git.kernel.org/stable/c/76050b0cc5a72e0c7493287b7e18e1cb9e3c4612
- https://git.kernel.org/stable/c/7937609cd387246aed994e81aa4fa951358fba41
- https://git.kernel.org/stable/c/bb6cacc439ddd2cd51227ab193f4f91cfc7f014f
- https://git.kernel.org/stable/c/c95fa5b20fe03609e0894656fa43c18045b5097e
- https://git.kernel.org/stable/c/d7dbdbe3800a908eecd4975c31be47dd45e2104a
- https://git.kernel.org/stable/c/ffdc881f68073ff86bf21afb9bb954812e8278be
Modified: 2025-06-19
CVE-2023-52921
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix possible UAF in amdgpu_cs_pass1() Since the gang_size check is outside of chunk parsing loop, we need to reset i before we free the chunk data. Suggested by Ye Zhang (@VAR10CK) of Baidu Security.
Modified: 2025-06-13
CVE-2023-52922
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: Fix UAF in bcm_proc_show()
BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80
Read of size 8 at addr ffff888155846230 by task cat/7862
CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/11b8e27ed448baa385d90154a141466bd5e92f18
- https://git.kernel.org/stable/c/3c3941bb1eb53abe7d640ffee5c4d6b559829ab3
- https://git.kernel.org/stable/c/55c3b96074f3f9b0aee19bf93cd71af7516582bb
- https://git.kernel.org/stable/c/9533dbfac0ff7edd77a5fa2c24974b1d66c8b0a6
- https://git.kernel.org/stable/c/995f47d76647708ec26c6e388663ad4f3f264787
- https://git.kernel.org/stable/c/9b58d36d0c1ea29a9571e0222a9c29df0ccfb7ff
- https://git.kernel.org/stable/c/cf254b4f68e480e73dab055014e002b77aed30ed
- https://git.kernel.org/stable/c/dfd0aa26e9a07f2ce546ccf8304ead6a2914e8a7
- https://allelesecurity.com/use-after-free-vulnerability-in-can-bcm-subsystem-leading-to-information-disclosure-cve-2023-52922/
Modified: 2025-10-15
CVE-2023-52923
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: adapt set backend to use GC transaction API Use the GC transaction API to replace the old and buggy gc API and the busy mark approach. No set elements are removed from async garbage collection anymore, instead the _DEAD bit is set on so the set element is not visible from lookup path anymore. Async GC enqueues transaction work that might be aborted and retried later. rbtree and pipapo set backends does not set on the _DEAD bit from the sync GC path since this runs in control plane path where mutex is held. In this case, set elements are deactivated, removed and then released via RCU callback, sync GC never fails.
- https://git.kernel.org/stable/c/146c76866795553dbc19998f36718d7986ad302b
- https://git.kernel.org/stable/c/479a2cf5259347d6a1f658b0f791d27a34908e91
- https://git.kernel.org/stable/c/c357648929c8dff891502349769aafb8f0452bc2
- https://git.kernel.org/stable/c/cb4d00b563675ba8ff6ef94b077f58d816f68ba3
- https://git.kernel.org/stable/c/df650d6a4bf47248261b61ef6b174d7c54034d15
- https://git.kernel.org/stable/c/e4d71d6a9c7db93f7bf20c3a0f0659d63d7de681
- https://git.kernel.org/stable/c/f6c383b8c31a93752a52697f8430a71dcbc46adf
Modified: 2025-10-15
CVE-2023-52924
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: don't skip expired elements during walk There is an asymmetry between commit/abort and preparation phase if the following conditions are met: 1. set is a verdict map ("1.2.3.4 : jump foo") 2. timeouts are enabled In this case, following sequence is problematic: 1. element E in set S refers to chain C 2. userspace requests removal of set S 3. kernel does a set walk to decrement chain->use count for all elements from preparation phase 4. kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase) If E has already expired in 1), it will be ignored during list walk, so its use count won't have been changed. Then, when set is culled, ->destroy callback will zap the element via nf_tables_set_elem_destroy(), but this function is only safe for elements that have been deactivated earlier from the preparation phase: lack of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain gets removed later, plus a leak of the nft_chain structure. Update pipapo_get() not to skip expired elements, otherwise flush command reports bogus ENOENT errors.
- https://git.kernel.org/stable/c/1da4874d05da1526b11b82fc7f3c7ac38749ddf8
- https://git.kernel.org/stable/c/24138933b97b055d486e8064b4a1721702442a9b
- https://git.kernel.org/stable/c/59dab3bf0b8fc08eb802721c0532f13dd89209b8
- https://git.kernel.org/stable/c/7c7e658a36f8b1522bd3586d8137e5f93a25ddc5
- https://git.kernel.org/stable/c/94313a196b44184b5b52c1876da6a537701b425a
- https://git.kernel.org/stable/c/b15ea4017af82011dd55225ce77cce3d4dfc169c
- https://git.kernel.org/stable/c/bd156ce9553dcaf2d6ee2c825d1a5a1718e86524
Modified: 2025-10-29
CVE-2023-52928
In the Linux kernel, the following vulnerability has been resolved: bpf: Skip invalid kfunc call in backtrack_insn The verifier skips invalid kfunc call in check_kfunc_call(), which would be captured in fixup_kfunc_call() if such insn is not eliminated by dead code elimination. However, this can lead to the following warning in backtrack_insn(), also see [1]: ------------[ cut here ]------------ verifier backtracking bug WARNING: CPU: 6 PID: 8646 at kernel/bpf/verifier.c:2756 backtrack_insn kernel/bpf/verifier.c:2756 __mark_chain_precision kernel/bpf/verifier.c:3065 mark_chain_precision kernel/bpf/verifier.c:3165 adjust_reg_min_max_vals kernel/bpf/verifier.c:10715 check_alu_op kernel/bpf/verifier.c:10928 do_check kernel/bpf/verifier.c:13821 [inline] do_check_common kernel/bpf/verifier.c:16289 [...] So make backtracking conservative with this by returning ENOTSUPP. [1] https://lore.kernel.org/bpf/CACkBjsaXNceR8ZjkLG=dT3P=4A8SBsg0Z5h5PWLryF5=ghKq=g@mail.gmail.com/
Modified: 2025-10-28
CVE-2023-52929
In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix cleanup after dev_set_name() If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not put this. While a minimal fix for this would be to add the gpiod_put() call, we can do better if we split device_register(), and use the tested nvmem_release() cleanup code by initialising the device early, and putting the device. This results in a slightly larger fix, but results in clear code. Note: this patch depends on "nvmem: core: initialise nvmem->id early" and "nvmem: core: remove nvmem_config wp_gpio". [Srini: Fixed subject line and error code handing with wp_gpio while applying.]
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-04-01
CVE-2023-52931
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Avoid potential vm use-after-free Adding the vm to the vm_xa table makes it visible to userspace, which could try to race with us to close the vm. So we need to take our extra reference before putting it in the table. (cherry picked from commit 99343c46d4e2b34c285d3d5f68ff04274c2f9fb4)
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-10-28
CVE-2023-52934
In the Linux kernel, the following vulnerability has been resolved: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups In commit 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE") we make the following change to find_pmd_or_thp_or_none(): - if (!pmd_present(pmde)) - return SCAN_PMD_NULL; + if (pmd_none(pmde)) + return SCAN_PMD_NONE; This was for-use by MADV_COLLAPSE file/shmem codepaths, where MADV_COLLAPSE might identify a pte-mapped hugepage, only to have khugepaged race-in, free the pte table, and clear the pmd. Such codepaths include: A) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER already in the pagecache. B) In retract_page_tables(), if we fail to grab mmap_lock for the target mm/address. In these cases, collapse_pte_mapped_thp() really does expect a none (not just !present) pmd, and we want to suitably identify that case separate from the case where no pmd is found, or it's a bad-pmd (of course, many things could happen once we drop mmap_lock, and the pmd could plausibly undergo multiple transitions due to intervening fault, split, etc). Regardless, the code is prepared install a huge-pmd only when the existing pmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd. However, the commit introduces a logical hole; namely, that we've allowed !none- && !huge- && !bad-pmds to be classified as genuine pte-table-mapping-pmds. One such example that could leak through are swap entries. The pmd values aren't checked again before use in pte_offset_map_lock(), which is expecting nothing less than a genuine pte-table-mapping-pmd. We want to put back the !pmd_present() check (below the pmd_none() check), but need to be careful to deal with subtleties in pmd transitions and treatments by various arch. The issue is that __split_huge_pmd_locked() temporarily clears the present bit (or otherwise marks the entry as invalid), but pmd_present() and pmd_trans_huge() still need to return true while the pmd is in this transitory state. For example, x86's pmd_present() also checks the _PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also checks a PMD_PRESENT_INVALID bit. Covering all 4 cases for x86 (all checks done on the same pmd value): 1) pmd_present() && pmd_trans_huge() All we actually know here is that the PSE bit is set. Either: a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE is set. => huge-pmd b) We are currently racing with __split_huge_page(). The danger here is that we proceed as-if we have a huge-pmd, but really we are looking at a pte-mapping-pmd. So, what is the risk of this danger? The only relevant path is: madvise_collapse() -> collapse_pte_mapped_thp() Where we might just incorrectly report back "success", when really the memory isn't pmd-backed. This is fine, since split could happen immediately after (actually) successful madvise_collapse(). So, it should be safe to just assume huge-pmd here. 2) pmd_present() && !pmd_trans_huge() Either: a) PSE not set and either PRESENT or PROTNONE is. => pte-table-mapping pmd (or PROT_NONE) b) devmap. This routine can be called immediately after unlocking/locking mmap_lock -- or called with no locks held (see khugepaged_scan_mm_slot()), so previous VMA checks have since been invalidated. 3) !pmd_present() && pmd_trans_huge() Not possible. 4) !pmd_present() && !pmd_trans_huge() Neither PRESENT nor PROTNONE set => not present I've checked all archs that implement pmd_trans_huge() (arm64, riscv, powerpc, longarch, x86, mips, s390) and this logic roughly translates (though devmap treatment is unique to x86 and powerpc, and (3) doesn't necessarily hold in general -- but that doesn't matter since !pmd_present() always takes failure path). Also, add a comment above find_pmd_or_thp_or_none() ---truncated---
Modified: 2025-11-25
CVE-2023-52935
In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: fix ->anon_vma race If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked. Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but does this check before holding the mmap lock (as the comment above the check explains). If we racily merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap traversals on pages belonging to the child will be able to see the page tables that we are concurrently removing while assuming that nothing else can access them. Repeat the ->anon_vma check once we hold the mmap lock to ensure that there really is no concurrent page table access. Hitting this bug causes a lockdep warning in collapse_and_free_pmd(), in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)". It can also lead to use-after-free access.
- https://git.kernel.org/stable/c/023f47a8250c6bdb4aebe744db4bf7f73414028b
- https://git.kernel.org/stable/c/352fbf61ce776fef18dca6a68680a6cd943dac95
- https://git.kernel.org/stable/c/abdf3c33918185c3e8ffeb09ed3e334b3d7df47c
- https://git.kernel.org/stable/c/acb08187b5a83cdb9ac4112fae9e18cf983b0128
- https://git.kernel.org/stable/c/cee956ab1efbd858b4ca61c8b474af5aa24b29a6
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-10-01
CVE-2023-52936
In the Linux kernel, the following vulnerability has been resolved: kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2025-10-01
CVE-2023-52937
In the Linux kernel, the following vulnerability has been resolved: HV: hv_balloon: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2025-10-01
CVE-2023-52939
In the Linux kernel, the following vulnerability has been resolved: mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath() As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"), hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could occurs a NULL pointer dereference, let's do not record the foreign writebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to fix it.
Modified: 2025-10-28
CVE-2023-52940
In the Linux kernel, the following vulnerability has been resolved: mm: multi-gen LRU: fix crash during cgroup migration lru_gen_migrate_mm() assumes lru_gen_add_mm() runs prior to itself. This isn't true for the following scenario: CPU 1 CPU 2 clone() cgroup_can_fork() cgroup_procs_write() cgroup_post_fork() task_lock() lru_gen_migrate_mm() task_unlock() task_lock() lru_gen_add_mm() task_unlock() And when the above happens, kernel crashes because of linked list corruption (mm_struct->lru_gen.list).
Modified: 2025-10-28
CVE-2023-52942
In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask() It was found that the check to see if a partition could use up all the cpus from the parent cpuset in update_parent_subparts_cpumask() was incorrect. As a result, it is possible to leave parent with no effective cpu left even if there are tasks in the parent cpuset. This can lead to system panic as reported in [1]. Fix this probem by updating the check to fail the enabling the partition if parent's effective_cpus is a subset of the child's cpus_allowed. Also record the error code when an error happens in update_prstate() and add a test case where parent partition and child have the same cpu list and parent has task. Enabling partition in the child will fail in this case. [1] https://www.spinics.net/lists/cgroups/msg36254.html
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: 2026-04-01
CVE-2023-52975
In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress
Bug report and analysis from Ding Hui.
During iSCSI session logout, if another task accesses the shost ipaddress
attr, we can get a KASAN UAF report like this:
[ 276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0
[ 276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088
[ 276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G E 6.1.0-rc8+ #3
[ 276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[ 276.944470] Call Trace:
[ 276.944943]
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-52978
In the Linux kernel, the following vulnerability has been resolved:
riscv: kprobe: Fixup kernel panic when probing an illegal position
The kernel would panic when probed for an illegal position. eg:
(CONFIG_RISCV_ISA_C=n)
echo 'p:hello kernel_clone+0x16 a0=%a0' >> kprobe_events
echo 1 > events/kprobes/hello/enable
cat trace
Kernel panic - not syncing: stack-protector: Kernel stack
is corrupted in: __do_sys_newfstatat+0xb8/0xb8
CPU: 0 PID: 111 Comm: sh Not tainted
6.2.0-rc1-00027-g2d398fe49a4d #490
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[
Modified: 2025-10-28
CVE-2023-52980
In the Linux kernel, the following vulnerability has been resolved: block: ublk: extending queue_size to fix overflow When validating drafted SPDK ublk target, in a case that assigning large queue depth to multiqueue ublk device, ublk target would run into a weird incorrect state. During rounds of review and debug, An overflow bug was found in ublk driver. In ublk_cmd.h, UBLK_MAX_QUEUE_DEPTH is 4096 which means each ublk queue depth can be set as large as 4096. But when setting qd for a ublk device, sizeof(struct ublk_queue) + depth * sizeof(struct ublk_io) will be larger than 65535 if qd is larger than 2728. Then queue_size is overflowed, and ublk_get_queue() references a wrong pointer position. The wrong content of ublk_queue elements will lead to out-of-bounds memory access. Extend queue_size in ublk_device as "unsigned int".
Modified: 2025-10-28
CVE-2023-52981
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix request ref counting during error capture & debugfs dump When GuC support was added to error capture, the reference counting around the request object was broken. Fix it up. The context based search manages the spinlocking around the search internally. So it needs to grab the reference count internally as well. The execlist only request based search relies on external locking, so it needs an external reference count but within the spinlock not outside it. The only other caller of the context based search is the code for dumping engine state to debugfs. That code wasn't previously getting an explicit reference at all as it does everything while holding the execlist specific spinlock. So, that needs updaing as well as that spinlock doesn't help when using GuC submission. Rather than trying to conditionally get/put depending on submission model, just change it to always do the get/put. v2: Explicitly document adding an extra blank line in some dense code (Andy Shevchenko). Fix multiple potential null pointer derefs in case of no request found (some spotted by Tvrtko, but there was more!). Also fix a leaked request in case of !started and another in __guc_reset_context now that intel_context_find_active_request is actually reference counting the returned request. v3: Add a _get suffix to intel_context_find_active_request now that it grabs a reference (Daniele). v4: Split the intel_guc_find_hung_context change to a separate patch and rename intel_context_find_active_request_get to intel_context_get_active_request (Tvrtko). v5: s/locking/reference counting/ in commit message (Tvrtko) (cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)
Modified: 2025-10-28
CVE-2023-52982
In the Linux kernel, the following vulnerability has been resolved:
fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
The freeing of relinquished volume will wake up the pending volume
acquisition by using wake_up_bit(), however it is mismatched with
wait_var_event() used in fscache_wait_on_volume_collision() and it will
never wake up the waiter in the wait-queue because these two functions
operate on different wait-queues.
According to the implementation in fscache_wait_on_volume_collision(),
if the wake-up of pending acquisition is delayed longer than 20 seconds
(e.g., due to the delay of on-demand fd closing), the first
wait_var_event_timeout() will timeout and the following wait_var_event()
will hang forever as shown below:
FS-Cache: Potential volume collision new=00000024 old=00000022
......
INFO: task mount:1148 blocked for more than 122 seconds.
Not tainted 6.1.0-rc6+ #1
task:mount state:D stack:0 pid:1148 ppid:1
Call Trace:
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-52985
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8mm-verdin: Do not power down eth-phy Currently if suspending using either freeze or memory state, the fec driver tries to power down the phy which leads to crash of the kernel and non-responsible kernel with the following call trace: [ 24.839889 ] Call trace: [ 24.839892 ] phy_error+0x18/0x60 [ 24.839898 ] kszphy_handle_interrupt+0x6c/0x80 [ 24.839903 ] phy_interrupt+0x20/0x2c [ 24.839909 ] irq_thread_fn+0x30/0xa0 [ 24.839919 ] irq_thread+0x178/0x2c0 [ 24.839925 ] kthread+0x154/0x160 [ 24.839932 ] ret_from_fork+0x10/0x20 Since there is currently no functionality in the phy subsystem to power down phys let's just disable the feature of powering-down the ethernet phy.
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-29
CVE-2023-52987
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-mtrace: prevent underflow in sof_ipc4_priority_mask_dfs_write() The "id" comes from the user. Change the type to unsigned to prevent an array underflow.
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-29
CVE-2023-52995
In the Linux kernel, the following vulnerability has been resolved:
riscv/kprobe: Fix instruction simulation of JALR
Set kprobe at 'jalr 1140(ra)' of vfs_write results in the following
crash:
[ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170
[ 32.093115] Oops [#1]
[ 32.093251] Modules linked in:
[ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16
[ 32.093985] Hardware name: riscv-virtio,qemu (DT)
[ 32.094280] epc : ksys_read+0x88/0xd6
[ 32.094855] ra : ksys_read+0xc0/0xd6
[ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0
[ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80
[ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60
[ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708
[ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300
[ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff
[ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170
[ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030
[ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410
[ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c
[ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54
[ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d
[ 32.098011] [
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-10-29
CVE-2023-52998
In the Linux kernel, the following vulnerability has been resolved: net: fec: Use page_pool_put_full_page when freeing rx buffers The page_pool_release_page was used when freeing rx buffers, and this function just unmaps the page (if mapped) and does not recycle the page. So after hundreds of down/up the eth0, the system will out of memory. For more details, please refer to the following reproduce steps and bug logs. To solve this issue and refer to the doc of page pool, the page_pool_put_full_page should be used to replace page_pool_release_page. Because this API will try to recycle the page if the page refcnt equal to 1. After testing 20000 times, the issue can not be reproduced anymore (about testing 391 times the issue will occur on i.MX8MN-EVK before). Reproduce steps: Create the test script and run the script. The script content is as follows: LOOPS=20000 i=1 while [ $i -le $LOOPS ] do echo "TINFO:ENET $curface up and down test $i times" org_macaddr=$(cat /sys/class/net/eth0/address) ifconfig eth0 down ifconfig eth0 hw ether $org_macaddr up i=$(expr $i + 1) done sleep 5 if cat /sys/class/net/eth0/operstate | grep 'up';then echo "TEST PASS" else echo "TEST FAIL" fi Bug detail logs: TINFO:ENET up and down test 391 times [ 850.471205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 853.535318] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 853.541694] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 870.590531] page_pool_release_retry() stalled pool shutdown 199 inflight 60 sec [ 931.006557] page_pool_release_retry() stalled pool shutdown 199 inflight 120 sec TINFO:ENET up and down test 392 times [ 991.426544] page_pool_release_retry() stalled pool shutdown 192 inflight 181 sec [ 1051.838531] page_pool_release_retry() stalled pool shutdown 170 inflight 241 sec [ 1093.751217] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 1096.446520] page_pool_release_retry() stalled pool shutdown 308 inflight 60 sec [ 1096.831245] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 1096.839092] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 1112.254526] page_pool_release_retry() stalled pool shutdown 103 inflight 302 sec [ 1156.862533] page_pool_release_retry() stalled pool shutdown 308 inflight 120 sec [ 1172.674516] page_pool_release_retry() stalled pool shutdown 103 inflight 362 sec [ 1217.278532] page_pool_release_retry() stalled pool shutdown 308 inflight 181 sec TINFO:ENET up and down test 393 times [ 1233.086535] page_pool_release_retry() stalled pool shutdown 103 inflight 422 sec [ 1277.698513] page_pool_release_retry() stalled pool shutdown 308 inflight 241 sec [ 1293.502525] page_pool_release_retry() stalled pool shutdown 86 inflight 483 sec [ 1338.110518] page_pool_release_retry() stalled pool shutdown 308 inflight 302 sec [ 1353.918540] page_pool_release_retry() stalled pool shutdown 32 inflight 543 sec [ 1361.179205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [ 1364.255298] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 1364.263189] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 1371.998532] page_pool_release_retry() stalled pool shutdown 310 inflight 60 sec [ 1398.530542] page_pool_release_retry() stalled pool shutdown 308 inflight 362 sec [ 1414.334539] page_pool_release_retry() stalled pool shutdown 16 inflight 604 sec [ 1432.414520] page_pool_release_retry() stalled pool shutdown 310 inflight 120 sec [ 1458.942523] page_pool_release_retry() stalled pool shutdown 308 inflight 422 sec [ 1474.750521] page_pool_release_retry() stalled pool shutdown 16 inflight 664 sec TINFO:ENET up and down test 394 times [ 1492.8305 ---truncated---
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-10-01
CVE-2023-53002
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix a memory leak with reused mmap_offset drm_vma_node_allow() and drm_vma_node_revoke() should be called in balanced pairs. We call drm_vma_node_allow() once per-file everytime a user calls mmap_offset, but only call drm_vma_node_revoke once per-file on each mmap_offset. As the mmap_offset is reused by the client, the per-file vm_count may remain non-zero and the rbtree leaked. Call drm_vma_node_allow_once() instead to prevent that memory leak.
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-30
CVE-2023-53004
In the Linux kernel, the following vulnerability has been resolved: ovl: fix tmpfile leak Missed an error cleanup.
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-53008
In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential memory leaks in session setup Make sure to free cifs_ses::auth_key.response before allocating it as we might end up leaking memory in reconnect or mounting.
Modified: 2025-10-30
CVE-2023-53009
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Add sync after creating vram bo There will be data corruption on vram allocated by svm if the initialization is not complete and application is writting on the memory. Adding sync to wait for the initialization completion is to resolve this issue.
Modified: 2025-10-30
CVE-2023-53010
In the Linux kernel, the following vulnerability has been resolved: bnxt: Do not read past the end of test names Test names were being concatenated based on a offset beyond the end of the first name, which tripped the buffer overflow detection logic: detected buffer overflow in strnlen [...] Call Trace: bnxt_ethtool_init.cold+0x18/0x18 Refactor struct hwrm_selftest_qlist_output to use an actual array, and adjust the concatenation to use snprintf() rather than a series of strncat() calls.
Modified: 2025-10-01
CVE-2023-53011
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: enable all safety features by default In the original implementation of dwmac5 commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features") all safety features were enabled by default. Later it seems some implementations didn't have support for all the features, so in commit 5ac712dcdfef ("net: stmmac: enable platform specific safety features") the safety_feat_cfg structure was added to the callback and defined for some platforms to selectively enable these safety features. The problem is that only certain platforms were given that software support. If the automotive safety package bit is set in the hardware features register the safety feature callback is called for the platform, and for platforms that didn't get a safety_feat_cfg defined this results in the following NULL pointer dereference: [ 7.933303] Call trace: [ 7.935812] dwmac5_safety_feat_config+0x20/0x170 [stmmac] [ 7.941455] __stmmac_open+0x16c/0x474 [stmmac] [ 7.946117] stmmac_open+0x38/0x70 [stmmac] [ 7.950414] __dev_open+0x100/0x1dc [ 7.954006] __dev_change_flags+0x18c/0x204 [ 7.958297] dev_change_flags+0x24/0x6c [ 7.962237] do_setlink+0x2b8/0xfa4 [ 7.965827] __rtnl_newlink+0x4ec/0x840 [ 7.969766] rtnl_newlink+0x50/0x80 [ 7.973353] rtnetlink_rcv_msg+0x12c/0x374 [ 7.977557] netlink_rcv_skb+0x5c/0x130 [ 7.981500] rtnetlink_rcv+0x18/0x2c [ 7.985172] netlink_unicast+0x2e8/0x340 [ 7.989197] netlink_sendmsg+0x1a8/0x420 [ 7.993222] ____sys_sendmsg+0x218/0x280 [ 7.997249] ___sys_sendmsg+0xac/0x100 [ 8.001103] __sys_sendmsg+0x84/0xe0 [ 8.004776] __arm64_sys_sendmsg+0x24/0x30 [ 8.008983] invoke_syscall+0x48/0x114 [ 8.012840] el0_svc_common.constprop.0+0xcc/0xec [ 8.017665] do_el0_svc+0x38/0xb0 [ 8.021071] el0_svc+0x2c/0x84 [ 8.024212] el0t_64_sync_handler+0xf4/0x120 [ 8.028598] el0t_64_sync+0x190/0x194 Go back to the original behavior, if the automotive safety package is found to be supported in hardware enable all the features unless safety_feat_cfg is passed in saying this particular platform only supports a subset of the features.
Modified: 2025-10-01
CVE-2023-53013
In the Linux kernel, the following vulnerability has been resolved: ptdma: pt_core_execute_cmd() should use spinlock The interrupt handler (pt_core_irq_handler()) of the ptdma driver can be called from interrupt context. The code flow in this function can lead down to pt_core_execute_cmd() which will attempt to grab a mutex, which is not appropriate in interrupt context and ultimately leads to a kernel panic. The fix here changes this mutex to a spinlock, which has been verified to resolve the issue.
Modified: 2025-10-01
CVE-2023-53014
In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra: Fix memory leak in terminate_all() Terminate vdesc when terminating an ongoing transfer. This will ensure that the vdesc is present in the desc_terminated list The descriptor will be freed later in desc_free_list(). This fixes the memory leaks which can happen when terminating an ongoing transfer.
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-01
CVE-2023-53016
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix possible deadlock in rfcomm_sk_state_change syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow: rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock() rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk) This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes.
Modified: 2025-10-01
CVE-2023-53017
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix memory leak in hci_update_adv_data() When hci_cmd_sync_queue() failed in hci_update_adv_data(), inst_ptr is not freed, which will cause memory leak, convert to use ERR_PTR/PTR_ERR to pass the instance to callback so no memory needs to be allocated.
Modified: 2025-10-01
CVE-2023-53018
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix memory leaks When hci_cmd_sync_queue() failed in hci_le_terminate_big() or hci_le_big_terminate(), the memory pointed by variable d is not freed, which will cause memory leak. Add release process to error path.
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-10-01
CVE-2023-53022
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()
This lockdep splat says it better than I could:
================================
WARNING: inconsistent lock state
6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0
{IN-SOFTIRQ-W} state was registered at:
_raw_spin_lock+0x5c/0xc0
sch_direct_xmit+0x148/0x37c
__dev_queue_xmit+0x528/0x111c
ip6_finish_output2+0x5ec/0xb7c
ip6_finish_output+0x240/0x3f0
ip6_output+0x78/0x360
ndisc_send_skb+0x33c/0x85c
ndisc_send_rs+0x54/0x12c
addrconf_rs_timer+0x154/0x260
call_timer_fn+0xb8/0x3a0
__run_timers.part.0+0x214/0x26c
run_timer_softirq+0x3c/0x74
__do_softirq+0x14c/0x5d8
____do_softirq+0x10/0x20
call_on_irq_stack+0x2c/0x5c
do_softirq_own_stack+0x1c/0x30
__irq_exit_rcu+0x168/0x1a0
irq_exit_rcu+0x10/0x40
el1_interrupt+0x38/0x64
irq event stamp: 7825
hardirqs last enabled at (7825): [
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-03-17
CVE-2023-53035
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy() The ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a metadata array to/from user space, may copy uninitialized buffer regions to user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO and NILFS_IOCTL_GET_CPINFO. This can occur when the element size of the user space metadata given by the v_size member of the argument nilfs_argv structure is larger than the size of the metadata element (nilfs_suinfo structure or nilfs_cpinfo structure) on the file system side. KMSAN-enabled kernels detect this issue as follows: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xc0/0x100 lib/usercopy.c:33 instrument_copy_to_user include/linux/instrumented.h:121 [inline] _copy_to_user+0xc0/0x100 lib/usercopy.c:33 copy_to_user include/linux/uaccess.h:169 [inline] nilfs_ioctl_wrap_copy+0x6fa/0xc10 fs/nilfs2/ioctl.c:99 nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline] nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290 nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343 __do_compat_sys_ioctl fs/ioctl.c:968 [inline] __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910 __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9f6/0xe90 mm/page_alloc.c:5572 alloc_pages+0xab0/0xd80 mm/mempolicy.c:2287 __get_free_pages+0x34/0xc0 mm/page_alloc.c:5599 nilfs_ioctl_wrap_copy+0x223/0xc10 fs/nilfs2/ioctl.c:74 nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline] nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290 nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343 __do_compat_sys_ioctl fs/ioctl.c:968 [inline] __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910 __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Bytes 16-127 of 3968 are uninitialized ... This eliminates the leak issue by initializing the page allocated as buffer using get_zeroed_page().
- https://git.kernel.org/stable/c/003587000276f81d0114b5ce773d80c119d8cb30
- https://git.kernel.org/stable/c/5bb105cc72beb9d51bf12f5c657336d2d35bdc5d
- https://git.kernel.org/stable/c/5f33b042f74fc9662eba17f4cd19b07d84bbc6c5
- https://git.kernel.org/stable/c/8a6550b365c0ce2e65905de57dcbfe1f7d629726
- https://git.kernel.org/stable/c/8f5cbf6a8c0e19b062b829c5b7aca01468bb57f6
- https://git.kernel.org/stable/c/9c5034e9a0e03db8d5e9eabb176340259b5b97e4
- https://git.kernel.org/stable/c/a94932381e8dae4117e9129b3c1282e18aa97b05
- https://git.kernel.org/stable/c/d18db946cc6a394291539e030df32324285648f7
Modified: 2025-11-12
CVE-2023-53036
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix call trace warning and hang when removing amdgpu device
On GPUs with RAS enabled, below call trace and hang are observed when
shutting down device.
v2: use DRM device unplugged flag instead of shutdown flag as the check to
prevent memory wipe in shutdown stage.
[ +0.000000] RIP: 0010:amdgpu_vram_mgr_fini+0x18d/0x1c0 [amdgpu]
[ +0.000001] PKRU: 55555554
[ +0.000001] Call Trace:
[ +0.000001]
Modified: 2025-11-12
CVE-2023-53037
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Bad drive in topology results kernel crash When the SAS Transport Layer support is enabled and a device exposed to the OS by the driver fails INQUIRY commands, the driver frees up the memory allocated for an internal HBA port data structure. However, in some places, the reference to the freed memory is not cleared. When the firmware sends the Device Info change event for the same device again, the freed memory is accessed and that leads to memory corruption and OS crash.
Modified: 2025-11-12
CVE-2023-53038
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read() If kzalloc() fails in lpfc_sli4_cgn_params_read(), then we rely on lpfc_read_object()'s routine to NULL check pdata. Currently, an early return error is thrown from lpfc_read_object() to protect us from NULL ptr dereference, but the errno code is -ENODEV. Change the errno code to a more appropriate -ENOMEM.
Modified: 2025-11-12
CVE-2023-53039
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Fix potential use-after-free in work function When a reset notify IPC message is received, the ISR schedules a work function and passes the ISHTP device to it via a global pointer ishtp_dev. If ish_probe() fails, the devm-managed device resources including ishtp_dev are freed, but the work is not cancelled, causing a use-after-free when the work function tries to access ishtp_dev. Use devm_work_autocancel() instead, so that the work is automatically cancelled if probe fails.
Modified: 2025-11-12
CVE-2023-53040
In the Linux kernel, the following vulnerability has been resolved: ca8210: fix mac_len negative array access This patch fixes a buffer overflow access of skb->data if ieee802154_hdr_peek_addrs() fails.
- https://git.kernel.org/stable/c/55d836f75778d2e2cafe37e023f9c106400bad4b
- https://git.kernel.org/stable/c/5da4469a7aa011de614c3e2ae383c35a353a382e
- https://git.kernel.org/stable/c/6c993779ea1d0cccdb3a5d7d45446dd229e610a3
- https://git.kernel.org/stable/c/7df72bedbdd1d02bb216e1f6eca0a16900238c4e
- https://git.kernel.org/stable/c/918944526a386f186dd818ea6b0bcbed75d8c16b
- https://git.kernel.org/stable/c/d143e327c97241599c958d1ba9fbaa88c37db721
- https://git.kernel.org/stable/c/d2b3bd0d4cadfdb7f3454d2aef9d5d9e8b48aae4
- https://git.kernel.org/stable/c/fd176a18db96d574d8c4763708abcec4444a08b6
Modified: 2025-11-12
CVE-2023-53041
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Perform lockless command completion in abort path While adding and removing the controller, the following call trace was observed: WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50 CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1 RIP: 0010:dma_free_attrs+0x33/0x50 Call Trace: qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx] qla2x00_abort_srb+0x8e/0x250 [qla2xxx] ? ql_dbg+0x70/0x100 [qla2xxx] __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx] qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx] qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx] qla2x00_remove_one+0x364/0x400 [qla2xxx] pci_device_remove+0x36/0xa0 __device_release_driver+0x17a/0x230 device_release_driver+0x24/0x30 pci_stop_bus_device+0x68/0x90 pci_stop_and_remove_bus_device_locked+0x16/0x30 remove_store+0x75/0x90 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 ? do_user_addr_fault+0x1d8/0x680 ? do_syscall_64+0x69/0x80 ? exc_page_fault+0x62/0x140 ? asm_exc_page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xae The command was completed in the abort path during driver unload with a lock held, causing the warning in abort path. Hence complete the command without any lock held.
- https://git.kernel.org/stable/c/0367076b0817d5c75dfb83001ce7ce5c64d803a9
- https://git.kernel.org/stable/c/231cfa78ec5badd84a1a2b09465bfad1a926aba1
- https://git.kernel.org/stable/c/415d614344a4f1bbddf55d724fc7eb9ef4b39aad
- https://git.kernel.org/stable/c/9189f20b4c5307c0998682bb522e481b4567a8b8
- https://git.kernel.org/stable/c/cd0a1804ac5bab2545ac700c8d0fe9ae9284c567
- https://git.kernel.org/stable/c/d6f7377528d2abf338e504126e44439541be8f7d
Modified: 2025-11-12
CVE-2023-53042
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Do not set DRR on pipe Commit [WHY] Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a pipe commit can cause underflow.
Modified: 2025-11-12
CVE-2023-53043
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: sc7280: Mark PCIe controller as cache coherent If the controller is not marked as cache coherent, then kernel will try to ensure coherency during dma-ops and that may cause data corruption. So, mark the PCIe node as dma-coherent as the devices on PCIe bus are cache coherent.
Modified: 2025-11-12
CVE-2023-53044
In the Linux kernel, the following vulnerability has been resolved: dm stats: check for and propagate alloc_percpu failure Check alloc_precpu()'s return value and return an error from dm_stats_init() if it fails. Update alloc_dev() to fail if dm_stats_init() does. Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup() even if dm-stats isn't being actively used.
- https://git.kernel.org/stable/c/0d96bd507ed7e7d565b6d53ebd3874686f123b2e
- https://git.kernel.org/stable/c/2287d7b721471a3d58bcd829250336e3cdf1635e
- https://git.kernel.org/stable/c/443c9d522397511a4328dc2ec3c9c63c73049756
- https://git.kernel.org/stable/c/4a32a9a818a895671bd43e0c40351e60e4e9140b
- https://git.kernel.org/stable/c/5b66e36a3efd24041b7374432bfa4dec2ff01e95
- https://git.kernel.org/stable/c/a42180dd361584816bfe15c137b665699b994d90
- https://git.kernel.org/stable/c/c68f08cc745675a17894e1b4a5b5b9700ace6da4
- https://git.kernel.org/stable/c/d3aa3e060c4a80827eb801fc448debc9daa7c46b
Modified: 2025-11-12
CVE-2023-53045
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: don't let userspace block driver unbind In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free() via g_audio_cleanup() will disconnect the card and then wait for all resources to be released, which happens when the refcount falls to zero. Since userspace can keep the refcount incremented by not closing the relevant file descriptor, the call to unbind may block indefinitely. This can cause a deadlock during reboot, as evidenced by the following blocked task observed on my machine: task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c Call trace: __switch_to+0xc8/0x140 __schedule+0x2f0/0x7c0 schedule+0x60/0xd0 schedule_timeout+0x180/0x1d4 wait_for_completion+0x78/0x180 snd_card_free+0x90/0xa0 g_audio_cleanup+0x2c/0x64 afunc_unbind+0x28/0x60 ... kernel_restart+0x4c/0xac __do_sys_reboot+0xcc/0x1ec __arm64_sys_reboot+0x28/0x30 invoke_syscall+0x4c/0x110 ... The issue can also be observed by opening the card with arecord and then stopping the process through the shell before unbinding: # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind (observe that the unbind command never finishes) Fix the problem by using snd_card_free_when_closed() instead, which will still disconnect the card as desired, but defer the task of freeing the resources to the core once userspace closes its file descriptor.
- https://git.kernel.org/stable/c/0eda2004f38d95ef5715d62be884cd344260535b
- https://git.kernel.org/stable/c/3256e152b645fc1e788ba44c2d8ced690113e3e6
- https://git.kernel.org/stable/c/33f341c1fc60e172a3515c51bdabee11e83d1ee9
- https://git.kernel.org/stable/c/3bc7324e4911351e39c54a62e6ca46321cb10faf
- https://git.kernel.org/stable/c/3e016ef2e72da93a2ea7afbb45de1b481b44d761
- https://git.kernel.org/stable/c/43ca70753dfffd517d2af126da28690f8f615605
- https://git.kernel.org/stable/c/6c67ed9ad9b83e453e808f9b31a931a20a25629b
- https://git.kernel.org/stable/c/b131989797f7287d7fdadb2bababc05a15d44750
Modified: 2025-11-12
CVE-2023-53046
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix race condition in hci_cmd_sync_clear There is a potential race condition in hci_cmd_sync_work and hci_cmd_sync_clear, and could lead to use-after-free. For instance, hci_cmd_sync_work is added to the 'req_workqueue' after cancel_work_sync The entry of 'cmd_sync_work_list' may be freed in hci_cmd_sync_clear, and causing kernel panic when it is used in 'hci_cmd_sync_work'. Here's the call trace: dump_stack_lvl+0x49/0x63 print_report.cold+0x5e/0x5d3 ? hci_cmd_sync_work+0x282/0x320 kasan_report+0xaa/0x120 ? hci_cmd_sync_work+0x282/0x320 __asan_report_load8_noabort+0x14/0x20 hci_cmd_sync_work+0x282/0x320 process_one_work+0x77b/0x11c0 ? _raw_spin_lock_irq+0x8e/0xf0 worker_thread+0x544/0x1180 ? poll_idle+0x1e0/0x1e0 kthread+0x285/0x320 ? process_one_work+0x11c0/0x11c0 ? kthread_complete_and_exit+0x30/0x30 ret_from_fork+0x22/0x30 Allocated by task 266: kasan_save_stack+0x26/0x50 __kasan_kmalloc+0xae/0xe0 kmem_cache_alloc_trace+0x191/0x350 hci_cmd_sync_queue+0x97/0x2b0 hci_update_passive_scan+0x176/0x1d0 le_conn_complete_evt+0x1b5/0x1a00 hci_le_conn_complete_evt+0x234/0x340 hci_le_meta_evt+0x231/0x4e0 hci_event_packet+0x4c5/0xf00 hci_rx_work+0x37d/0x880 process_one_work+0x77b/0x11c0 worker_thread+0x544/0x1180 kthread+0x285/0x320 ret_from_fork+0x22/0x30 Freed by task 269: kasan_save_stack+0x26/0x50 kasan_set_track+0x25/0x40 kasan_set_free_info+0x24/0x40 ____kasan_slab_free+0x176/0x1c0 __kasan_slab_free+0x12/0x20 slab_free_freelist_hook+0x95/0x1a0 kfree+0xba/0x2f0 hci_cmd_sync_clear+0x14c/0x210 hci_unregister_dev+0xff/0x440 vhci_release+0x7b/0xf0 __fput+0x1f3/0x970 ____fput+0xe/0x20 task_work_run+0xd4/0x160 do_exit+0x8b0/0x22a0 do_group_exit+0xba/0x2a0 get_signal+0x1e4a/0x25b0 arch_do_signal_or_restart+0x93/0x1f80 exit_to_user_mode_prepare+0xf5/0x1a0 syscall_exit_to_user_mode+0x26/0x50 ret_from_fork+0x15/0x30
Modified: 2025-11-12
CVE-2023-53047
In the Linux kernel, the following vulnerability has been resolved: tee: amdtee: fix race condition in amdtee_open_session There is a potential race condition in amdtee_open_session that may lead to use-after-free. For instance, in amdtee_open_session() after sess->sess_mask is set, and before setting: sess->session_info[i] = session_info; if amdtee_close_session() closes this same session, then 'sess' data structure will be released, causing kernel panic when 'sess' is accessed within amdtee_open_session(). The solution is to set the bit sess->sess_mask as the last step in amdtee_open_session().
- https://git.kernel.org/stable/c/02b296978a2137d7128151c542e84dc96400bc00
- https://git.kernel.org/stable/c/a63cce9393e4e7dbc5af82dc87e68cb321cb1a78
- https://git.kernel.org/stable/c/b3ef9e6fe09f1a132af28c623edcf4d4f39d9f35
- https://git.kernel.org/stable/c/f632a90f8e39db39b322107b9a8d438b826a7f4f
- https://git.kernel.org/stable/c/f8502fba45bd30e1a6a354d9d898bc99d1a11e6d
Modified: 2025-11-12
CVE-2023-53048
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: fix warning when handle discover_identity message Since both source and sink device can send discover_identity message in PD3, kernel may dump below warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 169 at drivers/usb/typec/tcpm/tcpm.c:1446 tcpm_queue_vdm+0xe0/0xf0 Modules linked in: CPU: 0 PID: 169 Comm: 1-0050 Not tainted 6.1.1-00038-g6a3c36cf1da2-dirty #567 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tcpm_queue_vdm+0xe0/0xf0 lr : tcpm_queue_vdm+0x2c/0xf0 sp : ffff80000c19bcd0 x29: ffff80000c19bcd0 x28: 0000000000000001 x27: ffff0000d11c8ab8 x26: ffff0000d11cc000 x25: 0000000000000000 x24: 00000000ff008081 x23: 0000000000000001 x22: 00000000ff00a081 x21: ffff80000c19bdbc x20: 0000000000000000 x19: ffff0000d11c8080 x18: ffffffffffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000d716f580 x14: 0000000000000001 x13: ffff0000d716f507 x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000020 x9 : 00000000000ee098 x8 : 00000000ffffffff x7 : 000000000000001c x6 : ffff0000d716f580 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff80000c19bdbc x1 : 00000000ff00a081 x0 : 0000000000000004 Call trace: tcpm_queue_vdm+0xe0/0xf0 tcpm_pd_rx_handler+0x340/0x1ab0 kthread_worker_fn+0xcc/0x18c kthread+0x10c/0x110 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- Below sequences may trigger this warning: tcpm_send_discover_work(work) tcpm_send_vdm(port, USB_SID_PD, CMD_DISCOVER_IDENT, NULL, 0); tcpm_queue_vdm(port, header, data, count); port->vdm_state = VDM_STATE_READY; vdm_state_machine_work(work); <-- received discover_identity from partner vdm_run_state_machine(port); port->vdm_state = VDM_STATE_SEND_MESSAGE; mod_vdm_delayed_work(port, x); tcpm_pd_rx_handler(work); tcpm_pd_data_request(port, msg); tcpm_handle_vdm_request(port, msg->payload, cnt); tcpm_queue_vdm(port, response[0], &response[1], rlen - 1); --> WARN_ON(port->vdm_state > VDM_STATE_DONE); For this case, the state machine could still send out discover identity message later if we skip current discover_identity message. So we should handle the received message firstly and override the pending discover_identity message without warning in this case. Then, a delayed send_discover work will send discover_identity message again.
Modified: 2025-11-12
CVE-2023-53049
In the Linux kernel, the following vulnerability has been resolved: usb: ucsi: Fix NULL pointer deref in ucsi_connector_change() When ucsi_init() fails, ucsi->connector is NULL, yet in case of ucsi_acpi we may still get events which cause the ucs_acpi code to call ucsi_connector_change(), which then derefs the NULL ucsi->connector pointer. Fix this by not setting ucsi->ntfy inside ucsi_init() until ucsi_init() has succeeded, so that ucsi_connector_change() ignores the events because UCSI_ENABLE_NTFY_CONNECTOR_CHANGE is not set in the ntfy mask.
- https://git.kernel.org/stable/c/1c5abcb13491da8c049f20462189c12c753ba978
- https://git.kernel.org/stable/c/7dd27aed9c456670b3882877ef17a48195f21693
- https://git.kernel.org/stable/c/7ef0423e43f877a328454059d46763043ce3da44
- https://git.kernel.org/stable/c/a6adfe9bbd6ac11e398b54ccd99a0f8eea09f3c0
- https://git.kernel.org/stable/c/f87fb985452ab2083967103ac00bfd68fb182764
Modified: 2025-11-12
CVE-2023-53050
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix memory leak in margining Memory for the usb4->margining needs to be relased for the upstream port of the router as well, even though the debugfs directory gets released with the router device removal. Fix this.
Modified: 2025-11-12
CVE-2023-53051
In the Linux kernel, the following vulnerability has been resolved: dm crypt: add cond_resched() to dmcrypt_write() The loop in dmcrypt_write may be running for unbounded amount of time, thus we need cond_resched() in it. This commit fixes the following warning: [ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897] ... [ 3391.387210][ C12] Call trace: [ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158 [ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0 [ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550 [ 3391.405856][ C12] submit_bio_noacct+0x308/0x380 [ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt] [ 3391.416005][ C12] kthread+0x130/0x138 [ 3391.419911][ C12] ret_from_fork+0x10/0x18
- https://git.kernel.org/stable/c/2c743db1193bf0e76c73d71ede08bd9b96e6c31d
- https://git.kernel.org/stable/c/66ff37993dd7e9954b6446237fe2453b380ce40d
- https://git.kernel.org/stable/c/7b9f8efb5fc888dd938d2964e705b8e00f1dc0f6
- https://git.kernel.org/stable/c/885c28ceae7dab2b18c2cc0eb95f1f82b1f629d1
- https://git.kernel.org/stable/c/e87cd83f70504f1cd2e428966f353c007d6d2d7f
- https://git.kernel.org/stable/c/eb485b7404a281d974bd445ddc5b0b8d5958f371
- https://git.kernel.org/stable/c/f0eb61b493dbbc32529fbd0d2e945b71b0e47306
- https://git.kernel.org/stable/c/fb294b1c0ba982144ca467a75e7d01ff26304e2b
Modified: 2025-11-12
CVE-2023-53053
In the Linux kernel, the following vulnerability has been resolved:
erspan: do not use skb_mac_header() in ndo_start_xmit()
Drivers should not assume skb_mac_header(skb) == skb->data in their
ndo_start_xmit().
Use skb_network_offset() and skb_transport_offset() which
better describe what is needed in erspan_fb_xmit() and
ip6erspan_tunnel_xmit()
syzbot reported:
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Modules linked in:
CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00
RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003
RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00
R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000
FS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/5d4172732f0ee1639a361a6cc5c3114bbb397386
- https://git.kernel.org/stable/c/8e50ed774554f93d55426039b27b1e38d7fa64d8
- https://git.kernel.org/stable/c/9c7d6803689c99d55bbb862260d0ba486ff23c0b
- https://git.kernel.org/stable/c/b41f37dbd9cdb60000e3b0dfad6df787591c2265
- https://git.kernel.org/stable/c/b72f453e886af532bde1fd049a2d2421999630d3
- https://git.kernel.org/stable/c/da149daf821a3c05cd04f7c60776c86c5ee9685c
- https://git.kernel.org/stable/c/f8cec30541f5c5cc218e9a32138d45d227727f2f
Modified: 2025-11-12
CVE-2023-53054
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix a devres leak in hw_enable upon suspend resume Each time the platform goes to low power, PM suspend / resume routines call: __dwc2_lowlevel_hw_enable -> devm_add_action_or_reset(). This adds a new devres each time. This may also happen at runtime, as dwc2_lowlevel_hw_enable() can be called from udc_start(). This can be seen with tracing: - echo 1 > /sys/kernel/debug/tracing/events/dev/devres_log/enable - go to low power - cat /sys/kernel/debug/tracing/trace A new "ADD" entry is found upon each low power cycle: ... devres_log: 49000000.usb-otg ADD 82a13bba devm_action_release (8 bytes) ... devres_log: 49000000.usb-otg ADD 49889daf devm_action_release (8 bytes) ... A second issue is addressed here: - regulator_bulk_enable() is called upon each PM cycle (suspend/resume). - regulator_bulk_disable() never gets called. So the reference count for these regulators constantly increase, by one upon each low power cycle, due to missing regulator_bulk_disable() call in __dwc2_lowlevel_hw_disable(). The original fix that introduced the devm_add_action_or_reset() call, fixed an issue during probe, that happens due to other errors in dwc2_driver_probe() -> dwc2_core_reset(). Then the probe fails without disabling regulators, when dr_mode == USB_DR_MODE_PERIPHERAL. Rather fix the error path: disable all the low level hardware in the error path, by using the "hsotg->ll_hw_enabled" flag. Checking dr_mode has been introduced to avoid a dual call to dwc2_lowlevel_hw_disable(). "ll_hw_enabled" should achieve the same (and is used currently in the remove() routine).
- https://git.kernel.org/stable/c/1f01027c51eb16145e8e07fafea3ca07ef102d06
- https://git.kernel.org/stable/c/6485fc381b6528b6f547ee1ff10bdbcbe31a6e4c
- https://git.kernel.org/stable/c/cba76e1fb896b573f09f51aa299223276a77bc90
- https://git.kernel.org/stable/c/f747313249b74f323ddf841a9c8db14d989f296a
- https://git.kernel.org/stable/c/ffb8ab6f87bd28d700ab5c20d9d3a7e75067630d
Modified: 2025-11-12
CVE-2023-53055
In the Linux kernel, the following vulnerability has been resolved: fscrypt: destroy keyring after security_sb_delete() fscrypt_destroy_keyring() must be called after all potentially-encrypted inodes were evicted; otherwise it cannot safely destroy the keyring. Since inodes that are in-use by the Landlock LSM don't get evicted until security_sb_delete(), this means that fscrypt_destroy_keyring() must be called *after* security_sb_delete(). This fixes a WARN_ON followed by a NULL dereference, only possible if Landlock was being used on encrypted files.
Modified: 2025-11-12
CVE-2023-53057
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: HCI: Fix global-out-of-bounds
To loop a variable-length array, hci_init_stage_sync(stage) considers
that stage[i] is valid as long as stage[i-1].func is valid.
Thus, the last element of stage[].func should be intentionally invalid
as hci_init0[], le_init2[], and others did.
However, amp_init1[] and amp_init2[] have no invalid element, letting
hci_init_stage_sync() keep accessing amp_init1[] over its valid range.
This patch fixes this by adding {} in the last of amp_init1[] and
amp_init2[].
==================================================================
BUG: KASAN: global-out-of-bounds in hci_dev_open_sync (
/v6.2-bzimage/net/bluetooth/hci_sync.c:3154
/v6.2-bzimage/net/bluetooth/hci_sync.c:3343
/v6.2-bzimage/net/bluetooth/hci_sync.c:4418
/v6.2-bzimage/net/bluetooth/hci_sync.c:4609
/v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
Read of size 8 at addr ffffffffaed1ab70 by task kworker/u5:0/1032
CPU: 0 PID: 1032 Comm: kworker/u5:0 Not tainted 6.2.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04
Workqueue: hci1 hci_power_on
Call Trace:
Modified: 2025-11-07
CVE-2023-53058
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, Fix an Oops in error handling code The error handling dereferences "vport". There is nothing we can do if it is an error pointer except returning the error code.
- https://git.kernel.org/stable/c/1a9853a7437a22fd849347008fb3c85087906b56
- https://git.kernel.org/stable/c/388188fb58bef9e7f3ca4f8970f03d493b66909f
- https://git.kernel.org/stable/c/5eadc80328298ef7beaaf0cd96791667d3b485ca
- https://git.kernel.org/stable/c/640fcdbcf27fc62de9223f958ceb4e897a00e791
- https://git.kernel.org/stable/c/c4c977935b2fc60084b3735737d17a06e7ba1bd0
Modified: 2026-03-17
CVE-2023-53059
In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl It is possible to peep kernel page's data by providing larger `insize` in struct cros_ec_command[1] when invoking EC host commands. Fix it by using zeroed memory. [1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74
- https://git.kernel.org/stable/c/13493ad6a220cb3f6f3552a16b4f2753a118b633
- https://git.kernel.org/stable/c/a0d8644784f73fa39f57f72f374eefaba2bf48a0
- https://git.kernel.org/stable/c/b20cf3f89c56b5f6a38b7f76a8128bf9f291bbd3
- https://git.kernel.org/stable/c/eab28bfafcd1245a3510df9aa9eb940589956ea6
- https://git.kernel.org/stable/c/ebea2e16504f40d2c2bac42ad5c5a3de5ce034b4
- https://git.kernel.org/stable/c/f86ff88a1548ccf5a13960c0e7625ca787ea0993
Modified: 2025-11-07
CVE-2023-53060
In the Linux kernel, the following vulnerability has been resolved:
igb: revert rtnl_lock() that causes deadlock
The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds
rtnl_lock to eliminate a false data race shown below
(FREE from device detaching) | (USE from netdev core)
igb_remove | igb_ndo_get_vf_config
igb_disable_sriov | vf >= adapter->vfs_allocated_count?
kfree(adapter->vf_data) |
adapter->vfs_allocated_count = 0 |
| memcpy(... adapter->vf_data[vf]
The above race will never happen and the extra rtnl_lock causes deadlock
below
[ 141.420169]
- https://git.kernel.org/stable/c/0dabb72b923e17cb3b4ac99ea1adc9ef35116930
- https://git.kernel.org/stable/c/4d2626e10709ff8474ffd1a9db3cf4647569e89c
- https://git.kernel.org/stable/c/62a64645749926f9d75af82a96440941f22b046f
- https://git.kernel.org/stable/c/65f69851e44d71248b952a687e44759a7abb5016
- https://git.kernel.org/stable/c/66e5577cabc3d463eea540332727929d0ace41c6
- https://git.kernel.org/stable/c/7d845e9a485f287181ff81567c3900a8e7ad1e28
- https://git.kernel.org/stable/c/cd1e320ac0958298c2774605ad050483f33a21f2
- https://git.kernel.org/stable/c/de91528d8ba274c614a2265077d695c61e31fd43
Modified: 2025-11-07
CVE-2023-53061
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix possible refcount leak in smb2_open() Reference count of acls will leak when memory allocation fails. Fix this by adding the missing posix_acl_release().
Modified: 2025-11-07
CVE-2023-53062
In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc95xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents.
- https://git.kernel.org/stable/c/33d1603a38e05886c538129ddfe00bd52d347e7b
- https://git.kernel.org/stable/c/70eb25c6a6cde149affe8a587371a3a8ad295ba0
- https://git.kernel.org/stable/c/733580e268a53db1cd01f2251419da91866378f6
- https://git.kernel.org/stable/c/ba6c40227108f8ee428e42eb0337b48ed3001e65
- https://git.kernel.org/stable/c/d3c145a4d24b752c9a1314d5a595014d51471418
- https://git.kernel.org/stable/c/e041bef1adee02999cf24f9a2e15ed452bc363fe
- https://git.kernel.org/stable/c/f2111c791d885211714db85f9a06188571c57dd0
- https://git.kernel.org/stable/c/ff821092cf02a70c2bccd2d19269f01e29aa52cf
Modified: 2025-11-07
CVE-2023-53064
In the Linux kernel, the following vulnerability has been resolved: iavf: fix hang on reboot with ice When a system with E810 with existing VFs gets rebooted the following hang may be observed. Pid 1 is hung in iavf_remove(), part of a network driver: PID: 1 TASK: ffff965400e5a340 CPU: 24 COMMAND: "systemd-shutdow" #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930 #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf] #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513 #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429 #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4 #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice] #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice] #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice] #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1 #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386 #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870 #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6 #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159 #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169 #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90 R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005 R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000 ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b During reboot all drivers PM shutdown callbacks are invoked. In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE. In ice_shutdown() the call chain above is executed, which at some point calls iavf_remove(). However iavf_remove() expects the VF to be in one of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If that's not the case it sleeps forever. So if iavf_shutdown() gets invoked before iavf_remove() the system will hang indefinitely because the adapter is already in state __IAVF_REMOVE. Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE, as we already went through iavf_shutdown().
Modified: 2025-11-12
CVE-2023-53065
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output syzkaller reportes a KASAN issue with stack-out-of-bounds. The call trace is as follows: dump_stack+0x9c/0xd3 print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 __perf_event_header__init_id+0x34/0x290 perf_event_header__init_id+0x48/0x60 perf_output_begin+0x4a4/0x560 perf_event_bpf_output+0x161/0x1e0 perf_iterate_sb_cpu+0x29e/0x340 perf_iterate_sb+0x4c/0xc0 perf_event_bpf_event+0x194/0x2c0 __bpf_prog_put.constprop.0+0x55/0xf0 __cls_bpf_delete_prog+0xea/0x120 [cls_bpf] cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf] process_one_work+0x3c2/0x730 worker_thread+0x93/0x650 kthread+0x1b8/0x210 ret_from_fork+0x1f/0x30 commit 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()") use on-stack struct perf_sample_data of the caller function. However, perf_event_bpf_output uses incorrect parameter to convert small-sized data (struct perf_bpf_event) into large-sized data (struct perf_sample_data), which causes memory overwriting occurs in __perf_event_header__init_id.
- https://git.kernel.org/stable/c/3a776fddb4e5598c8bfcd4ad094fba34f9856fc9
- https://git.kernel.org/stable/c/ac5f88642cb211152041f84a985309e9af4baf59
- https://git.kernel.org/stable/c/ddcf8320003638a06eb1e46412e045d0c5701575
- https://git.kernel.org/stable/c/eb81a2ed4f52be831c9fb879752d89645a312c13
- https://git.kernel.org/stable/c/ff8137727a2af4ad5f6e6c8b9f7ec5e8db9da86c
Modified: 2025-11-12
CVE-2023-53066
In the Linux kernel, the following vulnerability has been resolved: qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info We have to make sure that the info returned by the helper is valid before using it. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/25143b6a01d0cc5319edd3de22ffa2578b045550
- https://git.kernel.org/stable/c/39c3b9dd481c3afce9439b29bafe00444cb4406b
- https://git.kernel.org/stable/c/42d72c6d1edc9dc09a5d6f6695d257fa9e9cc270
- https://git.kernel.org/stable/c/7742c08e012eb65405e8304d100641638c5ff882
- https://git.kernel.org/stable/c/7bd0037822fd04da13721f77a42ee5a077d4c5fb
- https://git.kernel.org/stable/c/97ea704f39b5ded96f071e98701aa543f6f89683
- https://git.kernel.org/stable/c/b224b0cab3a66e93d414825065a2e667a1d28c32
- https://git.kernel.org/stable/c/e42d3bde4ec03c863259878dddaef5c351cca7ad
Modified: 2025-11-12
CVE-2023-53067
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Only call get_timer_irq() once in constant_clockevent_init() Under CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_DEBUG_PREEMPT=y, we can see the following messages on LoongArch, this is because using might_sleep() in preemption disable context. [ 0.001127] smp: Bringing up secondary CPUs ... [ 0.001222] Booting CPU#1... [ 0.001244] 64-bit Loongson Processor probed (LA464 Core) [ 0.001247] CPU1 revision is: 0014c012 (Loongson-64bit) [ 0.001250] FPU1 revision is: 00000000 [ 0.001252] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 [ 0.001255] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.001257] preempt_count: 1, expected: 0 [ 0.001258] RCU nest depth: 0, expected: 0 [ 0.001259] Preemption disabled at: [ 0.001261] [<9000000000223800>] arch_dup_task_struct+0x20/0x110 [ 0.001272] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc7+ #43 [ 0.001275] Hardware name: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-beta10 12/13/202 [ 0.001277] Stack : 0072617764726148 0000000000000000 9000000000222f1c 90000001001e0000 [ 0.001286] 90000001001e3be0 90000001001e3be8 0000000000000000 0000000000000000 [ 0.001292] 90000001001e3be8 0000000000000040 90000001001e3cb8 90000001001e3a50 [ 0.001297] 9000000001642000 90000001001e3be8 be694d10ce4139dd 9000000100174500 [ 0.001303] 0000000000000001 0000000000000001 00000000ffffe0a2 0000000000000020 [ 0.001309] 000000000000002f 9000000001354116 00000000056b0000 ffffffffffffffff [ 0.001314] 0000000000000000 0000000000000000 90000000014f6e90 9000000001642000 [ 0.001320] 900000000022b69c 0000000000000001 0000000000000000 9000000001736a90 [ 0.001325] 9000000100038000 0000000000000000 9000000000222f34 0000000000000000 [ 0.001331] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.001337] ... [ 0.001339] Call Trace: [ 0.001342] [<9000000000222f34>] show_stack+0x5c/0x180 [ 0.001346] [<90000000010bdd80>] dump_stack_lvl+0x60/0x88 [ 0.001352] [<9000000000266418>] __might_resched+0x180/0x1cc [ 0.001356] [<90000000010c742c>] mutex_lock+0x20/0x64 [ 0.001359] [<90000000002a8ccc>] irq_find_matching_fwspec+0x48/0x124 [ 0.001364] [<90000000002259c4>] constant_clockevent_init+0x68/0x204 [ 0.001368] [<900000000022acf4>] start_secondary+0x40/0xa8 [ 0.001371] [<90000000010c0124>] smpboot_entry+0x60/0x64 Here are the complete call chains: smpboot_entry() start_secondary() constant_clockevent_init() get_timer_irq() irq_find_matching_fwnode() irq_find_matching_fwspec() mutex_lock() might_sleep() __might_sleep() __might_resched() In order to avoid the above issue, we should break the call chains, using timer_irq_installed variable as check condition to only call get_timer_irq() once in constant_clockevent_init() is a simple and proper way.
Modified: 2025-11-12
CVE-2023-53068
In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents. Additionally prevent integer underflow when size is less than ETH_FCS_LEN.
Modified: 2025-11-12
CVE-2023-53069
In the Linux kernel, the following vulnerability has been resolved: octeontx2-vf: Add missing free for alloc_percpu Add the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid memory leak, same as the "pf->hw.lmt_info" in `drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.
Modified: 2025-11-12
CVE-2023-53070
In the Linux kernel, the following vulnerability has been resolved: ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") enabled to map PPTT once on the first invocation of acpi_get_pptt() and never unmapped the same allowing it to be used at runtime with out the hassle of mapping and unmapping the table. This was needed to fetch LLC information from the PPTT in the cpuhotplug path which is executed in the atomic context as the acpi_get_table() might sleep waiting for a mutex. However it missed to handle the case when there is no PPTT on the system which results in acpi_get_pptt() being called from all the secondary CPUs attempting to fetch the LLC information in the atomic context without knowing the absence of PPTT resulting in the splat like below: | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 0 | hardirqs last enabled at (0): 0x0 | hardirqs last disabled at (0): copy_process+0x61c/0x1b40 | softirqs last enabled at (0): copy_process+0x61c/0x1b40 | softirqs last disabled at (0): 0x0 | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1 | Call trace: | dump_backtrace+0xac/0x138 | show_stack+0x30/0x48 | dump_stack_lvl+0x60/0xb0 | dump_stack+0x18/0x28 | __might_resched+0x160/0x270 | __might_sleep+0x58/0xb0 | down_timeout+0x34/0x98 | acpi_os_wait_semaphore+0x7c/0xc0 | acpi_ut_acquire_mutex+0x58/0x108 | acpi_get_table+0x40/0xe8 | acpi_get_pptt+0x48/0xa0 | acpi_get_cache_info+0x38/0x140 | init_cache_level+0xf4/0x118 | detect_cache_attributes+0x2e4/0x640 | update_siblings_masks+0x3c/0x330 | store_cpu_topology+0x88/0xf0 | secondary_start_kernel+0xd0/0x168 | __secondary_switched+0xb8/0xc0 Update acpi_get_pptt() to consider the fact that PPTT is once checked and is not available on the system and return NULL avoiding any attempts to fetch PPTT and thereby avoiding any possible sleep waiting for a mutex in the atomic context.
Modified: 2025-11-12
CVE-2023-53072
In the Linux kernel, the following vulnerability has been resolved:
mptcp: use the workqueue to destroy unaccepted sockets
Christoph reported a UaF at token lookup time after having
refactored the passive socket initialization part:
BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260
Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198
CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
Modified: 2025-11-12
CVE-2023-53073
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/core: Always clear status for idx The variable 'status' (which contains the unhandled overflow bits) is not being properly masked in some cases, displaying the following warning: WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270 This seems to be happening because the loop is being continued before the status bit being unset, in case x86_perf_event_set_period() returns 0. This is also causing an inconsistency because the "handled" counter is incremented, but the status bit is not cleaned. Move the bit cleaning together above, together when the "handled" counter is incremented.
Modified: 2025-11-12
CVE-2023-53074
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini
The call trace occurs when the amdgpu is removed after
the mode1 reset. During mode1 reset, from suspend to resume,
there is no need to reinitialize the ta firmware buffer
which caused the bo pin_count increase redundantly.
[ 489.885525] Call Trace:
[ 489.885525]
Modified: 2025-11-12
CVE-2023-53075
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix invalid address access in lookup_rec() when index is 0 KASAN reported follow problem: BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly added to ftrace_pages_start in ftrace_process_locs(). Before the first pg->index++, index is 0 and accessing pg->records[-1].ip will cause this problem. Don't check the ip when pg->index is 0.
- https://git.kernel.org/stable/c/2a0d71fabfeb349216d33f001a6421b1768bd3a9
- https://git.kernel.org/stable/c/2de28e5ce34b22b73b833a21e2c45ae3aade3964
- https://git.kernel.org/stable/c/4f84f31f63416b0f02fc146ffdc4ab32723eb7e8
- https://git.kernel.org/stable/c/7569ee04b0e3b32df79f64db3a7138573edad9bc
- https://git.kernel.org/stable/c/83c3b2f4e7c61367c7b24551f4c6eb94bbdda283
- https://git.kernel.org/stable/c/ac58b88ccbbb8e9fb83e137cee04a856b1ea6635
- https://git.kernel.org/stable/c/ee92fa443358f4fc0017c1d0d325c27b37802504
- https://git.kernel.org/stable/c/f1bd8b7fd890d87d0dc4dedc6287ea34dd07c0b4
Modified: 2025-11-12
CVE-2023-53077
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes [WHY] When PTEBufferSizeInRequests is zero, UBSAN reports the following warning because dml_log2 returns an unexpected negative value: shift exponent 4294966273 is too large for 32-bit type 'int' [HOW] In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and assign the result directly.
- https://git.kernel.org/stable/c/031f196d1b1b6d5dfcb0533b431e3ab1750e6189
- https://git.kernel.org/stable/c/7257070be70e19a9138f39009c1a26c83a8a7cfa
- https://git.kernel.org/stable/c/a16394b5d661afec9a264fecac3abd87aea439ea
- https://git.kernel.org/stable/c/bec1bea2fa974e63f6059c33edde669c7894d0bc
- https://git.kernel.org/stable/c/e12b95680821b9880cd9992c0f3555389363604f
Modified: 2025-11-12
CVE-2023-53078
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not freed, which will cause following memleak: unreferenced object 0xffff88810b2c6980 (size 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<0000000098f3a26d>] alua_activate+0xb0/0x320 [<000000003b529641>] scsi_dh_activate+0xb2/0x140 [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] [<000000007adc9ace>] process_one_work+0x3c5/0x730 [<00000000c457a985>] worker_thread+0x93/0x650 [<00000000cb80e628>] kthread+0x1ba/0x210 [<00000000a1e61077>] ret_from_fork+0x22/0x30 Fix the problem by freeing 'qdata' in error path.
- https://git.kernel.org/stable/c/0d89254a4320eb7de0970c478172f764125c6355
- https://git.kernel.org/stable/c/123483df146492ca22b503ae6dacc2ce7c3a3974
- https://git.kernel.org/stable/c/1c55982beb80c7d3c30278fc6cfda8496a31dbe6
- https://git.kernel.org/stable/c/5c4d71424df34fc23dc5336d09394ce68c849542
- https://git.kernel.org/stable/c/9311e7a554dffd3823499e309a8b86a5cd1540e5
- https://git.kernel.org/stable/c/a13faca032acbf2699293587085293bdfaafc8ae
- https://git.kernel.org/stable/c/c09cdf6eb815ee35e55d6c50ac7f63db58bd20b8
- https://git.kernel.org/stable/c/c110051d335ef7f62ad33474b0c23997fee5bfb5
Modified: 2025-11-12
CVE-2023-53079
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix steering rules cleanup vport's mc, uc and multicast rules are not deleted in teardown path when EEH happens. Since the vport's promisc settings(uc, mc and all) in firmware are reset after EEH, mlx5 driver will try to delete the above rules in the initialization path. This cause kernel crash because these software rules are no longer valid. Fix by nullifying these rules right after delete to avoid accessing any dangling pointers. Call Trace: __list_del_entry_valid+0xcc/0x100 (unreliable) tree_put_node+0xf4/0x1b0 [mlx5_core] tree_remove_node+0x30/0x70 [mlx5_core] mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core] esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core] esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core] esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core] esw_enable_vport+0x130/0x260 [mlx5_core] mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core] mlx5_device_enable_sriov+0x74/0x440 [mlx5_core] mlx5_load_one+0x114c/0x1550 [mlx5_core] mlx5_pci_resume+0x68/0xf0 [mlx5_core] eeh_report_resume+0x1a4/0x230 eeh_pe_dev_traverse+0x98/0x170 eeh_handle_normal_event+0x3e4/0x640 eeh_handle_event+0x4c/0x370 eeh_event_handler+0x14c/0x210 kthread+0x168/0x1b0 ret_from_kernel_thread+0x5c/0x84
- https://git.kernel.org/stable/c/18cead61e437f4c7898acca0a5f3df12f801d97f
- https://git.kernel.org/stable/c/4df1f2d36bdc9a368650bf14b9097c555e95f71d
- https://git.kernel.org/stable/c/63546395a0e6ac264f78f65218086ce6014b4494
- https://git.kernel.org/stable/c/6f5780536181d1d0d09a11a1bc92f22e143447e2
- https://git.kernel.org/stable/c/922f56e9a795d6f3dd72d3428ebdd7ee040fa855
Modified: 2025-11-12
CVE-2023-53080
In the Linux kernel, the following vulnerability has been resolved: xsk: Add missing overflow check in xdp_umem_reg The number of chunks can overflow u32. Make sure to return -EINVAL on overflow. Also remove a redundant u32 cast assigning umem->npgs.
- https://git.kernel.org/stable/c/3cfc3564411acf96bf2fb791f706a1aa4f872c1d
- https://git.kernel.org/stable/c/580634b03a55f04a3c1968bcbd97736c079c6601
- https://git.kernel.org/stable/c/a069909acc4435eeb41d05ccc03baa447cc01b7e
- https://git.kernel.org/stable/c/bb2e3bfb2a79db0c2057c6f701b782954394c67f
- https://git.kernel.org/stable/c/c7df4813b149362248d6ef7be41a311e27bf75fe
Modified: 2025-11-12
CVE-2023-53081
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption after failed write When buffered write fails to copy data into underlying page cache page, ocfs2_write_end_nolock() just zeroes out and dirties the page. This can leave dirty page beyond EOF and if page writeback tries to write this page before write succeeds and expands i_size, page gets into inconsistent state where page dirty bit is clear but buffer dirty bits stay set resulting in page data never getting written and so data copied to the page is lost. Fix the problem by invalidating page beyond EOF after failed write.
- https://git.kernel.org/stable/c/1629f6f522b2d058019710466a84b240683bbee3
- https://git.kernel.org/stable/c/205759c6c18f54659b0b5976b14a52d1b3eb9f57
- https://git.kernel.org/stable/c/47eb055ad3588fc96d34e9e1dd87b210ce62906b
- https://git.kernel.org/stable/c/4c24eb49ab44351424ac8fe8567f91ea48a06089
- https://git.kernel.org/stable/c/90410bcf873cf05f54a32183afff0161f44f9715
- https://git.kernel.org/stable/c/91d7a4bd5656552d6259e2d0f8859f9e8cc5ef68
- https://git.kernel.org/stable/c/a9e53869cb43c96d6d851c491fd4e26430ab6ba6
- https://git.kernel.org/stable/c/c26f3ff4c0be590c1250f945ac2e4fc5fcdc5f45
Modified: 2025-11-12
CVE-2023-53082
In the Linux kernel, the following vulnerability has been resolved:
vp_vdpa: fix the crash in hot unplug with vp_vdpa
While unplugging the vp_vdpa device, it triggers a kernel panic
The root cause is: vdpa_mgmtdev_unregister() will accesses modern
devices which will cause a use after free.
So need to change the sequence in vp_vdpa_remove
[ 195.003359] BUG: unable to handle page fault for address: ff4e8beb80199014
[ 195.004012] #PF: supervisor read access in kernel mode
[ 195.004486] #PF: error_code(0x0000) - not-present page
[ 195.004960] PGD 100000067 P4D 1001b6067 PUD 1001b7067 PMD 1001b8067 PTE 0
[ 195.005578] Oops: 0000 1 PREEMPT SMP PTI
[ 195.005968] CPU: 13 PID: 164 Comm: kworker/u56:10 Kdump: loaded Not tainted 5.14.0-252.el9.x86_64 #1
[ 195.006792] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20221207gitfff6d81270b5-2.el9 unknown
[ 195.007556] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 195.008059] RIP: 0010:ioread8+0x31/0x80
[ 195.008418] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc <8a> 07 0f b6 c0 c3 cc cc cc cc 83 ea 01 48 83 ec 08 48 89 fe 48 c7
[ 195.010104] RSP: 0018:ff4e8beb8067bab8 EFLAGS: 00010292
[ 195.010584] RAX: ffffffffc05834a0 RBX: ffffffffc05843c0 RCX: ff4e8beb8067bae0
[ 195.011233] RDX: ff1bcbd580f88000 RSI: 0000000000000246 RDI: ff4e8beb80199014
[ 195.011881] RBP: ff1bcbd587e39000 R08: ffffffff916fa2d0 R09: ff4e8beb8067ba68
[ 195.012527] R10: 000000000000001c R11: 0000000000000000 R12: ff1bcbd5a3de9120
[ 195.013179] R13: ffffffffc062d000 R14: 0000000000000080 R15: ff1bcbe402bc7805
[ 195.013826] FS: 0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:0000000000000000
[ 195.014564] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 195.015093] CR2: ff4e8beb80199014 CR3: 0000000107dea002 CR4: 0000000000771ee0
[ 195.015741] PKRU: 55555554
[ 195.016001] Call Trace:
[ 195.016233]
Modified: 2025-11-12
CVE-2023-53083
In the Linux kernel, the following vulnerability has been resolved: nfsd: don't replace page in rq_pages if it's a continuation of last page The splice read calls nfsd_splice_actor to put the pages containing file data into the svc_rqst->rq_pages array. It's possible however to get a splice result that only has a partial page at the end, if (e.g.) the filesystem hands back a short read that doesn't cover the whole page. nfsd_splice_actor will plop the partial page into its rq_pages array and return. Then later, when nfsd_splice_actor is called again, the remainder of the page may end up being filled out. At this point, nfsd_splice_actor will put the page into the array _again_ corrupting the reply. If this is done enough times, rq_next_page will overrun the array and corrupt the trailing fields -- the rq_respages and rq_next_page pointers themselves. If we've already added the page to the array in the last pass, don't add it to the array a second time when dealing with a splice continuation. This was originally handled properly in nfsd_splice_actor, but commit 91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()") removed the check for it.
- https://git.kernel.org/stable/c/0101067f376eb7b9afd00279270f25d5111a091d
- https://git.kernel.org/stable/c/12eca509234acb6b666802edf77408bb70d7bfca
- https://git.kernel.org/stable/c/27c934dd8832dd40fd34776f916dc201e18b319b
- https://git.kernel.org/stable/c/51ddb84baff6f09ad62b5999ece3ec172e4e3568
- https://git.kernel.org/stable/c/8235cd619db6e67f1d7d26c55f1f3e4e575c947d
Modified: 2025-11-12
CVE-2023-53084
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove another errant put in error path drm_gem_shmem_mmap() doesn't own reference in error code path, resulting in the dma-buf shmem GEM object getting prematurely freed leading to a later use-after-free.
- https://git.kernel.org/stable/c/5cfb617967b05f8f27e862c97db1fabd8485f4db
- https://git.kernel.org/stable/c/684c7372bbd6447c2e86a2a84e97a1478604d21f
- https://git.kernel.org/stable/c/77d26c824aa5a7e0681ef1d5b75fe538d746addc
- https://git.kernel.org/stable/c/dede8c14a37a7ac458f9add56154a074ed78e7cf
- https://git.kernel.org/stable/c/ee9adb7a45516cfa536ca92253d7ae59d56db9e4
Modified: 2025-11-12
CVE-2023-53087
In the Linux kernel, the following vulnerability has been resolved: drm/i915/active: Fix misuse of non-idle barriers as fence trackers Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed at an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel context and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. When adding a request to a composite tracker, we try to reuse an existing fence tracker, already allocated and registered with that composite. The tracker we obtain may already track another fence, may be an idle barrier, or an active barrier. If the tracker we get occurs a non-idle barrier then we try to delete that barrier from a list of barrier tasks it belongs to. However, while doing that we don't respect return value from a function that performs the barrier deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since the same structure field is reused with both fence callback lists and barrier tasks list, list corruptions would likely occur. Barriers are now deleted from a barrier tasks list by temporarily removing the list content, traversing that content with skip over the node to be deleted, then populating the list back with the modified content. Should that intentionally racy concurrent deletion attempts be not serialized, one or more of those may fail because of the list being temporary empty. Related code that ignores the results of barrier deletion was initially introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"). However, all users of the barrier deletion routine were apparently serialized at that time, then the issue didn't exhibit itself. Results of git bisect with help of a newly developed igt@gem_barrier_race@remote-request IGT test indicate that list corruptions might start to appear after commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), introduced in v5.5. Respect results of barrier deletion attempts -- mark the barrier as idle only if successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails then don't use that tracker but go back and try to acquire a new, usable one. v3: use unlikely() to document what outcome we expect (Andi), - fix bad grammar in commit description. v2: no code changes, - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"), v5.4, - reword commit description. (cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7)
- https://git.kernel.org/stable/c/5c7591b8574c52c56b3994c2fbef1a3a311b5715
- https://git.kernel.org/stable/c/5e784a7d07af42057c0576fb647b482f4cb0dc2c
- https://git.kernel.org/stable/c/6ab7d33617559cced63d467928f478ea5c459021
- https://git.kernel.org/stable/c/9159db27fb19bbf1c91b5c9d5285e66cc96cc5ff
- https://git.kernel.org/stable/c/e0e6b416b25ee14716f3549e0cbec1011b193809
Modified: 2025-11-12
CVE-2023-53088
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix UaF in listener shutdown
As reported by Christoph after having refactored the passive
socket initialization, the mptcp listener shutdown path is prone
to an UaF issue.
BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x73/0xe0
Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266
CPU: 1 PID: 1266 Comm: syz-executor731 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
Modified: 2025-11-12
CVE-2023-53089
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix task hung in ext4_xattr_delete_inode
Syzbot reported a hung task problem:
==================================================================
INFO: task syz-executor232:5073 blocked for more than 143 seconds.
Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004
Call Trace:
- https://git.kernel.org/stable/c/0f7bfd6f8164be32dbbdf36aa1e5d00485c53cd7
- https://git.kernel.org/stable/c/1aec41c98cce61d19ce89650895e51b9f3cdef13
- https://git.kernel.org/stable/c/2c96c52aeaa6fd9163cfacdd98778b4a0398ef18
- https://git.kernel.org/stable/c/64b72f5e7574020dea62ab733d88a54d903c42a1
- https://git.kernel.org/stable/c/73f7987fe1b82596f1a380e85cd0097ebaae7e01
- https://git.kernel.org/stable/c/94fd091576b12540924f6316ebc0678e84cb2800
- https://git.kernel.org/stable/c/a98160d8f3e6242ca9b7f443f26e7ef3a61ba684
- https://git.kernel.org/stable/c/efddc7e106fdf8d1f62d45e79de78f63b7c04fba
Modified: 2025-11-12
CVE-2023-53090
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix an illegal memory access In the kfd_wait_on_events() function, the kfd_event_waiter structure is allocated by alloc_event_waiters(), but the event field of the waiter structure is not initialized; When copy_from_user() fails in the kfd_wait_on_events() function, it will enter exception handling to release the previously allocated memory of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function, this results in illegal memory access and system crash, here is the crash log: localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 localhost kernel: Call Trace: localhost kernel: _raw_spin_lock_irqsave+0x30/0x40 localhost kernel: remove_wait_queue+0x12/0x50 localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu] localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: __x64_sys_ioctl+0x8e/0xd0 localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0 localhost kernel: do_syscall_64+0x33/0x80 localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 localhost kernel: RIP: 0033:0x152a4dff68d7 Allocate the structure with kcalloc, and remove redundant 0-initialization and a redundant loop condition check.
- https://git.kernel.org/stable/c/2fece63b55c5d74cd6f5de51159e2cde37e10555
- https://git.kernel.org/stable/c/4fc8fff378b2f2039f2a666d9f8c570f4e58352c
- https://git.kernel.org/stable/c/5a3fb3b745af0ce46ec2e0c8e507bae45b937334
- https://git.kernel.org/stable/c/61f306f8df0d5559659c5578cf6d95236bcdcb25
- https://git.kernel.org/stable/c/6936525142a015e854d0a23e9ad9ea0a28b3843d
- https://git.kernel.org/stable/c/bbf5eada4334a96e3a204b2307ff5b14dc380b0b
- https://git.kernel.org/stable/c/d9923e7214a870b312bf61f6a89c7554d0966985
Modified: 2025-11-12
CVE-2023-53091
In the Linux kernel, the following vulnerability has been resolved: ext4: update s_journal_inum if it changes after journal replay When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.
Modified: 2025-11-12
CVE-2023-53092
In the Linux kernel, the following vulnerability has been resolved: interconnect: exynos: fix node leak in probe PM QoS error path Make sure to add the newly allocated interconnect node to the provider before adding the PM QoS request so that the node is freed on errors.
Modified: 2025-11-12
CVE-2023-53093
In the Linux kernel, the following vulnerability has been resolved: tracing: Do not let histogram values have some modifiers Histogram values can not be strings, stacktraces, graphs, symbols, syscalls, or grouped in buckets or log. Give an error if a value is set to do so. Note, the histogram code was not prepared to handle these modifiers for histograms and caused a bug. Mark Rutland reported: # echo 'p:copy_to_user __arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copy_to_user/trigger # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist [ 143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 143.695190] Mem abort info: [ 143.695362] ESR = 0x0000000096000004 [ 143.695604] EC = 0x25: DABT (current EL), IL = 32 bits [ 143.695889] SET = 0, FnV = 0 [ 143.696077] EA = 0, S1PTW = 0 [ 143.696302] FSC = 0x04: level 0 translation fault [ 143.702381] Data abort info: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000 [ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 143.704714] Modules linked in: [ 143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3 [ 143.706138] Hardware name: linux,dummy-virt (DT) [ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 143.707120] pc : hist_field_name.part.0+0x14/0x140 [ 143.707504] lr : hist_field_name.part.0+0x104/0x140 [ 143.707774] sp : ffff800008333a30 [ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0 [ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800 [ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001 [ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000 [ 143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c [ 143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c [ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d [ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000 [ 143.711746] Call trace: [ 143.712115] hist_field_name.part.0+0x14/0x140 [ 143.712642] hist_field_name.part.0+0x104/0x140 [ 143.712925] hist_field_print+0x28/0x140 [ 143.713125] event_hist_trigger_print+0x174/0x4d0 [ 143.713348] hist_show+0xf8/0x980 [ 143.713521] seq_read_iter+0x1bc/0x4b0 [ 143.713711] seq_read+0x8c/0xc4 [ 143.713876] vfs_read+0xc8/0x2a4 [ 143.714043] ksys_read+0x70/0xfc [ 143.714218] __arm64_sys_read+0x24/0x30 [ 143.714400] invoke_syscall+0x50/0x120 [ 143.714587] el0_svc_common.constprop.0+0x4c/0x100 [ 143.714807] do_el0_svc+0x44/0xd0 [ 143.714970] el0_svc+0x2c/0x84 [ 143.715134] el0t_64_sync_handler+0xbc/0x140 [ 143.715334] el0t_64_sync+0x190/0x194 [ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000) [ 143.716510] ---[ end trace 0000000000000000 ]--- Segmentation fault
Modified: 2025-11-12
CVE-2023-53094
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: fsl_lpuart: fix race on RX DMA shutdown
From time to time DMA completion can come in the middle of DMA shutdown:
- https://git.kernel.org/stable/c/19a98d56dfedafb25652bdb9cd48a4e73ceba702
- https://git.kernel.org/stable/c/1be6f2b15f902c02e055ae0b419ca789200473c9
- https://git.kernel.org/stable/c/2a36b444cace9580380467fd1183bb5e85bcc80a
- https://git.kernel.org/stable/c/90530e7214c8a04dcdde57502d93fa96af288c38
- https://git.kernel.org/stable/c/954fc9931f0aabf272b5674cf468affdd88d3a36
Modified: 2025-11-12
CVE-2023-53095
In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix a NULL pointer dereference The LRU mechanism may look up a resource in the process of being removed from an object. The locking rules here are a bit unclear but it looks currently like res->bo assignment is protected by the LRU lock, whereas bo->resource is protected by the object lock, while *clearing* of bo->resource is also protected by the LRU lock. This means that if we check that bo->resource points to the LRU resource under the LRU lock we should be safe. So perform that check before deciding to swap out a bo. That avoids dereferencing a NULL bo->resource in ttm_bo_swapout().
Modified: 2025-11-12
CVE-2023-53096
In the Linux kernel, the following vulnerability has been resolved: interconnect: fix mem leak when freeing nodes The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed.
- https://git.kernel.org/stable/c/2e0b13a1827229a02abef97b50ffaf89ba25370a
- https://git.kernel.org/stable/c/3167306455d0fbbbcf08cb25651acc527a86a95e
- https://git.kernel.org/stable/c/a5904f415e1af72fa8fe6665aa4f554dc2099a95
- https://git.kernel.org/stable/c/c1722e4113281fb34e5b4fb5c5387b17cd39a537
- https://git.kernel.org/stable/c/efae80ca13faa94457208852825731da44a788ad
- https://git.kernel.org/stable/c/f1e3a20c60196c37a402c584d0c9de306ba988ce
Modified: 2025-11-12
CVE-2023-53097
In the Linux kernel, the following vulnerability has been resolved: powerpc/iommu: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2025-11-12
CVE-2023-53098
In the Linux kernel, the following vulnerability has been resolved: media: rc: gpio-ir-recv: add remove function In case runtime PM is enabled, do runtime PM clean up to remove cpu latency qos request, otherwise driver removal may have below kernel dump: [ 19.463299] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048 [ 19.472161] Mem abort info: [ 19.474985] ESR = 0x0000000096000004 [ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.484081] SET = 0, FnV = 0 [ 19.487149] EA = 0, S1PTW = 0 [ 19.490361] FSC = 0x04: level 0 translation fault [ 19.495256] Data abort info: [ 19.498149] ISV = 0, ISS = 0x00000004 [ 19.501997] CM = 0, WnR = 0 [ 19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000 [ 19.511432] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000 [ 19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last unloaded: rc_core] [ 19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted 6.2.0-rc1-00028-g2c397a46d47c #72 [ 19.531854] Hardware name: FSL i.MX8MM EVK board (DT) [ 19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110 [ 19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.557294] sp : ffff800008ce3740 [ 19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27: ffff800008ce3d50 [ 19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24: ffffc7e3f9ef0e30 [ 19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21: 0000000000000008 [ 19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18: ffffffffffffffff [ 19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15: ffffffffffffffff [ 19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12: 0000000000000001 [ 19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 : 0000000000000008 [ 19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 000000000f0bfe9f [ 19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 : ffff006180382010 [ 19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 : 0000000000000020 [ 19.638548] Call trace: [ 19.640995] cpu_latency_qos_remove_request+0x20/0x110 [ 19.646142] gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.652339] pm_generic_runtime_suspend+0x2c/0x44 [ 19.657055] __rpm_callback+0x48/0x1dc [ 19.660807] rpm_callback+0x6c/0x80 [ 19.664301] rpm_suspend+0x10c/0x640 [ 19.667880] rpm_idle+0x250/0x2d0 [ 19.671198] update_autosuspend+0x38/0xe0 [ 19.675213] pm_runtime_set_autosuspend_delay+0x40/0x60 [ 19.680442] gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv] [ 19.685941] platform_probe+0x68/0xc0 [ 19.689610] really_probe+0xc0/0x3dc [ 19.693189] __driver_probe_device+0x7c/0x190 [ 19.697550] driver_probe_device+0x3c/0x110 [ 19.701739] __driver_attach+0xf4/0x200 [ 19.705578] bus_for_each_dev+0x70/0xd0 [ 19.709417] driver_attach+0x24/0x30 [ 19.712998] bus_add_driver+0x17c/0x240 [ 19.716834] driver_register+0x78/0x130 [ 19.720676] __platform_driver_register+0x28/0x34 [ 19.725386] gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv] [ 19.731404] do_one_initcall+0x44/0x2ac [ 19.735243] do_init_module+0x48/0x1d0 [ 19.739003] load_module+0x19fc/0x2034 [ 19.742759] __do_sys_finit_module+0xac/0x12c [ 19.747124] __arm64_sys_finit_module+0x20/0x30 [ 19.751664] invoke_syscall+0x48/0x114 [ 19.755420] el0_svc_common.constprop.0+0xcc/0xec [ 19.760132] do_el0_svc+0x38/0xb0 [ 19.763456] el0_svc+0x2c/0x84 [ 19.766516] el0t_64_sync_handler+0xf4/0x120 [ 19.770789] el0t_64_sync+0x190/0x194 [ 19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400) [ 19.780556] ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/00e81f191bc00cb6faabf468960e96ebf0404a6c
- https://git.kernel.org/stable/c/2ece4d2f7eac1cb51dc0e9859e09bfdb00faa28e
- https://git.kernel.org/stable/c/30040818b338b8ebc956ce0ebd198f8d593586a6
- https://git.kernel.org/stable/c/513572bb89e8075f5d2a2bb4c89f1152e44da9d8
- https://git.kernel.org/stable/c/a5c140d88a69eb43de2a030f1d7ff7b16bff3b1a
Modified: 2025-11-10
CVE-2023-53099
In the Linux kernel, the following vulnerability has been resolved:
firmware: xilinx: don't make a sleepable memory allocation from an atomic context
The following issue was discovered using lockdep:
[ 6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209
[ 6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0
[ 6.702431] 2 locks held by swapper/0/1:
[ 6.706300] #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4c/0x90
[ 6.714900] #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, at: clk_enable_lock+0x4c/0x140
[ 6.723156] irq event stamp: 304030
[ 6.726596] hardirqs last enabled at (304029): [
- https://git.kernel.org/stable/c/162049c31eb64308afa22e341a257a723526eb5c
- https://git.kernel.org/stable/c/38ed310c22e7a0fc978b1f8292136a4a4a8b3051
- https://git.kernel.org/stable/c/86afb633beaa02ee95b5126a14c9f22cfade4fd9
- https://git.kernel.org/stable/c/9bbab2843f2d1337a268499a1c02b435d2985a17
- https://git.kernel.org/stable/c/b37d3ccbd549494890672136a0e623eb010d46a7
Modified: 2025-11-10
CVE-2023-53100
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in ext4_update_inline_data
Syzbot found the following issue:
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
Modules linked in:
CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/2b96b4a5d9443ca4cad58b0040be455803c05a42
- https://git.kernel.org/stable/c/35161cec76772f74526f5886ad4082ec48511d5c
- https://git.kernel.org/stable/c/39c5df2ca544368b44b59d0f6d80131e90763371
- https://git.kernel.org/stable/c/74d775083e9f3d9dadf9e3b5f3e0028d1ad0bd5c
- https://git.kernel.org/stable/c/92eee6a82a9a6f9f83559e17a2b6b935e1a5cd25
- https://git.kernel.org/stable/c/a9bd94f67b27739bbe8583c52256502bd4cc7e83
- https://git.kernel.org/stable/c/c5aa102b433b1890e1ccaa40c06826c77dda1665
- https://git.kernel.org/stable/c/ca500cf2eceb5a8e93bf71ab97b5f7a18ecabce2
Modified: 2025-11-10
CVE-2023-53101
In the Linux kernel, the following vulnerability has been resolved: ext4: zero i_disksize when initializing the bootloader inode If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024); Fix this by setting i_disksize as well as i_size to zero when initiaizing the boot loader inode.
- https://git.kernel.org/stable/c/01a821aacc64d4b05dafd239dbc9b7856686002f
- https://git.kernel.org/stable/c/0d8a6c9a6415999fee1259ccf1796480c026b7d6
- https://git.kernel.org/stable/c/3f00c476da8fe7c4c34ea16abb55d74127120413
- https://git.kernel.org/stable/c/59eee0cdf8c036f554add97a4da7c06d7a9ff34a
- https://git.kernel.org/stable/c/9cb27b1e76f0cc886ac09055bc41c0ab3f205167
- https://git.kernel.org/stable/c/9e9a4cc5486356158554f6ad73027d8635a48b34
- https://git.kernel.org/stable/c/d6c1447e483c05dbcfb3ff77ac04237a82070b8c
- https://git.kernel.org/stable/c/f5361da1e60d54ec81346aee8e3d8baf1be0b762
Modified: 2025-11-10
CVE-2023-53102
In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: disable txq irq before flushing hw
ice_qp_dis() intends to stop a given queue pair that is a target of xsk
pool attach/detach. One of the steps is to disable interrupts on these
queues. It currently is broken in a way that txq irq is turned off
*after* HW flush which in turn takes no effect.
ice_qp_dis():
-> ice_qvec_dis_irq()
--> disable rxq irq
--> flush hw
-> ice_vsi_stop_tx_ring()
-->disable txq irq
Below splat can be triggered by following steps:
- start xdpsock WITHOUT loading xdp prog
- run xdp_rxq_info with XDP_TX action on this interface
- start traffic
- terminate xdpsock
[ 256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018
[ 256.319560] #PF: supervisor read access in kernel mode
[ 256.324775] #PF: error_code(0x0000) - not-present page
[ 256.329994] PGD 0 P4D 0
[ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G OE 6.2.0-rc5+ #51
[ 256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice]
[ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44
[ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206
[ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f
[ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80
[ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000
[ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000
[ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600
[ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000
[ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0
[ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 256.457770] PKRU: 55555554
[ 256.460529] Call Trace:
[ 256.463015]
- https://git.kernel.org/stable/c/243cde8de10894d7812c8a6b62653bf04d8f9700
- https://git.kernel.org/stable/c/2ecc6e44959382f95c9d427cd8da85121a9cecda
- https://git.kernel.org/stable/c/b830c9642386867863ac64295185f896ff2928ac
- https://git.kernel.org/stable/c/b89a453c6918e0f346fb0562e8c7812b94d28c73
- https://git.kernel.org/stable/c/cccba1ff0798a27f7b8d0c06762ef977400a2afb
Modified: 2025-11-10
CVE-2023-53103
In the Linux kernel, the following vulnerability has been resolved:
bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails
syzbot reported a warning[1] where the bond device itself is a slave and
we try to enslave a non-ethernet device as the first slave which fails
but then in the error path when ether_setup() restores the bond device
it also clears all flags. In my previous fix[2] I restored the
IFF_MASTER flag, but I didn't consider the case that the bond device
itself might also be a slave with IFF_SLAVE set, so we need to restore
that flag as well. Use the bond_ether_setup helper which does the right
thing and restores the bond's flags properly.
Steps to reproduce using a nlmon dev:
$ ip l add nlmon0 type nlmon
$ ip l add bond1 type bond
$ ip l add bond2 type bond
$ ip l set bond1 master bond2
$ ip l set dev nlmon0 master bond1
$ ip -d l sh dev bond1
22: bond1:
Modified: 2025-11-10
CVE-2023-53105
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix cleanup null-ptr deref on encap lock
During module is unloaded while a peer tc flow is still offloaded,
first the peer uplink rep profile is changed to a nic profile, and so
neigh encap lock is destroyed. Next during unload, the VF reps netdevs
are unregistered which causes the original non-peer tc flow to be deleted,
which deletes the peer flow. The peer flow deletion detaches the encap
entry and try to take the already destroyed encap lock, causing the
below trace.
Fix this by clearing peer flows during tc eswitch cleanup
(mlx5e_tc_esw_cleanup()).
Relevant trace:
[ 4316.837128] BUG: kernel NULL pointer dereference, address: 00000000000001d8
[ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40
[ 4316.851897] Call Trace:
[ 4316.852481]
Modified: 2025-11-10
CVE-2023-53106
In the Linux kernel, the following vulnerability has been resolved: nfc: st-nci: Fix use after free bug in ndlc_remove due to race condition This bug influences both st_nci_i2c_remove and st_nci_spi_remove. Take st_nci_i2c_remove as an example. In st_nci_i2c_probe, it called ndlc_probe and bound &ndlc->sm_work with llt_ndlc_sm_work. When it calls ndlc_recv or timeout handler, it will finally call schedule_work to start the work. When we call st_nci_i2c_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in ndlc_remove CPU0 CPU1 |llt_ndlc_sm_work st_nci_i2c_remove | ndlc_remove | st_nci_remove | nci_free_device| kfree(ndev) | //free ndlc->ndev | |llt_ndlc_rcv_queue |nci_recv_frame |//use ndlc->ndev
- https://git.kernel.org/stable/c/2156490c4b7cacda9a18ec99929940b8376dc0e3
- https://git.kernel.org/stable/c/3405eb641dafcc8b28d174784b203c1622c121bf
- https://git.kernel.org/stable/c/43aa468df246175207a7d5d7d6d31b231f15b49c
- https://git.kernel.org/stable/c/5000fe6c27827a61d8250a7e4a1d26c3298ef4f6
- https://git.kernel.org/stable/c/5e331022b448fbc5e76f24349cd0246844dcad25
- https://git.kernel.org/stable/c/84dd9cc34014e3a3dcce0eb6d54b8a067e97676b
- https://git.kernel.org/stable/c/b0c202a8dc63008205a5d546559736507a9aae66
- https://git.kernel.org/stable/c/f589e5b56c562d99ea74e05b1c3f0eab78aa17a3
Modified: 2025-11-10
CVE-2023-53107
In the Linux kernel, the following vulnerability has been resolved:
veth: Fix use after free in XDP_REDIRECT
Commit 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order
to accept non-linear skb") introduced a bug where it tried to
use pskb_expand_head() if the headroom was less than
XDP_PACKET_HEADROOM. This however uses kmalloc to expand the head,
which will later allow consume_skb() to free the skb while is it still
in use by AF_XDP.
Previously if the headroom was less than XDP_PACKET_HEADROOM we
continued on to allocate a new skb from pages so this restores that
behavior.
BUG: KASAN: use-after-free in __xsk_rcv+0x18d/0x2c0
Read of size 78 at addr ffff888976250154 by task napi/iconduit-g/148640
CPU: 5 PID: 148640 Comm: napi/iconduit-g Kdump: loaded Tainted: G O 6.1.4-cloudflare-kasan-2023.1.2 #1
Hardware name: Quanta Computer Inc. QuantaPlex T41S-2U/S2S-MB, BIOS S2S_3B10.03 06/21/2018
Call Trace:
Modified: 2025-11-10
CVE-2023-53108
In the Linux kernel, the following vulnerability has been resolved: net/iucv: Fix size of interrupt data iucv_irq_data needs to be 4 bytes larger. These bytes are not used by the iucv module, but written by the z/VM hypervisor in case a CPU is deconfigured. Reported as: BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten ----------------------------------------------------------------------------- 0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1 __kmem_cache_alloc_node+0x166/0x450 kmalloc_node_trace+0x3a/0x70 iucv_cpu_prepare+0x44/0xd0 cpuhp_invoke_callback+0x156/0x2f0 cpuhp_issue_call+0xf0/0x298 __cpuhp_setup_state_cpuslocked+0x136/0x338 __cpuhp_setup_state+0xf4/0x288 iucv_init+0xf4/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1 __kmem_cache_free+0x308/0x358 iucv_init+0x92/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0| Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000 Redzone 0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2 ................ Object 0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc ................ Object 0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400580: cc cc cc cc cc cc cc cc ........ Padding 00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<000000032aa034ec>] dump_stack_lvl+0xac/0x100 [<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140 [<0000000329f5aa78>] check_object+0x370/0x3c0 [<0000000329f5ede6>] free_debug_processing+0x15e/0x348 [<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0 [<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8 [<0000000329f61768>] __kmem_cache_free+0x308/0x358 [<000000032a91465c>] iucv_cpu_dead+0x6c/0x88 [<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0 [<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0 [<0000000329c3243e>] cpu_device_down+0x4e/0x78 [<000000032a61dee0>] device_offline+0xc8/0x118 [<000000032a61e048>] online_store+0x60/0xe0 [<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8 [<0000000329fab65c>] vfs_write+0x174/0x360 [<0000000329fab9fc>] ksys_write+0x74/0x100 [<000000032aa03a5a>] __do_syscall+0x1da/0x208 [<000000032aa177b2>] system_call+0x82/0xb0 INFO: lockdep is turned off. FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc FIX dma-kmalloc-64: Object at 0x0000000000400540 not freed
- https://git.kernel.org/stable/c/3cfdefdaaa4b2a77e84d0db5e0a47a7aa3bb615a
- https://git.kernel.org/stable/c/3d87debb8ed2649608ff432699e7c961c0c6f03b
- https://git.kernel.org/stable/c/71da5991b6438ad6da13ceb25465ee2760a1c52f
- https://git.kernel.org/stable/c/93a970494881004c348d8feb38463ee72496e99a
- https://git.kernel.org/stable/c/a908eae0f71811afee86be7088692f1aa5855c3b
- https://git.kernel.org/stable/c/b0d2bb5e31a693ebc8888eb407f8a257a3680efa
- https://git.kernel.org/stable/c/bd2e78462ae18484e55ae4d285df2c86b86bdd12
- https://git.kernel.org/stable/c/c78f1345db4e4b3b78f9b768f4074ebd60abe966
Modified: 2025-11-10
CVE-2023-53109
In the Linux kernel, the following vulnerability has been resolved: net: tunnels: annotate lockless accesses to dev->needed_headroom IP tunnels can apparently update dev->needed_headroom in their xmit path. This patch takes care of three tunnels xmit, and also the core LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA() helpers. More changes might be needed for completeness. BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmit read to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1: ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/i ---truncated---
- https://git.kernel.org/stable/c/4b397c06cb987935b1b097336532aa6b4210e091
- https://git.kernel.org/stable/c/51f3bd3765bc5ca4583af07a00833da00d2ace1d
- https://git.kernel.org/stable/c/5aaab217c8f5387b9c5fff9e940d80f135e04366
- https://git.kernel.org/stable/c/8e206f66d824b3b28a7f9ee1366dfc79a937bb46
- https://git.kernel.org/stable/c/9b86a8702b042ee4e15d2d46375be873a6a8834f
- https://git.kernel.org/stable/c/a69b72b57b7d269e833e520ba7500d556e8189b6
- https://git.kernel.org/stable/c/be59b87ee4aed81db7c10e44f603866a0ac3ca5d
- https://git.kernel.org/stable/c/e0a557fc1daf5c1086e47150a4571aebadbb62be
Modified: 2025-11-10
CVE-2023-53110
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler() When performing a stress test on SMC-R by rmmod mlx5_ib driver during the wrk/nginx test, we found that there is a probability of triggering a panic while terminating all link groups. This issue dues to the race between smc_smcr_terminate_all() and smc_buf_create(). smc_smcr_terminate_all smc_buf_create /* init */ conn->sndbuf_desc = NULL; ... __smc_lgr_terminate smc_conn_kill smc_close_abort smc_cdc_get_slot_and_msg_send __softirqentry_text_start smc_wr_tx_process_cqe smc_cdc_tx_handler READ(conn->sndbuf_desc->len); /* panic dues to NULL sndbuf_desc */ conn->sndbuf_desc = xxx; This patch tries to fix the issue by always to check the sndbuf_desc before send any cdc msg, to make sure that no null pointer is seen during cqe processing.
- https://git.kernel.org/stable/c/22a825c541d775c1dbe7b2402786025acad6727b
- https://git.kernel.org/stable/c/31817c530768b0199771ec6019571b4f0ddbf230
- https://git.kernel.org/stable/c/3c270435db8aa34929263dddae8fd050f5216ecb
- https://git.kernel.org/stable/c/3ebac7cf0a184a8102821a7a00203f02bebda83c
- https://git.kernel.org/stable/c/b108bd9e6be000492ebebe867daa699285978a10
Modified: 2025-11-10
CVE-2023-53111
In the Linux kernel, the following vulnerability has been resolved: loop: Fix use-after-free issues do_req_filebacked() calls blk_mq_complete_request() synchronously or asynchronously when using asynchronous I/O unless memory allocation fails. Hence, modify loop_handle_cmd() such that it does not dereference 'cmd' nor 'rq' after do_req_filebacked() finished unless we are sure that the request has not yet been completed. This patch fixes the following kernel crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000054 Call trace: css_put.42938+0x1c/0x1ac loop_process_work+0xc8c/0xfd4 loop_rootcg_workfn+0x24/0x34 process_one_work+0x244/0x558 worker_thread+0x400/0x8fc kthread+0x16c/0x1e0 ret_from_fork+0x10/0x20
Modified: 2025-11-10
CVE-2023-53112
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/sseu: fix max_subslices array-index-out-of-bounds access
It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU
mask internally in UAPI format") exposed a potential out-of-bounds
access, reported by UBSAN as following on a laptop with a gen 11 i915
card:
UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27
index 6 is out of range for type 'u16 [6]'
CPU: 2 PID: 165 Comm: systemd-udevd Not tainted 6.2.0-9-generic #9-Ubuntu
Hardware name: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 03/22/2022
Call Trace:
Modified: 2025-11-10
CVE-2023-53113
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: fix NULL-ptr deref in offchan check If, e.g. in AP mode, the link was already created by userspace but not activated yet, it has a chandef but the chandef isn't valid and has no channel. Check for this and ignore this link.
Modified: 2025-11-10
CVE-2023-53114
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix kernel crash during reboot when adapter is in recovery mode
If the driver detects during probe that firmware is in recovery
mode then i40e_init_recovery_mode() is called and the rest of
probe function is skipped including pci_set_drvdata(). Subsequent
i40e_shutdown() called during shutdown/reboot dereferences NULL
pointer as pci_get_drvdata() returns NULL.
To fix call pci_set_drvdata() also during entering to recovery mode.
Reproducer:
1) Lets have i40e NIC with firmware in recovery mode
2) Run reboot
Result:
[ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver
[ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.
[ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.
[ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
[ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
[ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0
[ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.
[ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
[ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
[ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0
...
[ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2
[ 156.318330] #PF: supervisor write access in kernel mode
[ 156.323546] #PF: error_code(0x0002) - not-present page
[ 156.328679] PGD 0 P4D 0
[ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1
[ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022
[ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]
[ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00
- https://git.kernel.org/stable/c/3cbecb1c9085a00155639404f7addbcbfc987ba3
- https://git.kernel.org/stable/c/4ff82695266576a0b4f1077a7100b2451e476df4
- https://git.kernel.org/stable/c/6e18f66b704bd725196508c1db93bf7338cdc8de
- https://git.kernel.org/stable/c/7e4f8a0c495413a50413e8c9f1032ce1bc633bae
- https://git.kernel.org/stable/c/b3826fb3ea14646b3d4e6309bfc384b349f36eb6
- https://git.kernel.org/stable/c/c703362a66ea971905b9dc153fc54d1b6ac05423
Modified: 2025-11-10
CVE-2023-53115
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix memory leaks in mpi3mr_init_ioc() Don't allocate memory again when IOC is being reinitialized.
Modified: 2025-11-10
CVE-2023-53116
In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid potential UAF in nvmet_req_complete() An nvme target ->queue_response() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpu_ref_put() is called in nvmet_req_complete(). Avoid such problem by using a local variable to save the sq pointer before calling __nvmet_req_complete(), thus avoiding dereferencing the req pointer after that function call.
- https://git.kernel.org/stable/c/04c394208831d5e0d5cfee46722eb0f033cd4083
- https://git.kernel.org/stable/c/6173a77b7e9d3e202bdb9897b23f2a8afe7bf286
- https://git.kernel.org/stable/c/8ed9813871038b25a934b21ab76b5b7dbf44fc3a
- https://git.kernel.org/stable/c/a6317235da8aa7cb97529ebc8121cc2a4c4c437a
- https://git.kernel.org/stable/c/bcd535f07c58342302a2cd2bdd8894fe0872c8a9
- https://git.kernel.org/stable/c/e5d99b29012bbf0e86929403209723b2806500c1
- https://git.kernel.org/stable/c/f1d5888a5efe345b63c430b256e95acb0a475642
- https://git.kernel.org/stable/c/fafcb4b26393870c45462f9af6a48e581dbbcf7e
Modified: 2025-11-10
CVE-2023-53117
In the Linux kernel, the following vulnerability has been resolved: fs: prevent out-of-bounds array speculation when closing a file descriptor Google-Bug-Id: 114199369
- https://git.kernel.org/stable/c/3d5d9501b634fd268eb56428cda92cd317752d69
- https://git.kernel.org/stable/c/609d54441493c99f21c1823dfd66fa7f4c512ff4
- https://git.kernel.org/stable/c/6631c8da02cfad96c53b217cf647b511c7f34faf
- https://git.kernel.org/stable/c/a759905de9cd6ec9ca08ceadf0920272772ed830
- https://git.kernel.org/stable/c/cec08b7d1ebcd3138d4658b3868ce26aeb1e8e06
- https://git.kernel.org/stable/c/eea8e4e056a5ffbeb539a13854c017d5d62c756a
- https://git.kernel.org/stable/c/f31cd5da636682caea424fa1c22679016cbfc16b
- https://git.kernel.org/stable/c/f8cd8754a03a3748384ee438c572423643c9c315
Modified: 2025-11-10
CVE-2023-53120
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix config page DMA memory leak A fix for: DMA-API: pci 0000:83:00.0: device driver has pending DMA allocations while released from device [count=1]
Modified: 2025-11-10
CVE-2023-53121
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_make_synack() can be called from process context
tcp_rtx_synack() now could be called in process context as explained in
0a375c822497 ("tcp: tcp_rtx_synack() can be called from process
context").
tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU
variables with preemption enabled. This causes the following BUG:
BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464
caller is tcp_make_synack+0x841/0xac0
Call Trace:
- https://git.kernel.org/stable/c/442aa78ed70188b21ccd8669738448702c0a3281
- https://git.kernel.org/stable/c/7613cde8c0c1f02a7ec2e1d536c01b65b135fc1c
- https://git.kernel.org/stable/c/77ad58bca0119e8cc3e0e9d91a3f22caa66e4dfa
- https://git.kernel.org/stable/c/9180aa4622a720b433e842b4d3aa34d73eec577a
- https://git.kernel.org/stable/c/ad07290d63ff6689f50565b02f5b6f34ec15a5ca
- https://git.kernel.org/stable/c/bced3f7db95ff2e6ca29dc4d1c9751ab5e736a09
- https://git.kernel.org/stable/c/d493d4fe88195a144d6a277a90062a7534ed2192
- https://git.kernel.org/stable/c/e23ca307745be3df7fe9762f3e2a7e311a57852e
Modified: 2025-11-10
CVE-2023-53123
In the Linux kernel, the following vulnerability has been resolved: PCI: s390: Fix use-after-free of PCI resources with per-function hotplug On s390 PCI functions may be hotplugged individually even when they belong to a multi-function device. In particular on an SR-IOV device VFs may be removed and later re-added. In commit a50297cf8235 ("s390/pci: separate zbus creation from scanning") it was missed however that struct pci_bus and struct zpci_bus's resource list retained a reference to the PCI functions MMIO resources even though those resources are released and freed on hot-unplug. These stale resources may subsequently be claimed when the PCI function re-appears resulting in use-after-free. One idea of fixing this use-after-free in s390 specific code that was investigated was to simply keep resources around from the moment a PCI function first appeared until the whole virtual PCI bus created for a multi-function device disappears. The problem with this however is that due to the requirement of artificial MMIO addreesses (address cookies) extra logic is then needed to keep the address cookies compatible on re-plug. At the same time the MMIO resources semantically belong to the PCI function so tying their lifecycle to the function seems more logical. Instead a simpler approach is to remove the resources of an individually hot-unplugged PCI function from the PCI bus's resource list while keeping the resources of other PCI functions on the PCI bus untouched. This is done by introducing pci_bus_remove_resource() to remove an individual resource. Similarly the resource also needs to be removed from the struct zpci_bus's resource list. It turns out however, that there is really no need to add the MMIO resources to the struct zpci_bus's resource list at all and instead we can simply use the zpci_bar_struct's resource pointer directly.
Modified: 2025-11-10
CVE-2023-53125
In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Limit packet length to skb->len Packet length retrieved from skb data may be larger than the actual socket buffer length (up to 9026 bytes). In such case the cloned skb passed up the network stack will leak kernel memory contents.
- https://git.kernel.org/stable/c/105db6574281e1e03fcbf87983f4fee111682306
- https://git.kernel.org/stable/c/4a4de0a68b18485c68ab4f0cfa665b1633c6d277
- https://git.kernel.org/stable/c/53966d572d056d6b234cfe76a5f9d60049d3c178
- https://git.kernel.org/stable/c/8ee5df9c039e37b9d8eb5e3de08bfb7f53d31cb6
- https://git.kernel.org/stable/c/9fabdd79051a9fe51388df099aff6e4b660fedd2
- https://git.kernel.org/stable/c/c7bdc137ca163b90917c1eeba4f1937684bd4f8b
- https://git.kernel.org/stable/c/d8b228318935044dafe3a5bc07ee71a1f1424b8d
- https://git.kernel.org/stable/c/e294f0aa47e4844f3d3c8766c02accd5a76a7d4e
Modified: 2025-11-10
CVE-2023-53126
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove() Free mrioc->sas_hba.phy at .remove.
Modified: 2025-11-10
CVE-2023-53127
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix expander node leak in mpi3mr_remove() Add a missing resource clean up in .remove.
Modified: 2025-11-10
CVE-2023-53128
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix throttle_groups memory leak Add a missing kfree().
Modified: 2025-11-10
CVE-2023-53131
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a server shutdown leak Fix a race where kthread_stop() may prevent the threadfn from ever getting called. If that happens the svc_rqst will not be cleaned up.
- https://git.kernel.org/stable/c/7a3720361068ab520aed4608bad31ea9a6cc7fe7
- https://git.kernel.org/stable/c/9ca6705d9d609441d34f8b853e1e4a6369b3b171
- https://git.kernel.org/stable/c/ad7e40ee157ba33950a4ccdc284334580da3638d
- https://git.kernel.org/stable/c/ce7dd61e004002bc1c48d1ca47c887f3f3cc7370
- https://git.kernel.org/stable/c/f74b3286859463cd63cc9d4aeaabd8b0c640182a
Modified: 2025-11-10
CVE-2023-53132
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix mpi3mr_hba_port memory leak in mpi3mr_remove() Free mpi3mr_hba_port at .remove.
Modified: 2025-11-10
CVE-2023-53133
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()
When the buffer length of the recvmsg system call is 0, we got the
flollowing soft lockup problem:
watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]
CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:remove_wait_queue+0xb/0xc0
Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20
RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768
RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040
RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7
R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800
R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0
FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-10
CVE-2023-53134
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Avoid order-5 memory allocation for TPA data The driver needs to keep track of all the possible concurrent TPA (GRO/LRO) completions on the aggregation ring. On P5 chips, the maximum number of concurrent TPA is 256 and the amount of memory we allocate is order-5 on systems using 4K pages. Memory allocation failure has been reported: NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1 Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022 Call Trace: dump_stack+0x57/0x6e warn_alloc.cold.120+0x7b/0xdd ? _cond_resched+0x15/0x30 ? __alloc_pages_direct_compact+0x15f/0x170 __alloc_pages_slowpath.constprop.108+0xc58/0xc70 __alloc_pages_nodemask+0x2d0/0x300 kmalloc_order+0x24/0xe0 kmalloc_order_trace+0x19/0x80 bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en] ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en] __bnxt_open_nic+0x12e/0x780 [bnxt_en] bnxt_open+0x10b/0x240 [bnxt_en] __dev_open+0xe9/0x180 __dev_change_flags+0x1af/0x220 dev_change_flags+0x21/0x60 do_setlink+0x35c/0x1100 Instead of allocating this big chunk of memory and dividing it up for the concurrent TPA instances, allocate each small chunk separately for each TPA instance. This will reduce it to order-0 allocations.
- https://git.kernel.org/stable/c/16f3aae1aa2dd89bc8d073a67f190af580386ae9
- https://git.kernel.org/stable/c/20fd0607acbf9770db9b99e3418dd75614f80b6c
- https://git.kernel.org/stable/c/accd7e23693aaaa9aa0d3e9eca0ae77d1be80ab3
- https://git.kernel.org/stable/c/ad529d1fae1565d38f929479d4ea8aea90054bd2
- https://git.kernel.org/stable/c/d16701a385b54f44bf41ff1d7485e7a11080deb3
- https://git.kernel.org/stable/c/fcae40e65802547def39b4deaa2ae38a29864d81
Modified: 2025-11-10
CVE-2023-53135
In the Linux kernel, the following vulnerability has been resolved:
riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode
When CONFIG_FRAME_POINTER is unset, the stack unwinding function
walk_stackframe randomly reads the stack and then, when KASAN is enabled,
it can lead to the following backtrace:
[ 0.000000] ==================================================================
[ 0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a
[ 0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0
[ 0.000000]
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43
[ 0.000000] Hardware name: riscv-virtio,qemu (DT)
[ 0.000000] Call Trace:
[ 0.000000] [
- https://git.kernel.org/stable/c/17fa90ffba20743c946920fbb0afe160d0ead8c9
- https://git.kernel.org/stable/c/324912d6c0c4006711054d389faa2239c1655e1e
- https://git.kernel.org/stable/c/3a9418d2c93c1c86ce4d0595112d91c7a8e70c2c
- https://git.kernel.org/stable/c/3de277af481ab931fab9e295ad8762692920732a
- https://git.kernel.org/stable/c/76950340cf03b149412fe0d5f0810e52ac1df8cb
- https://git.kernel.org/stable/c/a99a61d9e1bfca2fc37d223a6a185c0eb66aba02
Modified: 2025-11-10
CVE-2023-53136
In the Linux kernel, the following vulnerability has been resolved:
af_unix: fix struct pid leaks in OOB support
syzbot reported struct pid leak [1].
Issue is that queue_oob() calls maybe_add_creds() which potentially
holds a reference on a pid.
But skb->destructor is not set (either directly or by calling
unix_scm_to_skb())
This means that subsequent kfree_skb() or consume_skb() would leak
this reference.
In this fix, I chose to fully support scm even for the OOB message.
[1]
BUG: memory leak
unreferenced object 0xffff8881053e7f80 (size 128):
comm "syz-executor242", pid 5066, jiffies 4294946079 (age 13.220s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
Modified: 2025-11-10
CVE-2023-53138
In the Linux kernel, the following vulnerability has been resolved:
net: caif: Fix use-after-free in cfusbl_device_notify()
syzbot reported use-after-free in cfusbl_device_notify() [1]. This
causes a stack trace like below:
BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138
Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214
CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
- https://git.kernel.org/stable/c/1793da97a23e31c5bf06631f3f3e5a25f368fd64
- https://git.kernel.org/stable/c/287027d8a567168a5d8ce5cb0cba16a34791a48c
- https://git.kernel.org/stable/c/3f14457e1584224f4296af613bbd99deb60b5d91
- https://git.kernel.org/stable/c/68a45c3cf0e2242a533657f4f535d9b6a7447a79
- https://git.kernel.org/stable/c/9781e98a97110f5e76999058368b4be76a788484
- https://git.kernel.org/stable/c/9dc16be373b382ddd4c274052a6e870a95e76c01
- https://git.kernel.org/stable/c/c3aaec463a632cf4187dc017e421bfa69d7834a9
- https://git.kernel.org/stable/c/d1a11bbdbb5ea9f172019c5a4a3e9d8eabd72179
Modified: 2025-11-10
CVE-2023-53139
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause out-of-bounds write in device_property_read_u8_array later.
- https://git.kernel.org/stable/c/0a3664a1058d4b2b1ea2112cc275ca47fba7fc08
- https://git.kernel.org/stable/c/11f180a5d62a51b484e9648f9b310e1bd50b1a57
- https://git.kernel.org/stable/c/27824b2f98818215adc9661e563252c48dab1a13
- https://git.kernel.org/stable/c/4357bbb921fe9e81d0fd9f70d669d1f177d8380e
- https://git.kernel.org/stable/c/80be62358fa5507cefbaa067c7e6648401f2c3da
- https://git.kernel.org/stable/c/98f49e693e02c1dafd5786be3468657840dd6f06
- https://git.kernel.org/stable/c/ad11b872bc9b5d27e56183c6b01f9218c85395d2
- https://git.kernel.org/stable/c/ce93f1afc05941a572f5a69e2ed4012af905a693
Modified: 2025-11-10
CVE-2023-53140
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Remove the /proc/scsi/${proc_name} directory earlier Remove the /proc/scsi/${proc_name} directory earlier to fix a race condition between unloading and reloading kernel modules. This fixes a bug introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core"). Fix the following kernel warning: proc_dir_entry 'scsi/scsi_debug' already registered WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0 Call Trace: proc_mkdir+0xb5/0xe0 scsi_proc_hostdir_add+0xb5/0x170 scsi_host_alloc+0x683/0x6c0 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug] really_probe+0x159/0x540 __driver_probe_device+0xdc/0x230 driver_probe_device+0x4f/0x120 __device_attach_driver+0xef/0x180 bus_for_each_drv+0xe5/0x130 __device_attach+0x127/0x290 device_initial_probe+0x17/0x20 bus_probe_device+0x110/0x130 device_add+0x673/0xc80 device_register+0x1e/0x30 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug] scsi_debug_init+0x64f/0x1000 [scsi_debug] do_one_initcall+0xd7/0x470 do_init_module+0xe7/0x330 load_module+0x122a/0x12c0 __do_sys_finit_module+0x124/0x1a0 __x64_sys_finit_module+0x46/0x50 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/13daafe1e209b03e9bda16ff2bd2b2da145a139b
- https://git.kernel.org/stable/c/17e98a5ede81b7696bec421f7afa2dfe467f5e6b
- https://git.kernel.org/stable/c/1ec363599f8346d5a8d08c71a0d9860d6c420ec0
- https://git.kernel.org/stable/c/6b223e32d66ca9db1f252f433514783d8b22a8e1
- https://git.kernel.org/stable/c/891a3cba425cf483d96facca55aebd6ff1da4338
- https://git.kernel.org/stable/c/e471e928de97b00f297ad1015cc14f9459765713
- https://git.kernel.org/stable/c/fc663711b94468f4e1427ebe289c9f05669699c9
Modified: 2025-11-10
CVE-2023-53141
In the Linux kernel, the following vulnerability has been resolved:
ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
ila_xlat_nl_cmd_get_mapping() generates an empty skb,
triggerring a recent sanity check [1].
Instead, return an error code, so that user space
can get it.
[1]
skb_assert_len
WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]
WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
Modules linked in:
CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : skb_assert_len include/linux/skbuff.h:2527 [inline]
pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
lr : skb_assert_len include/linux/skbuff.h:2527 [inline]
lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
sp : ffff80001e0d6c40
x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0
x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00
x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10
x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0
x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001
x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600
x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e
Call trace:
skb_assert_len include/linux/skbuff.h:2527 [inline]
__dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
dev_queue_xmit include/linux/netdevice.h:3033 [inline]
__netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]
__netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325
netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338
__netlink_sendskb net/netlink/af_netlink.c:1283 [inline]
netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292
netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380
nlmsg_unicast include/net/netlink.h:1099 [inline]
genlmsg_unicast include/net/genetlink.h:433 [inline]
genlmsg_reply include/net/genetlink.h:443 [inline]
ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493
genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065
netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574
genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0x558/0x844 net/socket.c:2479
___sys_sendmsg net/socket.c:2533 [inline]
__sys_sendmsg+0x26c/0x33c net/socket.c:2562
__do_sys_sendmsg net/socket.c:2571 [inline]
__se_sys_sendmsg net/socket.c:2569 [inline]
__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193
el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
irq event stamp: 136484
hardirqs last enabled at (136483): [
- https://git.kernel.org/stable/c/25b54f247ea060aeb85ec88a82c75060fca03521
- https://git.kernel.org/stable/c/42d9ed4e5dc5f87fbd67c232e2e4a9b88ceeb47f
- https://git.kernel.org/stable/c/60fe7cb483c8c5dcadaeeac867251d6e59c7badc
- https://git.kernel.org/stable/c/693aa2c0d9b6d5b1f2745d31b6e70d09dbbaf06e
- https://git.kernel.org/stable/c/783f218940b3c7b872e4111d0145000f26ecbdf6
- https://git.kernel.org/stable/c/91aceb3844d4aec555c7f423f9fd843eff5835e9
- https://git.kernel.org/stable/c/b26bc5861505f04dea933ca3e522772b20fa086f
- https://git.kernel.org/stable/c/c631e52aea0fc8d4deea06e439f5810a8b40ad0f
Modified: 2025-11-10
CVE-2023-53142
In the Linux kernel, the following vulnerability has been resolved: ice: copy last block omitted in ice_get_module_eeprom() ice_get_module_eeprom() is broken since commit e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") In this refactor, ice_get_module_eeprom() reads the eeprom in blocks of size 8. But the condition that should protect the buffer overflow ignores the last block. The last block always contains zeros. Bug uncovered by ethtool upstream commit 9538f384b535 ("netlink: eeprom: Defer page requests to individual parsers") After this commit, ethtool reads a block with length = 1; to read the SFF-8024 identifier value. unpatched driver: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Offset Values ------ ------ 0x0090: 00 00 00 00 00 00 00 00 $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 00 00 00 00 $ $ ethtool -m enp65s0f0np0 Offset Values ------ ------ 0x0000: 11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00 0x0070: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 patched driver: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 61 6e 6f 78 $ ethtool -m enp65s0f0np0 Identifier : 0x11 (QSFP28) Extended identifier : 0x00 Extended identifier description : 1.5W max. Power consumption Extended identifier description : No CDR in TX, No CDR in RX Extended identifier description : High Power Class (> 3.5 W) not enabled Connector : 0x23 (No separable connector) Transceiver codes : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Transceiver type : 40G Ethernet: 40G Base-CR4 Transceiver type : 25G Ethernet: 25G Base-CR CA-N Encoding : 0x05 (64B/66B) BR, Nominal : 25500Mbps Rate identifier : 0x00 Length (SMF,km) : 0km Length (OM3 50um) : 0m Length (OM2 50um) : 0m Length (OM1 62.5um) : 0m Length (Copper or Active cable) : 1m Transmitter technology : 0xa0 (Copper cable unequalized) Attenuation at 2.5GHz : 4db Attenuation at 5.0GHz : 5db Attenuation at 7.0GHz : 7db Attenuation at 12.9GHz : 10db ........ ....
Modified: 2025-11-10
CVE-2023-53143
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix another off-by-one fsmap error on 1k block filesystems
Apparently syzbot figured out that issuing this FSMAP call:
struct fsmap_head cmd = {
.fmh_count = ...;
.fmh_keys = {
{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
},
...
};
ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);
Produces this crash if the underlying filesystem is a 1k-block ext4
filesystem:
kernel BUG at fs/ext4/ext4.h:3331!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]
RSP: 0018:ffffc90007c03998 EFLAGS: 00010246
RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000
RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11
RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400
R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001
R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398
FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0
Call Trace:
- https://git.kernel.org/stable/c/15ebade3266b300da9cd1edce4004fe8fd6a2b88
- https://git.kernel.org/stable/c/1d2366624b4c19a2ba6baf67fe57f4a1b0f67c05
- https://git.kernel.org/stable/c/a70b49dc7eee5dbe3775a650ce598e3557ff5475
- https://git.kernel.org/stable/c/c24f838493792b5e78a3596b4ca96375aa0af4c2
- https://git.kernel.org/stable/c/c5d7c31e17224d847a330180ec1b03bf390632b2
- https://git.kernel.org/stable/c/c993799baf9c5861f8df91beb80e1611b12efcbd
- https://git.kernel.org/stable/c/eb3a695aa71a514f2e7f5778e05faba3733b70a0
- https://git.kernel.org/stable/c/f16054ac1774915160ca4e1c73ff7a269465a1b9
Modified: 2025-11-10
CVE-2023-53144
In the Linux kernel, the following vulnerability has been resolved: erofs: fix wrong kunmap when using LZMA on HIGHMEM platforms As the call trace shown, the root cause is kunmap incorrect pages: BUG: kernel NULL pointer dereference, address: 00000000 CPU: 1 PID: 40 Comm: kworker/u5:0 Not tainted 6.2.0-rc5 #4 Workqueue: erofs_worker z_erofs_decompressqueue_work EIP: z_erofs_lzma_decompress+0x34b/0x8ac z_erofs_decompress+0x12/0x14 z_erofs_decompress_queue+0x7e7/0xb1c z_erofs_decompressqueue_work+0x32/0x60 process_one_work+0x24b/0x4d8 ? process_one_work+0x1a4/0x4d8 worker_thread+0x14c/0x3fc kthread+0xe6/0x10c ? rescuer_thread+0x358/0x358 ? kthread_complete_and_exit+0x18/0x18 ret_from_fork+0x1c/0x28 ---[ end trace 0000000000000000 ]--- The bug is trivial and should be fixed now. It has no impact on !HIGHMEM platforms.
Modified: 2025-11-12
CVE-2023-53145
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btsdio: fix use after free bug in btsdio_remove due to race condition In btsdio_probe, the data->work is bound with btsdio_work. It will be started in btsdio_send_frame. If the btsdio_remove runs with a unfinished work, there may be a race condition that hdev is freed but used in btsdio_work. Fix it by canceling the work before do cleanup in btsdio_remove.
- https://git.kernel.org/stable/c/179c65828593aff1f444e15debd40a477cb23cf4
- https://git.kernel.org/stable/c/3efcbf25e5ab4d4ad1b7e6ba0869ff85540e3f6e
- https://git.kernel.org/stable/c/6c3653627397a0d6eab19b20a59423e118985a6b
- https://git.kernel.org/stable/c/73f7b171b7c09139eb3c6a5677c200dc1be5f318
- https://git.kernel.org/stable/c/746b363bef41cc159c051c47f9e30800bc6b520d
- https://git.kernel.org/stable/c/a5c2a467e9e789ae0891de55b766daac52e3b7b3
- https://git.kernel.org/stable/c/a6650d27ab2c12a8ee750f396edb5ac8b4558b2e
Modified: 2025-11-12
CVE-2023-53146
In the Linux kernel, the following vulnerability has been resolved: media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer() In dw2102_i2c_transfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach dw2102_i2c_transfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 950e252cb469 ("[media] dw2102: limit messages to buffer size")
- https://git.kernel.org/stable/c/08dfcbd03b2b7f918c4f87c6ff637054e510df74
- https://git.kernel.org/stable/c/5ae544d94abc8ff77b1b9bf8774def3fa5689b5b
- https://git.kernel.org/stable/c/77cbd42d29de9ffc93d5529bab8813cde53af14c
- https://git.kernel.org/stable/c/903566208ae6bb9c0e7e54355ce75bf6cf72485d
- https://git.kernel.org/stable/c/97fdbdb750342cbc204befde976872fedb406ee6
- https://git.kernel.org/stable/c/beb9550494e7349f92b9eaa283256a5ad9b1c9be
- https://git.kernel.org/stable/c/ecbe6d011b95c7da59f014f8d26cb7245ed1e11e
- https://git.kernel.org/stable/c/fb28afab113a82b89ffec48c8155ec05b4f8cb5e
Modified: 2025-11-25
CVE-2023-53147
In the Linux kernel, the following vulnerability has been resolved:
xfrm: add NULL check in xfrm_update_ae_params
Normally, x->replay_esn and x->preplay_esn should be allocated at
xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the
xfrm_update_ae_params(...) is okay to update them. However, the current
implementation of xfrm_new_ae(...) allows a malicious user to directly
dereference a NULL pointer and crash the kernel like below.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4
RIP: 0010:memcpy_orig+0xad/0x140
Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c
RSP: 0018:ffff888008f57658 EFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571
RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818
R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000
FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/00374d9b6d9f932802b55181be9831aa948e5b7c
- https://git.kernel.org/stable/c/075448a2eb753f813fe873cfa52853e9fef8eedb
- https://git.kernel.org/stable/c/44f69c96f8a147413c23c68cda4d6fb5e23137cd
- https://git.kernel.org/stable/c/53df4be4f5221e90dc7aa9ce745a9a21bb7024f4
- https://git.kernel.org/stable/c/8046beb890ebc83c5820188c650073e1c6066e67
- https://git.kernel.org/stable/c/87b655f4936b6fc01f3658aa88a22c923b379ebd
- https://git.kernel.org/stable/c/bd30aa9c7febb6e709670cd5154194189ca3b7b5
- https://git.kernel.org/stable/c/ed1cba039309c80b49719fcff3e3d7cdddb73d96
Modified: 2025-11-25
CVE-2023-53148
In the Linux kernel, the following vulnerability has been resolved: igb: Fix igb_down hung on surprise removal In a setup where a Thunderbolt hub connects to Ethernet and a display through USB Type-C, users may experience a hung task timeout when they remove the cable between the PC and the Thunderbolt hub. This is because the igb_down function is called multiple times when the Thunderbolt hub is unplugged. For example, the igb_io_error_detected triggers the first call, and the igb_remove triggers the second call. The second call to igb_down will block at napi_synchronize. Here's the call trace: __schedule+0x3b0/0xddb ? __mod_timer+0x164/0x5d3 schedule+0x44/0xa8 schedule_timeout+0xb2/0x2a4 ? run_local_timers+0x4e/0x4e msleep+0x31/0x38 igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] __dev_close_many+0x95/0xec dev_close_many+0x6e/0x103 unregister_netdevice_many+0x105/0x5b1 unregister_netdevice_queue+0xc2/0x10d unregister_netdev+0x1c/0x23 igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pci_device_remove+0x3f/0x9c device_release_driver_internal+0xfe/0x1b4 pci_stop_bus_device+0x5b/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_and_remove_bus_device+0x12/0x19 pciehp_unconfigure_device+0x76/0xe9 pciehp_disable_slot+0x6e/0x131 pciehp_handle_presence_or_link_change+0x7a/0x3f7 pciehp_ist+0xbe/0x194 irq_thread_fn+0x22/0x4d ? irq_thread+0x1fd/0x1fd irq_thread+0x17b/0x1fd ? irq_forced_thread_fn+0x5f/0x5f kthread+0x142/0x153 ? __irq_get_irqchip_state+0x46/0x46 ? kthread_associate_blkcg+0x71/0x71 ret_from_fork+0x1f/0x30 In this case, igb_io_error_detected detaches the network interface and requests a PCIE slot reset, however, the PCIE reset callback is not being invoked and thus the Ethernet connection breaks down. As the PCIE error in this case is a non-fatal one, requesting a slot reset can be avoided. This patch fixes the task hung issue and preserves Ethernet connection by ignoring non-fatal PCIE errors.
- https://git.kernel.org/stable/c/004d25060c78fc31f66da0fa439c544dda1ac9d5
- https://git.kernel.org/stable/c/124e39a734cb90658b8f0dc110847bbfc6e33792
- https://git.kernel.org/stable/c/39695e87d86f0e7d897fba1d2559f825aa20caeb
- https://git.kernel.org/stable/c/41f63b72a01c0e0ac59ab83fd2d921fcce0f602d
- https://git.kernel.org/stable/c/994c2ceb70ea99264ccc6f09e6703ca267dad63c
- https://git.kernel.org/stable/c/c2312e1d12b1c3ee4100c173131b102e2aed4d04
- https://git.kernel.org/stable/c/c9f56f3c7bc908caa772112d3ae71cdd5d18c257
- https://git.kernel.org/stable/c/fa92c463eba75dcedbd8d689ffdcb83293aaa0c3
Modified: 2025-11-25
CVE-2023-53150
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Pointer may be dereferenced Klocwork tool reported pointer 'rport' returned from call to function fc_bsg_to_rport() may be NULL and will be dereferenced. Add a fix to validate rport before dereferencing.
- https://git.kernel.org/stable/c/005961bd8f066fe931104f67c34ebfcc7f240099
- https://git.kernel.org/stable/c/00eca15319d9ce8c31cdf22f32a3467775423df4
- https://git.kernel.org/stable/c/0715da51391d223bf4981e28346770edea7eeb74
- https://git.kernel.org/stable/c/22b1d7c8bb59c3376430a8bad5840194b12bf29a
- https://git.kernel.org/stable/c/3f22f9ddbb29dba369daddb084be3bacf1587529
- https://git.kernel.org/stable/c/5addd62586a94a572359418464ce0ae12fa46187
- https://git.kernel.org/stable/c/a69125a3ce88d9a386872034e7664b30cc4bcbed
- https://git.kernel.org/stable/c/b06d1b525364bbcf4929b4b35d81945b10dc9883
Modified: 2025-11-24
CVE-2023-53152
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix calltrace warning in amddrm_buddy_fini
The following call trace is observed when removing the amdgpu driver, which
is caused by that BOs allocated for psp are not freed until removing.
[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]
[61811.450577] Call Trace:
[61811.450577]
Modified: 2025-11-24
CVE-2023-53153
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix use after free for wext Key information in wext.connect is not reset on (re)connect and can hold data from a previous connection. Reset key data to avoid that drivers or mac80211 incorrectly detect a WEP connection request and access the freed or already reused memory. Additionally optimize cfg80211_sme_connect() and avoid an useless schedule of conn_work.
- https://git.kernel.org/stable/c/015b8cc5e7c4d7bb671f1984d7b7338c310b185b
- https://git.kernel.org/stable/c/22dfb21bf1cd876616d45cda1bc6daa89eec6747
- https://git.kernel.org/stable/c/2cfe78619b0de6d2da773978bc2d22797212eaa7
- https://git.kernel.org/stable/c/66af4a2ab1d65d556d638cb9555a3b823c2557a9
- https://git.kernel.org/stable/c/6f1959c17d4cb5b74af6fc31dc787e1dc3e4f6e2
- https://git.kernel.org/stable/c/a2a92b3e9d8e03ee3f9ee407fc46a9b4bd02d8b6
- https://git.kernel.org/stable/c/f4b6a138efb8a32507b8946104e32cb926308da7
- https://git.kernel.org/stable/c/fd081afd21eb35b968b0330700c43ec94986e1c4
Modified: 2025-11-24
CVE-2023-53163
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: don't hold ni_lock when calling truncate_setsize() syzbot is reporting hung task at do_user_addr_fault() [1], for there is a silent deadlock between PG_locked bit and ni_lock lock. Since filemap_update_page() calls filemap_read_folio() after calling folio_trylock() which will set PG_locked bit, ntfs_truncate() must not call truncate_setsize() which will wait for PG_locked bit to be cleared when holding ni_lock lock.
Modified: 2025-11-24
CVE-2023-53164
In the Linux kernel, the following vulnerability has been resolved: irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_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/02298b7bae12936ca313975b02e7f98b06670d37
- https://git.kernel.org/stable/c/07fceab32096c1290b491f2fcaace03f78e2db37
- https://git.kernel.org/stable/c/4ae40c20f1519e1767ba01609abc7e8d6485fc0c
- https://git.kernel.org/stable/c/856fc2195494d1175ada0f1f46f92c5b28ce12eb
- https://git.kernel.org/stable/c/a0d91a48e1a020fb636f0fcaf44672f123bb0799
- https://git.kernel.org/stable/c/df8d3536b660c6c6f6b25fa8b157e9b38ad78142
Modified: 2025-11-24
CVE-2023-53165
In the Linux kernel, the following vulnerability has been resolved: udf: Fix uninitialized array access for some pathnames For filenames that begin with . and are between 2 and 5 characters long, UDF charset conversion code would read uninitialized memory in the output buffer. The only practical impact is that the name may be prepended a "unification hash" when it is not actually needed but still it is good to fix this.
- https://git.kernel.org/stable/c/008ae78d1e12efa904dc819b1ec83e2bca6b2c56
- https://git.kernel.org/stable/c/028f6055c912588e6f72722d89c30b401bbcf013
- https://git.kernel.org/stable/c/3f1368af47acf4d0b2a5fb0d2c0d6919d2234b6d
- https://git.kernel.org/stable/c/4503f6fc95d6dee85fb2c54785848799e192c51c
- https://git.kernel.org/stable/c/4d50988da0db167aed6f38685145cb5cd526c4f8
- https://git.kernel.org/stable/c/985f9666698960dfc87a106d6314203fa90fda75
- https://git.kernel.org/stable/c/a6824149809395dfbb5bc36bc7057cc3cb84e56d
- https://git.kernel.org/stable/c/b37f998d357102e8eb0f8eeb33f03fff22e49cbf
Modified: 2025-11-24
CVE-2023-53166
In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq25890: Fix external_power_changed race
bq25890_charger_external_power_changed() dereferences bq->charger,
which gets sets in bq25890_power_supply_init() like this:
bq->charger = devm_power_supply_register(bq->dev, &bq->desc, &psy_cfg);
As soon as devm_power_supply_register() has called device_add()
the external_power_changed callback can get called. So there is a window
where bq25890_charger_external_power_changed() may get called while
bq->charger has not been set yet leading to a NULL pointer dereference.
This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f
when the cht_wcove_pwrsrc (extcon) power_supply is done with detecting
the connected charger-type which happens to exactly hit the small window:
BUG: kernel NULL pointer dereference, address: 0000000000000018
Modified: 2025-11-24
CVE-2023-53167
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix null pointer dereference in tracing_err_log_open() Fix an issue in function 'tracing_err_log_open'. The function doesn't call 'seq_open' if the file is opened only with write permissions, which results in 'file->private_data' being left as null. If we then use 'lseek' on that opened file, 'seq_lseek' dereferences 'file->private_data' in 'mutex_lock(&m->lock)', resulting in a kernel panic. Writing to this node requires root privileges, therefore this bug has very little security impact. Tracefs node: /sys/kernel/tracing/error_log Example Kernel panic: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: mutex_lock+0x30/0x110 seq_lseek+0x34/0xb8 __arm64_sys_lseek+0x6c/0xb8 invoke_syscall+0x58/0x13c el0_svc_common+0xc4/0x10c do_el0_svc+0x24/0x98 el0_svc+0x24/0x88 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1b4/0x1b8 Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02) ---[ end trace 561d1b49c12cf8a5 ]--- Kernel panic - not syncing: Oops: Fatal exception
- https://git.kernel.org/stable/c/02b0095e2fbbc060560c1065f86a211d91e27b26
- https://git.kernel.org/stable/c/1e1c9aa9288a46c342f0f2c5c0b1c0876b9b0276
- https://git.kernel.org/stable/c/3b5d9b7b875968a8a8c99dac45cb85b705c44802
- https://git.kernel.org/stable/c/7060e5aac6dc195124c106f49106d653a416323a
- https://git.kernel.org/stable/c/93114cbc7cb169f6f26eeaed5286b91bb86b463b
- https://git.kernel.org/stable/c/938d5b7a75e18264887387ddf9169db6d8aeef98
Modified: 2025-11-24
CVE-2023-53168
In the Linux kernel, the following vulnerability has been resolved: usb: ucsi_acpi: Increase the command completion timeout Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command completion timeout value") increased the timeout from 5 seconds to 60 seconds due to issues related to alternate mode discovery. After the alternate mode discovery switch to polled mode the timeout was reduced, but instead of being set back to 5 seconds it was reduced to 1 second. This is causing problems when using a Lenovo ThinkPad X1 yoga gen7 connected over Type-C to a LG 27UL850-W (charging DP over Type-C). When the monitor is already connected at boot the following error is logged: "PPM init failed (-110)", /sys/class/typec is empty and on unplugging the NULL pointer deref fixed earlier in this series happens. When the monitor is connected after boot the following error is logged instead: "GET_CONNECTOR_STATUS failed (-110)". Setting the timeout back to 5 seconds fixes both cases.
Modified: 2025-12-02
CVE-2023-53169
In the Linux kernel, the following vulnerability has been resolved:
x86/resctrl: Clear staged_config[] before and after it is used
As a temporary storage, staged_config[] in rdt_domain should be cleared
before and after it is used. The stale value in staged_config[] could
cause an MSR access error.
Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3
Cache (MBA should be disabled if the number of CLOSIDs for MB is less than
16.) :
mount -t resctrl resctrl -o cdp /sys/fs/resctrl
mkdir /sys/fs/resctrl/p{1..7}
umount /sys/fs/resctrl/
mount -t resctrl resctrl /sys/fs/resctrl
mkdir /sys/fs/resctrl/p{1..8}
An error occurs when creating resource group named p8:
unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)
Call Trace:
Modified: 2025-12-02
CVE-2023-53171
In the Linux kernel, the following vulnerability has been resolved: vfio/type1: prevent underflow of locked_vm via exec() When a vfio container is preserved across exec, the task does not change, but it gets a new mm with locked_vm=0, and loses the count from existing dma mappings. If the user later unmaps a dma mapping, locked_vm underflows to a large unsigned value, and a subsequent dma map request fails with ENOMEM in __account_locked_vm. To avoid underflow, grab and save the mm at the time a dma is mapped. Use that mm when adjusting locked_vm, rather than re-acquiring the saved task's mm, which may have changed. If the saved mm is dead, do nothing. locked_vm is incremented for existing mappings in a subsequent patch.
- https://git.kernel.org/stable/c/046eca5018f8a5dd1dc2cedf87fb5843b9ea3026
- https://git.kernel.org/stable/c/5a271242716846cc016736fb76be2b40ee49b0c3
- https://git.kernel.org/stable/c/a6b2aabe664098d5cf877ae0fd96459464a30e17
- https://git.kernel.org/stable/c/b0790dff0760b7734cf0961f497ad64628ca550b
- https://git.kernel.org/stable/c/eafb81c50da899dd80b340c841277acc4a1945b7
Modified: 2025-12-02
CVE-2023-53173
In the Linux kernel, the following vulnerability has been resolved: tty: pcn_uart: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2025-12-02
CVE-2023-53174
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix possible memory leak if device_add() fails If device_add() returns error, the name allocated by dev_set_name() needs be freed. As the comment of device_add() says, put_device() should be used to decrease the reference count in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanp().
- https://git.kernel.org/stable/c/04b5b5cb0136ce970333a9c6cec7e46adba1ea3a
- https://git.kernel.org/stable/c/06c5340858011aa1195aec43a776e3185fbf7f56
- https://git.kernel.org/stable/c/43c0e16d0c5ec59398b405f4c4aa5a076e656c3f
- https://git.kernel.org/stable/c/63956ad27a6882f01fea7c69e17823090f4c7b3f
- https://git.kernel.org/stable/c/6bc7f4c8c27d526f968788b8a985896755b1df35
- https://git.kernel.org/stable/c/aa9a76d5ffdecd3b52ac333eb89361b0c9fe04e8
- https://git.kernel.org/stable/c/b191ff1f075c4875f11271cbf0093e6e044a12aa
- https://git.kernel.org/stable/c/e12fac07f61caac9c5b186d827658b3470787619
Modified: 2025-12-02
CVE-2023-53175
In the Linux kernel, the following vulnerability has been resolved: PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the device yet), doing a VM hibernation triggers a panic in hv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), because pdev->dev.msi.data is still NULL. Avoid the panic by checking if MSI-X/MSI is enabled.
Modified: 2025-12-02
CVE-2023-53176
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Reinit port->pm on port specific driver unbind When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs: Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone: serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c Let's fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm.
- https://git.kernel.org/stable/c/04e82793f068d2f0ffe62fcea03d007a8cdc16a7
- https://git.kernel.org/stable/c/1ba5594739d858e524ff0f398ee1ebfe0a8b9d41
- https://git.kernel.org/stable/c/2c86a1305c1406f45ea780d06953c484ea1d9e6e
- https://git.kernel.org/stable/c/490bf37eaabb0a857ed1ae8e75d8854e41662f1c
- https://git.kernel.org/stable/c/8e596aed5f2f98cf3e6e98d6fe1d689f4a319308
- https://git.kernel.org/stable/c/af4d6dbb1a92ea424ad1ba1d0c88c7fa2345d872
- https://git.kernel.org/stable/c/c9e080c3005fd183c56ff8f4d75edb5da0765d2c
- https://git.kernel.org/stable/c/d5cd2928d31042a7c0a01464f9a8d95be736421d
Modified: 2025-12-02
CVE-2023-53177
In the Linux kernel, the following vulnerability has been resolved: media: hi846: fix usage of pm_runtime_get_if_in_use() pm_runtime_get_if_in_use() does not only return nonzero values when the device is in use, it can return a negative errno too. And especially during resuming from system suspend, when runtime pm is not yet up again, -EAGAIN is being returned, so the subsequent pm_runtime_put() call results in a refcount underflow. Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().
Modified: 2025-12-02
CVE-2023-53178
In the Linux kernel, the following vulnerability has been resolved: mm: fix zswap writeback race condition The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page. The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B The fix: Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW), zswap-shrink work just checks that the local zswap_entry reference is still the same as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data. Reproducer: I originally found this by running `stress` overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do the trick. In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running `stress --vm 1 --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set `--vm-stride` to something other than 4096 otherwise `stress` won't realize that memory has been corrupted because all pages would have the same data.
Modified: 2025-12-02
CVE-2023-53179
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access. This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue.
- https://git.kernel.org/stable/c/050d91c03b28ca479df13dfb02bcd2c60dd6a878
- https://git.kernel.org/stable/c/109e830585e89a03d554bf8ad0e668630d0a6260
- https://git.kernel.org/stable/c/7935b636dd693dfe4483cfef4a1e91366c8103fa
- https://git.kernel.org/stable/c/7ca0706c68adadf86a36b60dca090f5e9481e808
- https://git.kernel.org/stable/c/83091f8ac03f118086596f17c9a52d31d6ca94b3
- https://git.kernel.org/stable/c/a9e6142e5f8f6ac7d1bca45c1b2b13b084ea9e14
- https://git.kernel.org/stable/c/d59b6fc405549f7caf31f6aa5da1d6bef746b166
- https://git.kernel.org/stable/c/d95c8420efe684b964e3aa28108e9a354bcd7225
- https://git.kernel.org/stable/c/e632d09dffc68b9602d6893a99bfe3001d36cefc
Modified: 2025-12-02
CVE-2023-53181
In the Linux kernel, the following vulnerability has been resolved: dma-buf/dma-resv: Stop leaking on krealloc() failure Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure.
Modified: 2025-12-02
CVE-2023-53182
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Avoid undefined behavior: applying zero offset to null pointer
ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e
Before this change we see the following UBSAN stack trace in Fuchsia:
#0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682
- https://git.kernel.org/stable/c/05bb0167c80b8f93c6a4e0451b7da9b96db990c2
- https://git.kernel.org/stable/c/16359bc02c093b0862e31739c07673340a2106a6
- https://git.kernel.org/stable/c/3048c6b84a51e4ba4a89385ed218d19a670edd47
- https://git.kernel.org/stable/c/35465c7a91c6b46e7c14d0c01d0084349a38ce51
- https://git.kernel.org/stable/c/3a7a4aa3958ce0c4938a443d65001debe9a9af9c
- https://git.kernel.org/stable/c/5a2d0dcb47b16f84880a59571eab8a004e3236d7
- https://git.kernel.org/stable/c/710e09fd116e2fa53e319a416ad4e4f8027682b6
- https://git.kernel.org/stable/c/8c4a7163b7f1495e3cc58bec7a4100de6612cde9
Modified: 2025-12-02
CVE-2023-53185
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes A bad USB device is able to construct a service connection response message with target endpoint being ENDPOINT0 which is reserved for HTC_CTRL_RSVD_SVC and should not be modified to be used for any other services. Reject such service connection responses. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/061b0cb9327b80d7a0f63a33e7c3e2a91a71f142
- https://git.kernel.org/stable/c/09740fa9827cfbaf23ecd041e602a426f99be888
- https://git.kernel.org/stable/c/1044187e7249073f719ebbf9e5ffb4f16f99e555
- https://git.kernel.org/stable/c/4dc3560561a08842b4a4c07ccc5a90e5067dbb5b
- https://git.kernel.org/stable/c/6a444dffb75238c47d2d852f12cf53f12ad2cba8
- https://git.kernel.org/stable/c/95b4b940f0fb2873dcedad81699e869eb7581c85
- https://git.kernel.org/stable/c/9e3031eea2d45918dc44cbfc6a6029e82882916f
- https://git.kernel.org/stable/c/be2a546c30fe8d72efa032bee612363bb75314bd
- https://git.kernel.org/stable/c/db8df00cd6d801b3abdb145201c2bdd1c665f585
Modified: 2025-12-02
CVE-2023-53186
In the Linux kernel, the following vulnerability has been resolved:
skbuff: Fix a race between coalescing and releasing SKBs
Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment
recycling") allowed coalescing to proceed with non page pool page and page
pool page when @from is cloned, i.e.
to->pp_recycle --> false
from->pp_recycle --> true
skb_cloned(from) --> true
However, it actually requires skb_cloned(@from) to hold true until
coalescing finishes in this situation. If the other cloned SKB is
released while the merging is in process, from_shinfo->nr_frags will be
set to 0 toward the end of the function, causing the increment of frag
page _refcount to be unexpectedly skipped resulting in inconsistent
reference counts. Later when SKB(@to) is released, it frees the page
directly even though the page pool page is still in use, leading to
use-after-free or double-free errors. So it should be prohibited.
The double-free error message below prompted us to investigate:
BUG: Bad page state in process swapper/1 pfn:0e0d1
page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000
index:0x2 pfn:0xe0d1
flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000
raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000
page dumped because: nonzero _refcount
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+
Call Trace:
Modified: 2025-12-02
CVE-2023-53188
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix race on port output assume the following setup on a single machine: 1. An openvswitch instance with one bridge and default flows 2. two network namespaces "server" and "client" 3. two ovs interfaces "server" and "client" on the bridge 4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues 5. move the ends of the veth pairs to the respective network namespaces 6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet) 7. start some http server on the server network namespace 8. test if a client in the client namespace can reach the http server when following the actions below the host has a chance of getting a cpu stuck in a infinite loop: 1. send a large amount of parallel requests to the http server (around 3000 curls should work) 2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace) there is a low chance that this will cause the below kernel cpu stuck message. If this does not happen just retry. Below there is also the output of bpftrace for the functions mentioned in the output. The series of events happening here is: 1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process 2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net` 3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER` 4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs) 5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device 6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path 7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0 8. port deletion continues (but details are not relevant for this issue) 9. at some future point the background task deletes the vport If after 7. but before 9. a packet is send to the ovs vport (which is not deleted at this point in time) which forwards it to the `dev_queue_xmit` flow even though the device is unregistering. In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is a while loop (if the packet has a rx_queue recorded) that is infinite if `dev->real_num_tx_queues` is zero. To prevent this from happening we update `do_output` to handle devices without carrier the same as if the device is not found (which would be the code path after 9. is done). Additionally we now produce a warning in `skb_tx_hash` if we will hit the infinite loop. bpftrace (first word is function name): __dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2 ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2 netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 dp_ ---truncated---
- https://git.kernel.org/stable/c/066b86787fa3d97b7aefb5ac0a99a22dad2d15f8
- https://git.kernel.org/stable/c/284be5db6c8d06d247ed056cfc448c4f79bbb16c
- https://git.kernel.org/stable/c/56252da41426f3d01957456f13caf46ce670ea29
- https://git.kernel.org/stable/c/5efcb301523baacd98a47553d4996e924923114d
- https://git.kernel.org/stable/c/644b3051b06ba465bc7401bfae9b14963cbc8c1c
- https://git.kernel.org/stable/c/9b0dd09c1ceb35950d2884848099fccc9ec9a123
Modified: 2025-12-02
CVE-2023-53189
In the Linux kernel, the following vulnerability has been resolved: ipv6/addrconf: fix a potential refcount underflow for idev Now in addrconf_mod_rs_timer(), reference idev depends on whether rs_timer is not pending. Then modify rs_timer timeout. There is a time gap in [1], during which if the pending rs_timer becomes not pending. It will miss to hold idev, but the rs_timer is activated. Thus rs_timer callback function addrconf_rs_timer() will be executed and put idev later without holding idev. A refcount underflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when); To fix the issue, hold idev if mod_timer() return 0.
- https://git.kernel.org/stable/c/06a0716949c22e2aefb648526580671197151acc
- https://git.kernel.org/stable/c/1f656e483eb4733d62f18dfb206a49b78f60f495
- https://git.kernel.org/stable/c/2ad31ce40e8182860b631e37209e93e543790b7c
- https://git.kernel.org/stable/c/436b7cc7eae7851c184b671ed7a4a64c750b86f7
- https://git.kernel.org/stable/c/82abd1c37d3bf2a2658b34772c17a25a6f9cca42
- https://git.kernel.org/stable/c/c6395e32935d35e6f935e7caf1c2dac5a95943b4
- https://git.kernel.org/stable/c/c7eeba47058532f6077d6a658e38b6698f6ae71a
- https://git.kernel.org/stable/c/df62fdcd004afa72ecbed0e862ebb983acd3aa57
Modified: 2025-12-02
CVE-2023-53190
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix memory leaks in error path
The memory allocated by vxlan_vnigroup_init() is not freed in the error
path, leading to memory leaks [1]. Fix by calling
vxlan_vnigroup_uninit() in the error path.
The leaks can be reproduced by annotating gro_cells_init() with
ALLOW_ERROR_INJECTION() and then running:
# echo "100" > /sys/kernel/debug/fail_function/probability
# echo "1" > /sys/kernel/debug/fail_function/times
# echo "gro_cells_init" > /sys/kernel/debug/fail_function/inject
# printf %#x -12 > /sys/kernel/debug/fail_function/gro_cells_init/retval
# ip link add name vxlan0 type vxlan dstport 4789 external vnifilter
RTNETLINK answers: Cannot allocate memory
[1]
unreferenced object 0xffff88810db84a00 (size 512):
comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
hex dump (first 32 bytes):
f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v.............
03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H...........
backtrace:
[
Modified: 2025-12-02
CVE-2023-53191
In the Linux kernel, the following vulnerability has been resolved: irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains 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/071d068b89e95d1b078aa6bbcb9d0961b77d6aa1
- https://git.kernel.org/stable/c/5fbf2cc39b62a4afe44f3d42ee3dcf8f012c1926
- https://git.kernel.org/stable/c/65e30bd1310d90b794c377bf405394157854aa30
- https://git.kernel.org/stable/c/9e79ac4f70fd51243e1c6108d4b0baf16cfde99c
- https://git.kernel.org/stable/c/c9aaf4efe1f02b2fef21a69fb3652f5ad12a5710
- https://git.kernel.org/stable/c/d6c66c46889752fa4962c6388516f7ab66a8d6a1
- https://git.kernel.org/stable/c/eef04516f0c317ce80502c1d6b0d06235a87cd8f
- https://git.kernel.org/stable/c/eef09f786df4b34b97557929287c4e5a83bbf09b
Modified: 2025-12-02
CVE-2023-53192
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix nexthop hash size
The nexthop code expects a 31 bit hash, such as what is returned by
fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash
returned by skb_get_hash() can lead to problems related to the fact that
'int hash' is a negative number when the MSB is set.
In the case of hash threshold nexthop groups, nexthop_select_path_hthr()
will disproportionately select the first nexthop group entry. In the case
of resilient nexthop groups, nexthop_select_path_res() may do an out of
bounds access in nh_buckets[], for example:
hash = -912054133
num_nh_buckets = 2
bucket_index = 65535
which leads to the following panic:
BUG: unable to handle page fault for address: ffffc900025910c8
PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:nexthop_select_path+0x197/0xbf0
Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85
RSP: 0018:ffff88810c36f260 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8
RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219
R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0
R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900
FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/0756384fb1bd38adb2ebcfd1307422f433a1d772
- https://git.kernel.org/stable/c/23c195ce6f4aec86e1c9e1ea1c800381c4b465c7
- https://git.kernel.org/stable/c/32ef2c0c6cf11a076f0280a7866b9abc47821e19
- https://git.kernel.org/stable/c/7b8717658dff8b471cbfc124bf9b5ca4229579ed
- https://git.kernel.org/stable/c/c650597647ecb318d02372277bdfd866c6829f78
Modified: 2025-12-02
CVE-2023-53195
In the Linux kernel, the following vulnerability has been resolved: mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init The line cards array is not freed in the error path of mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by freeing the array in the error path, thereby making the error path identical to mlxsw_m_linecards_fini().
Modified: 2025-12-02
CVE-2023-53196
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: qcom: Fix potential memory leak Function dwc3_qcom_probe() allocates memory for resource structure which is pointed by parent_res pointer. This memory is not freed. This leads to memory leak. Use stack memory to prevent memory leak. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/097fb3ee710d4de83b8d4f5589e8ee13e0f0541e
- https://git.kernel.org/stable/c/134a7d4642f11daed6bbc378f930a54dd0322291
- https://git.kernel.org/stable/c/648a163cff21ea355c8765e882ba8bf66a870a3e
- https://git.kernel.org/stable/c/74f8606ddfa450d2255b4e61472a7632def1e8c4
- https://git.kernel.org/stable/c/b626cd5e4a87a281629e0c2b07519990077c0fbe
- https://git.kernel.org/stable/c/c3b322b84ab5dda7eaca9ded763628b7467734f4
Modified: 2025-12-02
CVE-2023-53197
In the Linux kernel, the following vulnerability has been resolved: USB: uhci: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2025-12-02
CVE-2023-53198
In the Linux kernel, the following vulnerability has been resolved:
raw: Fix NULL deref in raw_get_next().
Dae R. Jeong reported a NULL deref in raw_get_next() [0].
It seems that the repro was running these sequences in parallel so
that one thread was iterating on a socket that was being freed in
another netns.
unshare(0x40060200)
r0 = syz_open_procfs(0x0, &(0x7f0000002080)='net/raw\x00')
socket$inet_icmp_raw(0x2, 0x3, 0x1)
pread64(r0, &(0x7f0000000000)=""/10, 0xa, 0x10000000007f)
After commit 0daf07e52709 ("raw: convert raw sockets to RCU"), we
use RCU and hlist_nulls_for_each_entry() to iterate over SOCK_RAW
sockets. However, we should use spinlock for slow paths to avoid
the NULL deref.
Also, SOCK_RAW does not use SLAB_TYPESAFE_BY_RCU, and the slab object
is not reused during iteration in the grace period. In fact, the
lockless readers do not check the nulls marker with get_nulls_value().
So, SOCK_RAW should use hlist instead of hlist_nulls.
Instead of adding an unnecessary barrier by sk_nulls_for_each_rcu(),
let's convert hlist_nulls to hlist and use sk_for_each_rcu() for
fast paths and sk_for_each() and spinlock for /proc/net/raw.
[0]:
general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
CPU: 2 PID: 20952 Comm: syz-executor.0 Not tainted 6.2.0-g048ec869bafd-dirty #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_pnet include/net/net_namespace.h:383 [inline]
RIP: 0010:sock_net include/net/sock.h:649 [inline]
RIP: 0010:raw_get_next net/ipv4/raw.c:974 [inline]
RIP: 0010:raw_get_idx net/ipv4/raw.c:986 [inline]
RIP: 0010:raw_seq_start+0x431/0x800 net/ipv4/raw.c:995
Code: ef e8 33 3d 94 f7 49 8b 6d 00 4c 89 ef e8 b7 65 5f f7 49 89 ed 49 83 c5 98 0f 84 9a 00 00 00 48 83 c5 c8 48 89 e8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 ef e8 00 3d 94 f7 4c 8b 7d 00 48 89 ef
RSP: 0018:ffffc9001154f9b0 EFLAGS: 00010206
RAX: 0000000000000005 RBX: 1ffff1100302c8fd RCX: 0000000000000000
RDX: 0000000000000028 RSI: ffffc9001154f988 RDI: ffffc9000f77a338
RBP: 0000000000000029 R08: ffffffff8a50ffb4 R09: fffffbfff24b6bd9
R10: fffffbfff24b6bd9 R11: 0000000000000000 R12: ffff88801db73b78
R13: fffffffffffffff9 R14: dffffc0000000000 R15: 0000000000000030
FS: 00007f843ae8e700(0000) GS:ffff888063700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055bb9614b35f CR3: 000000003c672000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-12-03
CVE-2023-53199
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails Syzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream(). While processing skbs in ath9k_hif_usb_rx_stream(), the already allocated skbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we have an incorrect pkt_len or pkt_tag, the input skb is considered invalid and dropped. All the associated packets already in skb_pool should be dropped and freed. Added a comment describing this issue. The patch also makes remain_skb NULL after being processed so that it cannot be referenced after potential free. The initialization of hif_dev fields which are associated with remain_skb (rx_remain_len, rx_transfer_len and rx_pad_len) is moved after a new remain_skb is allocated. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/0af54343a76263a12dbae7fafb64eb47c4a6ad38
- https://git.kernel.org/stable/c/3fc6401fafde11712a83089fa2cc874cfd10e2cd
- https://git.kernel.org/stable/c/61490d2710277e8a55009b7682456ae22f8087cf
- https://git.kernel.org/stable/c/9acdec72787af1bc8ed92711b52118c8e3e638a2
- https://git.kernel.org/stable/c/c766e37fccd5a5c5059be7efcd9618bf8a2c17c3
- https://git.kernel.org/stable/c/cd8316767099920a5d41feed1afab0c482a43e9f
- https://git.kernel.org/stable/c/f26dd69f61eff2eedf5df2d199bdd23108309947
Modified: 2025-12-04
CVE-2023-53200
In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu counter block leak on error path when creating new netns Here is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter block on xt_register_table fail. Note: xt_percpu_counter_free should be called to free it like we do in do_replace through cleanup_entry helper (or in __ip6t_unregister_table). Probability of hitting this error path is low AFAICS (xt_register_table can only return ENOMEM here, as it is not replacing anything, as we are creating new netns, and it is hard to imagine that all previous allocations succeeded and after that one in xt_register_table failed). But it's worth fixing even the rare leak.
Modified: 2025-12-04
CVE-2023-53201
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: wraparound mbox producer index Driver is not handling the wraparound of the mbox producer index correctly. Currently the wraparound happens once u32 max is reached. Bit 31 of the producer index register is special and should be set only once for the first command. Because the producer index overflow setting bit31 after a long time, FW goes to initialization sequence and this causes FW hang. Fix is to wraparound the mbox producer index once it reaches u16 max.
- https://git.kernel.org/stable/c/0af91306e17ef3d18e5f100aa58aa787869118af
- https://git.kernel.org/stable/c/50d77c3739b2b15e9e1f1c9cbe50037d294800f8
- https://git.kernel.org/stable/c/79226176cdd1b65a1e6a90e0e1a2b490f0a9df33
- https://git.kernel.org/stable/c/7bfa0303fbc265c94cfbd17505c55b99848aa4e3
- https://git.kernel.org/stable/c/9341501e2f7af29f5b5562c2840a7fde40eb7de4
- https://git.kernel.org/stable/c/c9be352be9bb15e6b83e40abc4df7f4776b435ba
Modified: 2025-12-03
CVE-2023-53202
In the Linux kernel, the following vulnerability has been resolved: PM: domains: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2025-12-04
CVE-2023-53204
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data-races around user->unix_inflight. user->unix_inflight is changed under spin_lock(unix_gc_lock), but too_many_unix_fds() reads it locklessly. Let's annotate the write/read accesses to user->unix_inflight. BUG: KCSAN: data-race in unix_attach_fds / unix_inflight write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0: too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 value changed: 0x000000000000000c -> 0x000000000000000d Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
- https://git.kernel.org/stable/c/03d133dfbcec9d439729cc64706c7eb6d1663a24
- https://git.kernel.org/stable/c/0bc36c0650b21df36fbec8136add83936eaf0607
- https://git.kernel.org/stable/c/9151ed4b006125cba7c06c79df504340ea4e9386
- https://git.kernel.org/stable/c/ac92f239a079678a035c0faad9089354a874aede
- https://git.kernel.org/stable/c/adcf4e069358cdee8593663650ea447215a1c49e
- https://git.kernel.org/stable/c/b401d7e485b0a234cf8fe9a6ae99dbcd20863138
- https://git.kernel.org/stable/c/b9cdbb38e030fc2fe97fe27b54cbb6b4fbff250f
- https://git.kernel.org/stable/c/df97b5ea9f3ac9308c3a633524dab382cd59d9e5
Modified: 2025-12-04
CVE-2023-53205
In the Linux kernel, the following vulnerability has been resolved: KVM: s390/diag: fix racy access of physical cpu number in diag 9c handler We do check for target CPU == -1, but this might change at the time we are going to use it. Hold the physical target CPU in a local variable to avoid out-of-bound accesses to the cpu arrays.
Modified: 2026-01-14
CVE-2023-53207
In the Linux kernel, the following vulnerability has been resolved: ublk: fail to recover device if queue setup is interrupted In ublk_ctrl_end_recovery(), if wait_for_completion_interruptible() is interrupted by signal, queues aren't setup successfully yet, so we have to fail UBLK_CMD_END_USER_RECOVERY, otherwise kernel oops can be triggered.
Modified: 2026-01-14
CVE-2023-53208
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired ratio doesn't match the current ratio, not if the ratio L1 is using for L2 diverges from the default. Functionally, the end result is the same as KVM will run L2 with L1's multiplier if L2's multiplier is the default, i.e. checking that L1's multiplier is loaded is equivalent to checking if L2 has a non-default multiplier. However, the assertion that TSC scaling is exposed to L1 is flawed, as userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking KVM's state_test selftest to do vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR); after restoring state in a new VM+vCPU yields an endless supply of: ------------[ cut here ]------------ WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105 nested_svm_vmexit+0x6af/0x720 [kvm_amd] Call Trace: nested_svm_exit_handled+0x102/0x1f0 [kvm_amd] svm_handle_exit+0xb9/0x180 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] ? trace_hardirqs_off+0x4d/0xa0 __se_sys_ioctl+0x7a/0xc0 __x64_sys_ioctl+0x21/0x30 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Unlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check into the if-statement is wrong as KVM needs to ensure L1's multiplier is loaded in the above scenario. Alternatively, the WARN_ON() could simply be deleted, but that would make KVM's behavior even more subtle, e.g. it's not immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when checking only tsc_ratio_msr.
Modified: 2026-01-14
CVE-2023-53209
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: Fix possible NULL dereference In a call to mac80211_hwsim_select_tx_link() the sta pointer might be NULL, thus need to check that it is not NULL before accessing it.
Modified: 2026-01-14
CVE-2023-53210
In the Linux kernel, the following vulnerability has been resolved: md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is empty, and then submit 'flush_bio', however, r5l_log_flush_endio() is clearing the list first and then clear the bio, which will cause null-ptr-deref: T1: submit flush io raid5d handle_active_stripes r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init submit_bio // io1 T2: io1 is done r5l_log_flush_endio list_splice_tail_init // clear the list T3: submit new flush io ... r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init bio_uninit // clear bio->bi_blkg submit_bio // null-ptr-deref Fix this problem by clearing bio before clearing the list in r5l_log_flush_endio().
Modified: 2026-01-14
CVE-2023-53211
In the Linux kernel, the following vulnerability has been resolved: driver core: location: Free struct acpi_pld_info *pld before return false struct acpi_pld_info *pld should be freed before the return of allocation failure, to prevent memory leak, add the ACPI_FREE() to fix it.
Modified: 2026-01-14
CVE-2023-53213
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() Fix a slab-out-of-bounds read that occurs in kmemdup() called from brcmf_get_assoc_ies(). The bug could occur when assoc_info->req_len, data from a URB provided by a USB device, is bigger than the size of buffer which is defined as WL_EXTRA_BUF_MAX. Add the size check for req_len/resp_len of assoc_info. Found by a modified version of syzkaller. [ 46.592467][ T7] ================================================================== [ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50 [ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7 [ 46.598575][ T7] [ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145 [ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker [ 46.605943][ T7] Call Trace: [ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1 [ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334 [ 46.608610][ T7] ? kmemdup+0x3e/0x50 [ 46.609341][ T7] kasan_report.cold+0x79/0xd5 [ 46.610151][ T7] ? kmemdup+0x3e/0x50 [ 46.610796][ T7] kasan_check_range+0x14e/0x1b0 [ 46.611691][ T7] memcpy+0x20/0x60 [ 46.612323][ T7] kmemdup+0x3e/0x50 [ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60 [ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0 [ 46.614831][ T7] ? lock_chain_count+0x20/0x20 [ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770 [ 46.616552][ T7] ? lock_chain_count+0x20/0x20 [ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770 [ 46.618244][ T7] ? lock_chain_count+0x20/0x20 [ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0 [ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0 [ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790 [ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950 [ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 [ 46.623390][ T7] ? find_held_lock+0x2d/0x110 [ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60 [ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0 [ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0 [ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 [ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100 [ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60 [ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100 [ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 46.630649][ T7] process_one_work+0x92b/0x1460 [ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330 [ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90 [ 46.632347][ T7] worker_thread+0x95/0xe00 [ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0 [ 46.633393][ T7] ? process_one_work+0x1460/0x1460 [ 46.633957][ T7] kthread+0x3a1/0x480 [ 46.634369][ T7] ? set_kthread_struct+0x120/0x120 [ 46.634933][ T7] ret_from_fork+0x1f/0x30 [ 46.635431][ T7] [ 46.635687][ T7] Allocated by task 7: [ 46.636151][ T7] kasan_save_stack+0x1b/0x40 [ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90 [ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330 [ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040 [ 46.638275][ T7] brcmf_attach+0x389/0xd40 [ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690 [ 46.639279][ T7] usb_probe_interface+0x2aa/0x760 [ 46.639820][ T7] really_probe+0x205/0xb70 [ 46.640342][ T7] __driver_probe_device+0 ---truncated---
- https://git.kernel.org/stable/c/0da40e018fd034d87c9460123fa7f897b69fdee7
- https://git.kernel.org/stable/c/21bee3e649d87f78fe8aef6ae02edd3d6f310fd0
- https://git.kernel.org/stable/c/228186629ea970cc78b7d7d5f593f2d32fddf9f6
- https://git.kernel.org/stable/c/39f9bd880abac6068bedb24a4e16e7bd26bf92da
- https://git.kernel.org/stable/c/425eea395f1f5ae349fb55f7fe51d833a5324bfe
- https://git.kernel.org/stable/c/549825602e3e6449927ca1ea1a08fd89868439df
- https://git.kernel.org/stable/c/936a23293bbb3332bdf4cdb9c1496e80cb0bc2c8
- https://git.kernel.org/stable/c/ac5305e5d227b9af3aae25fa83380d3ff0225b73
- https://git.kernel.org/stable/c/e29661611e6e71027159a3140e818ef3b99f32dd
Modified: 2026-01-14
CVE-2023-53214
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential memory corruption in __update_iostat_latency() Add iotype sanity check to avoid potential memory corruption. This is to fix the compile error below: fs/f2fs/iostat.c:231 __update_iostat_latency() error: buffer overflow 'io_lat->peak_lat[type]' 3 <= 3 vim +228 fs/f2fs/iostat.c 211 static inline void __update_iostat_latency(struct bio_iostat_ctx *iostat_ctx, 212 enum iostat_lat_type type) 213 { 214 unsigned long ts_diff; 215 unsigned int page_type = iostat_ctx->type; 216 struct f2fs_sb_info *sbi = iostat_ctx->sbi; 217 struct iostat_lat_info *io_lat = sbi->iostat_io_lat; 218 unsigned long flags; 219 220 if (!sbi->iostat_enable) 221 return; 222 223 ts_diff = jiffies - iostat_ctx->submit_ts; 224 if (page_type >= META_FLUSH) ^^^^^^^^^^ 225 page_type = META; 226 227 spin_lock_irqsave(&sbi->iostat_lat_lock, flags); @228 io_lat->sum_lat[type][page_type] += ts_diff; ^^^^^^^^^ Mixup between META_FLUSH and NR_PAGE_TYPE leads to memory corruption.
Modified: 2026-01-14
CVE-2023-53215
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Don't balance task to its current running CPU We've run into the case that the balancer tries to balance a migration disabled task and trigger the warning in set_task_cpu() like below: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : set_task_cpu+0x188/0x240 lr : load_balance+0x5d0/0xc60 sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace: set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380 _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x6c/0x80 __do_softirq+0x128/0x3d8 ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0 cpu_startup_entry+0x30/0x3c secondary_start_kernel+0x14c/0x190 __secondary_switched+0xb0/0xb4 ---[ end trace 0000000000000000 ]--- Further investigation shows that the warning is superfluous, the migration disabled task is just going to be migrated to its current running CPU. This is because that on load balance if the dst_cpu is not allowed by the task, we'll re-select a new_dst_cpu as a candidate. If no task can be balanced to dst_cpu we'll try to balance the task to the new_dst_cpu instead. In this case when the migration disabled task is not on CPU it only allows to run on its current CPU, load balance will select its current CPU as new_dst_cpu and later triggers the warning above. The new_dst_cpu is chosen from the env->dst_grpmask. Currently it contains CPUs in sched_group_span() and if we have overlapped groups it's possible to run into this case. This patch makes env->dst_grpmask of group_balance_mask() which exclude any CPUs from the busiest group and solve the issue. For balancing in a domain with no overlapped groups the behaviour keeps same as before.
- https://git.kernel.org/stable/c/0dd37d6dd33a9c23351e6115ae8cdac7863bc7de
- https://git.kernel.org/stable/c/32d937f94b7805d4c9028b8727a7d6241547da54
- https://git.kernel.org/stable/c/34eb902050d473bb2befa15714fb1d30a0991c15
- https://git.kernel.org/stable/c/3cb43222bab8ab328fc91ed30899b3df2efbccfd
- https://git.kernel.org/stable/c/6b0c79aa33075b34c3cdcea4132c0afb3fc42d68
- https://git.kernel.org/stable/c/78a5f711efceb37e32c48cd6b40addb671fea9cc
- https://git.kernel.org/stable/c/a5286f4655ce2fa28f477c0b957ea7f323fe2fab
- https://git.kernel.org/stable/c/cec1857b1ea5cc3ea2b600564f1c95d1a6f27ad1
Modified: 2026-01-14
CVE-2023-53217
In the Linux kernel, the following vulnerability has been resolved: nubus: Partially revert proc_create_single_data() conversion The conversion to proc_create_single_data() introduced a regression whereby reading a file in /proc/bus/nubus results in a seg fault: # grep -r . /proc/bus/nubus/e/ Data read fault at 0x00000020 in Super Data (pc=0x1074c2) BAD KERNEL BUSERR Oops: 00000000 Modules linked in: PC: [<001074c2>] PDE_DATA+0xc/0x16 SR: 2010 SP: 38284958 a2: 01152370 d0: 00000001 d1: 01013000 d2: 01002790 d3: 00000000 d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40 Process grep (pid: 45, task=142f8727) Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70 baddr=001074c8 dibuf=ffffffff ver=f Stack from 01199e48: 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000 d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0 Call Trace: [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0 [<000d551a>] seq_read+0xc4/0x510 [<00018000>] fp_fcos+0x2/0x82 [<0002800d>] __sys_setreuid+0x115/0x1c6 [<00103640>] proc_reg_read+0x5c/0xb0 [<00018000>] fp_fcos+0x2/0x82 [<000b3344>] __vfs_read+0x2c/0x13c [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b8aa2>] sys_statx+0x60/0x7e [<000b34b6>] vfs_read+0x62/0x12a [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b39c2>] ksys_read+0x48/0xbe [<00018000>] fp_fcos+0x2/0x82 [<000b3a4e>] sys_read+0x16/0x1a [<00018000>] fp_fcos+0x2/0x82 [<00002b84>] syscall+0x8/0xc [<00018000>] fp_fcos+0x2/0x82 [<0000c016>] not_ext+0xa/0x18 Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8 Disabling lock debugging due to kernel taint Segmentation fault The proc_create_single_data() conversion does not work because single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is not equivalent to the original code.
- https://git.kernel.org/stable/c/0e96647cff9224db564a1cee6efccb13dbe11ee2
- https://git.kernel.org/stable/c/67e3b5230cefed1eca470c460a2035f02986cebb
- https://git.kernel.org/stable/c/9877533e1401dbbb2c7da8badda05d196aa07623
- https://git.kernel.org/stable/c/a03f2f4bd49030f57849227be9ba38a3eb1edb61
- https://git.kernel.org/stable/c/c06edf13f4cf7f9e8ff4bc6f7e951e4f074dc105
- https://git.kernel.org/stable/c/f70407e8e0272e00d133c5e039168ff1bae6bcac
Modified: 2026-01-14
CVE-2023-53219
In the Linux kernel, the following vulnerability has been resolved: media: netup_unidvb: fix use-after-free at del_timer() When Universal DVB card is detaching, netup_unidvb_dma_fini() uses del_timer() to stop dma->timeout timer. But when timer handler netup_unidvb_dma_timeout() is running, del_timer() could not stop it. As a result, the use-after-free bug could happen. The process is shown below: (cleanup routine) | (timer routine) | mod_timer(&dev->tx_sim_timer, ..) netup_unidvb_finidev() | (wait a time) netup_unidvb_dma_fini() | netup_unidvb_dma_timeout() del_timer(&dma->timeout); | | ndev->pci_dev->dev //USE Fix by changing del_timer() to del_timer_sync().
- https://git.kernel.org/stable/c/051af3f0b7d1cd8ab7f3e2523ad8ae1af44caba3
- https://git.kernel.org/stable/c/07821524f67bf920342bc84ae8b3dea2a315a89e
- https://git.kernel.org/stable/c/0f5bb36bf9b39a2a96e730bf4455095b50713f63
- https://git.kernel.org/stable/c/1550bcf2983ae1220cc8ab899a39a423fa7cb523
- https://git.kernel.org/stable/c/90229e9ee957d4514425e4a4d82c50ab5d57ac4d
- https://git.kernel.org/stable/c/c8f9c05e1ebcc9c7bc211cc8b74d8fb86a8756fc
- https://git.kernel.org/stable/c/dd5c77814f290b353917df329f36de1472d47154
- https://git.kernel.org/stable/c/f9982db735a8495eee14267cf193c806b957e942
Modified: 2026-01-14
CVE-2023-53220
In the Linux kernel, the following vulnerability has been resolved: media: az6007: Fix null-ptr-deref in az6007_i2c_xfer() In az6007_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach az6007_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
- https://git.kernel.org/stable/c/1047f9343011f2cedc73c64829686206a7e9fc3f
- https://git.kernel.org/stable/c/5b1ea100ad3695025969dc4693f307877fb688d6
- https://git.kernel.org/stable/c/6ab7ea4e17d6a605d05308adf8f3408924770cba
- https://git.kernel.org/stable/c/991c77fe18c6f374bbf83376f8c42550aa565662
- https://git.kernel.org/stable/c/a1110f19d4940e4185251d072cbb0ff51486a1e7
- https://git.kernel.org/stable/c/a9def3e9718a4dc756f48db147d42ec41a966240
- https://git.kernel.org/stable/c/adcb73f8ce9aec48b1f85223f401c1574015d8d2
- https://git.kernel.org/stable/c/c6763fefa267f6e62595a6ac1f57815d99fc90b7
Modified: 2026-01-14
CVE-2023-53221
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memleak due to fentry attach failure If it fails to attach fentry, the allocated bpf trampoline image will be left in the system. That can be verified by checking /proc/kallsyms. This meamleak can be verified by a simple bpf program as follows: SEC("fentry/trap_init") int fentry_run() { return 0; } It will fail to attach trap_init because this function is freed after kernel init, and then we can find the trampoline image is left in the system by checking /proc/kallsyms. $ tail /proc/kallsyms ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf] $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'" [2522] FUNC 'trap_init' type_id=119 linkage=static $ echo $((6442453466 & 0x7fffffff)) 2522 Note that there are two left bpf trampoline images, that is because the libbpf will fallback to raw tracepoint if -EINVAL is returned.
Modified: 2026-01-14
CVE-2023-53222
In the Linux kernel, the following vulnerability has been resolved: jfs: jfs_dmap: Validate db_l2nbperpage while mounting In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block number inside dbFree(). db_l2nbperpage, which is the log2 number of blocks per page, is passed as an argument to BLKTODMAP which uses it for shifting. Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is too big. This happens because the large value is set without any validation in dbMount() at line 181. Thus, make sure that db_l2nbperpage is correct while mounting. Max number of blocks per page = Page size / Min block size => log2(Max num_block per page) = log2(Page size / Min block size) = log2(Page size) - log2(Min block size) => Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE
- https://git.kernel.org/stable/c/11509910c599cbd04585ec35a6d5e1a0053d84c1
- https://git.kernel.org/stable/c/2a03c4e683d33d17b667418eb717b13dda1fac6b
- https://git.kernel.org/stable/c/47b7eaae08e8b2f25bdf37bc14d21be090bcb20f
- https://git.kernel.org/stable/c/8c1efe3f74a7864461b0dff281c5562154b4aa8e
- https://git.kernel.org/stable/c/a4855aeb13e4ad1f23e16753b68212e180f7d848
- https://git.kernel.org/stable/c/c7feb54b113802d2aba98708769d3c33fb017254
- https://git.kernel.org/stable/c/de984faecddb900fa850af4df574a25b32bb93f5
- https://git.kernel.org/stable/c/ef5c205b6e6f8d1f18ef0b4a9832b1b5fa85f7f2
Modified: 2026-01-14
CVE-2023-53223
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Add missing check for alloc_ordered_workqueue Add check for the return value of alloc_ordered_workqueue as it may return NULL pointer and cause NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/517646/
- https://git.kernel.org/stable/c/115906ca7b535afb1fe7b5406c566ccd3873f82b
- https://git.kernel.org/stable/c/25a6499b1a53d854eda2b161b5c8a20296515dbe
- https://git.kernel.org/stable/c/3a9a4a9725c60f04326b5019a52ce15aee808506
- https://git.kernel.org/stable/c/3e18f157faeeb59034404569e8e07cbe1c0030a7
- https://git.kernel.org/stable/c/540c66180afd59309a442d3bf1f2393464c8b4c5
- https://git.kernel.org/stable/c/5dfe7a5386fde5a656ca06602b31bf50e26954cd
- https://git.kernel.org/stable/c/759ea5677c362fb1e3edc667260ba9f409dc931d
- https://git.kernel.org/stable/c/9257974858ee847b2e1fd552691b8ba5c2fc1c7b
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-53225
In the Linux kernel, the following vulnerability has been resolved: spi: imx: Don't skip cleanup in remove's error path Returning early in a platform driver's remove callback is wrong. In this case the dma resources are not released in the error path. this is never retried later and so this is a permanent leak. To fix this, only skip hardware disabling if waking the device fails.
- https://git.kernel.org/stable/c/11951c9e3f364d7ae3b568a0e52c8335d43066b5
- https://git.kernel.org/stable/c/57a463226638f1ceabbb029cbd21b0c94640f1b5
- https://git.kernel.org/stable/c/6d16305a1535873e0a8a8ae92ea2d9106ec2d7df
- https://git.kernel.org/stable/c/aa93a46f998a9069368026ac52bba96868c59157
- https://git.kernel.org/stable/c/b64cb3f085fed296103c91f0db6acad30a021b36
- https://git.kernel.org/stable/c/f90822ad63d11301e425311dac0c8e12ca1737b8
Modified: 2026-01-14
CVE-2023-53226
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix OOB and integer underflow when rx packets Make sure mwifiex_process_mgmt_packet, mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet, mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet not out-of-bounds access the skb->data buffer.
- https://git.kernel.org/stable/c/11958528161731c58e105b501ed60b83a91ea941
- https://git.kernel.org/stable/c/29eca8b7863d1d7de6c5b746b374e3487d14f154
- https://git.kernel.org/stable/c/3975e21d4d01efaf0296ded40d11c06589c49245
- https://git.kernel.org/stable/c/3fe3923d092e22d87d1ed03e2729db444b8c1331
- https://git.kernel.org/stable/c/650d1bc02fba7b42f476d8b6643324abac5921ed
- https://git.kernel.org/stable/c/7c54b6fc39eb1aac51cf2945f8a25e2a47fdca02
- https://git.kernel.org/stable/c/8824aa4ab62c800f75d96f48e1883a5f56ec5869
- https://git.kernel.org/stable/c/a7300e3800e9fd5405e88ce67709c1a97783b9c8
- https://git.kernel.org/stable/c/f517c97fc129995de77dd06aa5a74f909ebf568f
Modified: 2026-01-14
CVE-2023-53229
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta Avoid potential data corruption issues caused by uninitialized driver private data structures.
- https://git.kernel.org/stable/c/022c8320d9eb7394538bd716fa1a07a5ed92621b
- https://git.kernel.org/stable/c/12b220a6171faf10638ab683a975cadcf1a352d6
- https://git.kernel.org/stable/c/30c5a016a37a668c1c07442cf94de6e99ea7417a
- https://git.kernel.org/stable/c/3fe20515449a80a177526d2ecd13b43f6ee41aeb
- https://git.kernel.org/stable/c/73752a39e2a6e38eee3ba90ece2ded598ea88006
- https://git.kernel.org/stable/c/7e68d7c640d41d8a371b8f6c2d2682ea437cbe21
- https://git.kernel.org/stable/c/a3593082e0dadf87f17ea4ca9fa0210caaa2aebf
- https://git.kernel.org/stable/c/db8d32d6b25fdb75c387daee496b96209d477780
Modified: 2026-01-14
CVE-2023-53230
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix warning in cifs_smb3_do_mount() This fixes the following warning reported by kernel test robot fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of 'cifs_sb'
Modified: 2026-03-17
CVE-2023-53232
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix kernel panic by accessing unallocated eeprom.data
The MT7921 driver no longer uses eeprom.data, but the relevant code has not
been removed completely since
commit 16d98b548365 ("mt76: mt7921: rely on mcu_get_nic_capability").
This could result in potential invalid memory access.
To fix the kernel panic issue in mt7921, it is necessary to avoid accessing
unallocated eeprom.data which can lead to invalid memory access.
Furthermore, it is possible to entirely eliminate the
mt7921_mcu_parse_eeprom function and solely depend on
mt7921_mcu_parse_response to divide the RxD header.
[2.702735] BUG: kernel NULL pointer dereference, address: 0000000000000550
[2.702740] #PF: supervisor write access in kernel mode
[2.702741] #PF: error_code(0x0002) - not-present page
[2.702743] PGD 0 P4D 0
[2.702747] Oops: 0002 [#1] PREEMPT SMP NOPTI
[2.702755] RIP: 0010:mt7921_mcu_parse_response+0x147/0x170 [mt7921_common]
[2.702758] RSP: 0018:ffffae7c00fef828 EFLAGS: 00010286
[2.702760] RAX: ffffa367f57be024 RBX: ffffa367cc7bf500 RCX: 0000000000000000
[2.702762] RDX: 0000000000000550 RSI: 0000000000000000 RDI: ffffa367cc7bf500
[2.702763] RBP: ffffae7c00fef840 R08: ffffa367cb167000 R09: 0000000000000005
[2.702764] R10: 0000000000000000 R11: ffffffffc04702e4 R12: ffffa367e8329f40
[2.702766] R13: 0000000000000000 R14: 0000000000000001 R15: ffffa367e8329f40
[2.702768] FS: 000079ee6cf20c40(0000) GS:ffffa36b2f940000(0000) knlGS:0000000000000000
[2.702769] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[2.702775] CR2: 0000000000000550 CR3: 00000001233c6004 CR4: 0000000000770ee0
[2.702776] PKRU: 55555554
[2.702777] Call Trace:
[2.702782] mt76_mcu_skb_send_and_get_msg+0xc3/0x11e [mt76
Modified: 2026-01-14
CVE-2023-53233
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix deadlock triggered by cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock: 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0 __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20 __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated---
- https://git.kernel.org/stable/c/13085e1b5cab8ad802904d72e6a6dae85ae0cd20
- https://git.kernel.org/stable/c/3517584cf1b35bd02f4a90267ddf9dcf17bd9c87
- https://git.kernel.org/stable/c/9708efad9ba5095b9bb7916e11a135b3bd66c071
- https://git.kernel.org/stable/c/b615238e5bc01e13dc0610febddc1ca99bab1df6
- https://git.kernel.org/stable/c/c9ca2257150272df1b8d9ebe5059197ffea6e913
Modified: 2026-01-14
CVE-2023-53234
In the Linux kernel, the following vulnerability has been resolved: watchdog: Fix kmemleak in watchdog_cdev_register kmemleak reports memory leaks in watchdog_dev_register, as follows: unreferenced object 0xffff888116233000 (size 2048): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 32 bytes): 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#..... 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#............. backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<000000006a389304>] kmalloc_trace+0x21/0x110 [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... unreferenced object 0xffff888105b9fa80 (size 16): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 16 bytes): 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1....... backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintf_const+0x55/0x180 [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150 [<00000000a92e820b>] dev_set_name+0xab/0xe0 [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... The reason is that put_device is not be called if cdev_device_add fails and wdd->id != 0. watchdog_cdev_register wd_data = kzalloc [1] err = dev_set_name [2] .. err = cdev_device_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // [1],[2] would be leaked To fix it, call put_device in all wdd->id cases.
- https://git.kernel.org/stable/c/13721a2ac66b246f5802ba1b75ad8637e53eeecc
- https://git.kernel.org/stable/c/23cc41c3f19c4d858c3708f1c0a06e94958e6c3b
- https://git.kernel.org/stable/c/50808d034e199fe3ff7a9d2068a4eebeb6b4098a
- https://git.kernel.org/stable/c/59e391b3fc507a15b7e8e9d9f4de87cae177c366
- https://git.kernel.org/stable/c/8c1655600f4f2839fb844fe8c70b2b65fadc7a56
- https://git.kernel.org/stable/c/ac099d94e0480c937aa9172ab64074981ca1a4d3
- https://git.kernel.org/stable/c/bf26b0e430ce34261f45959989edaf680b64d538
- https://git.kernel.org/stable/c/c5a21a5501508ae3afa2fe6d5a3e74a37fa48df3
Modified: 2026-01-14
CVE-2023-53238
In the Linux kernel, the following vulnerability has been resolved: phy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe() The size of array 'priv->ports[]' is INNO_PHY_PORT_NUM. In the for loop, 'i' is used as the index for array 'priv->ports[]' with a check (i > INNO_PHY_PORT_NUM) which indicates that INNO_PHY_PORT_NUM is allowed value for 'i' in the same loop. This > comparison needs to be changed to >=, otherwise it potentially leads to an out of bounds write on the next iteration through the loop
- https://git.kernel.org/stable/c/01cb355bb92e8fcf8306e11a4774d610c5864e39
- https://git.kernel.org/stable/c/13c088cf3657d70893d75cf116be937f1509cc0f
- https://git.kernel.org/stable/c/195e806b2afb0bad6470c9094f7e45e0cf109ee0
- https://git.kernel.org/stable/c/2843a2e703f5cb85c9eeca11b7ee90861635a010
- https://git.kernel.org/stable/c/6d8a71e4c3a2fa4960cc50996e76a42b62fab677
- https://git.kernel.org/stable/c/ad249aa3c38f329f91fba8b4b3cd087e79fb0ce8
- https://git.kernel.org/stable/c/ce69eac840db0b559994dc4290fce3d7c0d7bccd
Modified: 2026-01-14
CVE-2023-53239
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Add check for kzalloc As kzalloc may fail and return NULL pointer, it should be better to check the return value in order to avoid the NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/514154/
- https://git.kernel.org/stable/c/13fcfcb2a9a4787fe4e49841d728f6f2e9fa6911
- https://git.kernel.org/stable/c/37ff771ed008b9cbffd0eab77985968364694ce3
- https://git.kernel.org/stable/c/3975ea6eaffe26aec634b5c473e51dc76e73af62
- https://git.kernel.org/stable/c/49907c8873826ee771ba0ca1629e809c6479f617
- https://git.kernel.org/stable/c/82943a0730e00c14b03e25a4b2a1a9477ae89d7b
- https://git.kernel.org/stable/c/bc579a2ee8b2e20c152b24b437d094832d8c9c9e
Modified: 2026-01-14
CVE-2023-53240
In the Linux kernel, the following vulnerability has been resolved:
xsk: check IFF_UP earlier in Tx path
Xsk Tx can be triggered via either sendmsg() or poll() syscalls. These
two paths share a call to common function xsk_xmit() which has two
sanity checks within. A pseudo code example to show the two paths:
__xsk_sendmsg() : xsk_poll():
if (unlikely(!xsk_is_bound(xs))) if (unlikely(!xsk_is_bound(xs)))
return -ENXIO; return mask;
if (unlikely(need_wait)) (...)
return -EOPNOTSUPP; xsk_xmit()
mark napi id
(...)
xsk_xmit()
xsk_xmit():
if (unlikely(!(xs->dev->flags & IFF_UP)))
return -ENETDOWN;
if (unlikely(!xs->tx))
return -ENOBUFS;
As it can be observed above, in sendmsg() napi id can be marked on
interface that was not brought up and this causes a NULL ptr
dereference:
[31757.505631] BUG: kernel NULL pointer dereference, address: 0000000000000018
[31757.512710] #PF: supervisor read access in kernel mode
[31757.517936] #PF: error_code(0x0000) - not-present page
[31757.523149] PGD 0 P4D 0
[31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI
[31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+ #40
[31757.536871] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[31757.547457] RIP: 0010:xsk_sendmsg+0xde/0x180
[31757.551799] Code: 00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 48 8b 80 98 00 00 00 48 8b 40 20 <8b> 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f
[31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246
[31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000
[31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100
[31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000
[31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa
[31757.605123] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000000
[31757.612364] FS: 00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000
[31757.620571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4: 00000000007706e0
[31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[31757.648139] PKRU: 55555554
[31757.650894] Call Trace:
[31757.653385]
Modified: 2026-01-14
CVE-2023-53241
In the Linux kernel, the following vulnerability has been resolved: nfsd: call op_release, even when op_func returns an error For ops with "trivial" replies, nfsd4_encode_operation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time. Have the compound processing engine always call op_release, even when op_func sets an error in op->status. With this change, we also need nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL on error to avoid a double free.
- https://git.kernel.org/stable/c/15a8b55dbb1ba154d82627547c5761cac884d810
- https://git.kernel.org/stable/c/3d0dcada384af22dec764c8374a2997870ec86ae
- https://git.kernel.org/stable/c/65a33135e91e6dd661ecdf1194b9d90c49ae3570
- https://git.kernel.org/stable/c/b11d8162c24af4a351d21e2c804d25ca493305e3
- https://git.kernel.org/stable/c/b623a8e5d38a69a3ef8644acb1030dd7c7bc28b3
Modified: 2026-01-14
CVE-2023-53242
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/hisi: Drop second sensor hi3660 The commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm allocators") exposes a panic "BRK handler: Fatal exception" on the hi3660_thermal_probe funciton. This is because the function allocates memory for only one sensors array entry, but tries to fill up a second one. Fix this by removing the unneeded second access.
- https://git.kernel.org/stable/c/15cc25829a97c3957e520e971868aacc84341317
- https://git.kernel.org/stable/c/3cf2181e438f43ed24e12424fe36d156cca233b9
- https://git.kernel.org/stable/c/68e675a9b69cfc34dd915d91a4650e3ee53421f4
- https://git.kernel.org/stable/c/9f6756cd09889c7201ee31e6f76fbd914fb0b80d
- https://git.kernel.org/stable/c/e02bc492883abf751fd1a8d89fc025fbce6744c6
- https://git.kernel.org/stable/c/f5aaf140ab1c02889c088e1b1098adad600541af
Modified: 2026-01-14
CVE-2023-53243
In the Linux kernel, the following vulnerability has been resolved:
btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profile
Callers of `btrfs_reduce_alloc_profile` expect it to return exactly
one allocation profile flag, and failing to do so may ultimately
result in a WARN_ON and remount-ro when allocating new blocks, like
the below transaction abort on 6.1.
`btrfs_reduce_alloc_profile` has two ways of determining the profile,
first it checks if a conversion balance is currently running and
uses the profile we're converting to. If no balance is currently
running, it returns the max-redundancy profile which at least one
block in the selected block group has.
This works by simply checking each known allocation profile bit in
redundancy order. However, `btrfs_reduce_alloc_profile` has not been
updated as new flags have been added - first with the `DUP` profile
and later with the RAID1C34 profiles.
Because of the way it checks, if we have blocks with different
profiles and at least one is known, that profile will be selected.
However, if none are known we may return a flag set with multiple
allocation profiles set.
This is currently only possible when a balance from one of the three
unhandled profiles to another of the unhandled profiles is canceled
after allocating at least one block using the new profile.
In that case, a transaction abort like the below will occur and the
filesystem will need to be mounted with -o skip_balance to get it
mounted rw again (but the balance cannot be resumed without a
similar abort).
[770.648] ------------[ cut here ]------------
[770.648] BTRFS: Transaction aborted (error -22)
[770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs]
[770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test
[770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV
[770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0
[770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test)
[770.648] MSR: 9000000002029033
- https://git.kernel.org/stable/c/12b6d68498982a053a4a7e561a04387e57ca6f1a
- https://git.kernel.org/stable/c/160fe8f6fdb13da6111677be6263e5d65e875987
- https://git.kernel.org/stable/c/1b532748ba00bd2a1d9b09e0d5e81280582c7770
- https://git.kernel.org/stable/c/4fadf53fa95142f01f215012e97c384529759a72
- https://git.kernel.org/stable/c/a3fbd156bd2cd16e3c64e250ebce33eb9f2ef612
Modified: 2026-01-14
CVE-2023-53244
In the Linux kernel, the following vulnerability has been resolved: media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finish When the driver calls tw68_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer buf->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of tw68_risc_buffer() and the value of buf->cpu before buffer free.
Modified: 2026-01-14
CVE-2023-53245
In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix handling of virtual Fibre Channel timeouts Hyper-V provides the ability to connect Fibre Channel LUNs to the host system and present them in a guest VM as a SCSI device. I/O to the vFC device is handled by the storvsc driver. The storvsc driver includes a partial integration with the FC transport implemented in the generic portion of the Linux SCSI subsystem so that FC attributes can be displayed in /sys. However, the partial integration means that some aspects of vFC don't work properly. Unfortunately, a full and correct integration isn't practical because of limitations in what Hyper-V provides to the guest. In particular, in the context of Hyper-V storvsc, the FC transport timeout function fc_eh_timed_out() causes a kernel panic because it can't find the rport and dereferences a NULL pointer. The original patch that added the call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this regard. In many cases a timeout is due to a transient condition, so the situation can be improved by just continuing to wait like with other I/O requests issued by storvsc, and avoiding the guaranteed panic. For a permanent failure, continuing to wait may result in a hung thread instead of a panic, which again may be better. So fix the panic by removing the storvsc call to fc_eh_timed_out(). This allows storvsc to keep waiting for a response. The change has been tested by users who experienced a panic in fc_eh_timed_out() due to transient timeouts, and it solves their problem. In the future we may want to deprecate the vFC functionality in storvsc since it can't be fully fixed. But it has current users for whom it is working well enough, so it should probably stay for a while longer.
- https://git.kernel.org/stable/c/048ebc9a28fb918ee635dd4b2fcf4248eb6e4050
- https://git.kernel.org/stable/c/1678408d08f31a694d5150a56796dd04c9710b22
- https://git.kernel.org/stable/c/175544ad48cbf56affeef2a679c6a4d4fb1e2881
- https://git.kernel.org/stable/c/311db605e07f0d4fc0cc7ddb74f1e5692ea2f469
- https://git.kernel.org/stable/c/763c06565055ae373fe7f89c11e1447bd1ded264
- https://git.kernel.org/stable/c/7a792b3d888aab2c65389f9f4f9f2f6c000b1a0d
- https://git.kernel.org/stable/c/cd87f4df9865a53807001ed12c0f0420b14ececd
- https://git.kernel.org/stable/c/ed70fa5629a8b992a5372d7044d1db1f8fa6de29
Modified: 2026-01-05
CVE-2023-53246
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALL
When compiled with CONFIG_CIFS_DFS_UPCALL disabled, cifs_dfs_d_automount
is NULL. cifs.ko logic for mapping CIFS_FATTR_DFS_REFERRAL attributes to
S_AUTOMOUNT and corresponding dentry flags is retained regardless of
CONFIG_CIFS_DFS_UPCALL, leading to a NULL pointer dereference in
VFS follow_automount() when traversing a DFS referral link:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
- https://git.kernel.org/stable/c/179a88a8558bbf42991d361595281f3e45d7edfc
- https://git.kernel.org/stable/c/1e144b68208e98fd4602c842a7149ba5f41d87fb
- https://git.kernel.org/stable/c/26a32a212bc540f4773cd6af8cf73e967d72569c
- https://git.kernel.org/stable/c/b64305185b76f1d5145ce594ff48f3f0e70695bd
- https://git.kernel.org/stable/c/b7d854c33ab48e55fc233699bbefe39ec9bb5c05
Modified: 2026-01-14
CVE-2023-53247
In the Linux kernel, the following vulnerability has been resolved: btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand While trying to get the subpage blocksize tests running, I hit the following panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198 This happens because during btrfs_cont_expand we'll get a page, set it as mapped, and if it's not Uptodate we'll read it. However between the read and re-locking the page we could have called release_folio() on the page, but left the page in the file mapping. release_folio() can clear the page private, and thus further down we blow up when we go to modify the subpage bits. Fix this by putting the set_page_extent_mapped() after the read. This is safe because read_folio() will call set_page_extent_mapped() before it does the read, and then if we clear page private but leave it on the mapping we're completely safe re-setting set_page_extent_mapped(). With this patch I can now run generic/476 without panicing.
Modified: 2026-01-14
CVE-2023-53248
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: install stub fence into potential unused fence pointers When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Modified: 2026-01-14
CVE-2023-53249
In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imx8mn: fix memory leak in imx8mn_clocks_probe Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devm_kzalloc() instead will automatically free the memory using devm_kfree().
- https://git.kernel.org/stable/c/188d070de9132667956f5aadd98d2bd87d3eac89
- https://git.kernel.org/stable/c/294321349bd3b0680847fc2bbe66b9ab3e522fea
- https://git.kernel.org/stable/c/50b5ddde8fad5f0ffd239029d0956af633a0f9b1
- https://git.kernel.org/stable/c/9428cf0fbf4be9a24f3e15a0c166b861b12666af
- https://git.kernel.org/stable/c/9ba3693b0350b154fdd7830559bbc7b04c067096
- https://git.kernel.org/stable/c/d4fa5e47af1e7bb2bbcaac062b14216c00e92148
Modified: 2026-01-14
CVE-2023-53250
In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 1373 Comm: modprobe
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:dmi_sysfs_entry_release
...
Call Trace:
Modified: 2026-01-14
CVE-2023-53251
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: fix NULL pointer dereference in iwl_pcie_irq_rx_msix_handler() rxq can be NULL only when trans_pcie->rxq is NULL and entry->entry is zero. For the case when entry->entry is not equal to 0, rxq won't be NULL even if trans_pcie->rxq is NULL. Modify checker to check for trans_pcie->rxq.
- https://git.kernel.org/stable/c/1902f1953b8ba100ee8705cb8a6f1a9795550eca
- https://git.kernel.org/stable/c/2d690495eb2766d58e25c83676f422219c4fcf18
- https://git.kernel.org/stable/c/390e44efcf4d390b5053ad112553155d2d097c73
- https://git.kernel.org/stable/c/3b9de981fe7f1c6e07c7b852421ad69be3d4b6c2
- https://git.kernel.org/stable/c/f71d0fc407dd028416bec002ddcc62f5acb0346a
Modified: 2026-01-14
CVE-2023-53252
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: use RCU for hci_conn_params and iterate safely in hci_sync
hci_update_accept_list_sync iterates over hdev->pend_le_conns and
hdev->pend_le_reports, and waits for controller events in the loop body,
without holding hdev lock.
Meanwhile, these lists and the items may be modified e.g. by
le_scan_cleanup. This can invalidate the list cursor or any other item
in the list, resulting to invalid behavior (eg use-after-free).
Use RCU for the hci_conn_params action lists. Since the loop bodies in
hci_sync block and we cannot use RCU or hdev->lock for the whole loop,
copy list items first and then iterate on the copy. Only the flags field
is written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee we
read valid values.
Free params everywhere with hci_conn_params_free so the cleanup is
guaranteed to be done properly.
This fixes the following, which can be triggered e.g. by BlueZ new
mgmt-tester case "Add + Remove Device Nowait - Success", or by changing
hci_le_set_cig_params to always return false, and running iso-tester:
==================================================================
BUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)
Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
Modified: 2026-01-14
CVE-2023-53254
In the Linux kernel, the following vulnerability has been resolved: cacheinfo: Fix shared_cpu_map to handle shared caches at different levels The cacheinfo sets up the shared_cpu_map by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched shared_cpu_map when the shared cache does not have the same index between CPUs. CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3 This patch checks each cache is shared with all caches on other CPUs.
Modified: 2026-01-14
CVE-2023-53255
In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool() svc_create_memory_pool() is only called from stratix10_svc_drv_probe(). Most of resources in the probe are managed, but not this memremap() call. There is also no memunmap() call in the file. So switch to devm_memremap() to avoid a resource leak.
- https://git.kernel.org/stable/c/1995f15590ca222f91193ed11461862b450abfd6
- https://git.kernel.org/stable/c/7363de081c793e47866cb54ce7cb8a480cffc259
- https://git.kernel.org/stable/c/974ac045a05ad12a0b4578fb303f00dcc22f3aba
- https://git.kernel.org/stable/c/c04ed61ebf01968d7699b121663982493ed577fb
- https://git.kernel.org/stable/c/cb8a31a56df8492fb0d900959238e1a3ff8b8981
- https://git.kernel.org/stable/c/e3373e6b6c79aff698442b00d20c9f285d296e46
Modified: 2026-01-14
CVE-2023-53256
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix FFA device names for logical partitions Each physical partition can provide multiple services each with UUID. Each such service can be presented as logical partition with a unique combination of VM ID and UUID. The number of distinct UUID in a system will be less than or equal to the number of logical partitions. However, currently it fails to register more than one logical partition or service within a physical partition as the device name contains only VM ID while both VM ID and UUID are maintained in the partition information. The kernel complains with the below message: | sysfs: cannot create duplicate filename '/devices/arm-ffa-8001' | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8 | Hardware name: FVP Base RevC (DT) | Call trace: | dump_backtrace+0xf8/0x118 | show_stack+0x18/0x24 | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | sysfs_create_dir_ns+0xe0/0x13c | kobject_add_internal+0x220/0x3d4 | kobject_add+0x94/0x100 | device_add+0x144/0x5d8 | device_register+0x20/0x30 | ffa_device_register+0x88/0xd8 | ffa_setup_partitions+0x108/0x1b8 | ffa_init+0x2ec/0x3a4 | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to | register things with the same name in the same directory. | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17 | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001 By virtue of being random enough to avoid collisions when generated in a distributed system, there is no way to compress UUID keys to the number of bits required to identify each. We can eliminate '-' in the name but it is not worth eliminating 4 bytes and add unnecessary logic for doing that. Also v1.0 doesn't provide the UUID of the partitions which makes it hard to use the same for the device name. So to keep it simple, let us alloc an ID using ida_alloc() and append the same to "arm-ffa" to make up a unique device name. Also stash the id value in ffa_dev to help freeing the ID later when the device is destroyed.
Modified: 2026-01-14
CVE-2023-53257
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check S1G action frame size Before checking the action code, check that it even exists in the frame.
Modified: 2026-01-14
CVE-2023-53258
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix possible underflow for displays with large vblank [Why] Underflow observed when using a display with a large vblank region and low refresh rate [How] Simplify calculation of vblank_nom Increase value for VBlankNomDefaultUS to 800us
Modified: 2026-01-16
CVE-2023-53259
In the Linux kernel, the following vulnerability has been resolved:
VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF
The call to get_user_pages_fast() in vmci_host_setup_notify() can return
NULL context->notify_page causing a GPF. To avoid GPF check if
context->notify_page == NULL and return error if so.
general protection fault, probably for non-canonical address
0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: maybe wild-memory-access in range [0x0005088000000300-
0x0005088000000307]
CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1
Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014
RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0
Call Trace:
- https://git.kernel.org/stable/c/055891397f530f9b1b22be38d7eca8b08382941f
- https://git.kernel.org/stable/c/1a726cb47fd204109c767409fa9ca15a96328f14
- https://git.kernel.org/stable/c/91b8e4f61f8f4594ee65368c8d89e6fdc29d3fb1
- https://git.kernel.org/stable/c/a3c89e8c69a58f62451c0a75b77fcab25979b897
- https://git.kernel.org/stable/c/b4239bfb260d1e6837766c41a0b241d7670f1402
- https://git.kernel.org/stable/c/d4198f67e7556b1507f14f60d81a72660e5560e4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2026-01-14
CVE-2023-53260
In the Linux kernel, the following vulnerability has been resolved:
ovl: fix null pointer dereference in ovl_permission()
Following process:
P1 P2
path_lookupat
link_path_walk
inode_permission
ovl_permission
ovl_i_path_real(inode, &realpath)
path->dentry = ovl_i_dentry_upper(inode)
drop_cache
__dentry_kill(ovl_dentry)
iput(ovl_inode)
ovl_destroy_inode(ovl_inode)
dput(oi->__upperdentry)
dentry_kill(upperdentry)
dentry_unlink_inode
upperdentry->d_inode = NULL
realinode = d_inode(realpath.dentry) // return NULL
inode_permission(realinode)
inode->i_sb // NULL pointer dereference
, will trigger an null pointer dereference at realinode:
[ 335.664979] BUG: kernel NULL pointer dereference,
address: 0000000000000002
[ 335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0
[ 335.669956] RIP: 0010:inode_permission+0x33/0x2c0
[ 335.678939] Call Trace:
[ 335.679165]
Modified: 2026-01-14
CVE-2023-53262
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix scheduling while atomic in decompression path [ 16.945668][ C0] Call trace: [ 16.945678][ C0] dump_backtrace+0x110/0x204 [ 16.945706][ C0] dump_stack_lvl+0x84/0xbc [ 16.945735][ C0] __schedule_bug+0xb8/0x1ac [ 16.945756][ C0] __schedule+0x724/0xbdc [ 16.945778][ C0] schedule+0x154/0x258 [ 16.945793][ C0] bit_wait_io+0x48/0xa4 [ 16.945808][ C0] out_of_line_wait_on_bit+0x114/0x198 [ 16.945824][ C0] __sync_dirty_buffer+0x1f8/0x2e8 [ 16.945853][ C0] __f2fs_commit_super+0x140/0x1f4 [ 16.945881][ C0] f2fs_commit_super+0x110/0x28c [ 16.945898][ C0] f2fs_handle_error+0x1f4/0x2f4 [ 16.945917][ C0] f2fs_decompress_cluster+0xc4/0x450 [ 16.945942][ C0] f2fs_end_read_compressed_page+0xc0/0xfc [ 16.945959][ C0] f2fs_handle_step_decompress+0x118/0x1cc [ 16.945978][ C0] f2fs_read_end_io+0x168/0x2b0 [ 16.945993][ C0] bio_endio+0x25c/0x2c8 [ 16.946015][ C0] dm_io_dec_pending+0x3e8/0x57c [ 16.946052][ C0] clone_endio+0x134/0x254 [ 16.946069][ C0] bio_endio+0x25c/0x2c8 [ 16.946084][ C0] blk_update_request+0x1d4/0x478 [ 16.946103][ C0] scsi_end_request+0x38/0x4cc [ 16.946129][ C0] scsi_io_completion+0x94/0x184 [ 16.946147][ C0] scsi_finish_command+0xe8/0x154 [ 16.946164][ C0] scsi_complete+0x90/0x1d8 [ 16.946181][ C0] blk_done_softirq+0xa4/0x11c [ 16.946198][ C0] _stext+0x184/0x614 [ 16.946214][ C0] __irq_exit_rcu+0x78/0x144 [ 16.946234][ C0] handle_domain_irq+0xd4/0x154 [ 16.946260][ C0] gic_handle_irq.33881+0x5c/0x27c [ 16.946281][ C0] call_on_irq_stack+0x40/0x70 [ 16.946298][ C0] do_interrupt_handler+0x48/0xa4 [ 16.946313][ C0] el1_interrupt+0x38/0x68 [ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30 [ 16.946362][ C0] el1h_64_irq+0x78/0x7c [ 16.946377][ C0] finish_task_switch+0xc8/0x3d8 [ 16.946394][ C0] __schedule+0x600/0xbdc [ 16.946408][ C0] preempt_schedule_common+0x34/0x5c [ 16.946423][ C0] preempt_schedule+0x44/0x48 [ 16.946438][ C0] process_one_work+0x30c/0x550 [ 16.946456][ C0] worker_thread+0x414/0x8bc [ 16.946472][ C0] kthread+0x16c/0x1e0 [ 16.946486][ C0] ret_from_fork+0x10/0x20
Modified: 2026-01-14
CVE-2023-53263
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create We can't simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first. It might not fix all regressions from commit 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it fixes a memory corruption in error handling related to that commit.
Modified: 2026-01-14
CVE-2023-53264
In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devm_kzalloc() instead will automatically free the memory using devm_kfree(). Also, fix error handling of hws by adding unregister_hws label, which unregisters remaining hws when iomap failed.
Modified: 2026-01-14
CVE-2023-53265
In the Linux kernel, the following vulnerability has been resolved:
ubi: ensure that VID header offset + VID header size <= alloc, size
Ensure that the VID header offset + VID header size does not exceed
the allocated area to avoid slab OOB.
BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197
Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555
CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W
6.0.0-1868 #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29
04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1b42b1a36fc946f0d7088425b90d491b4257ca3e
- https://git.kernel.org/stable/c/61aeba0e4b4124cfe3c5427feaf29c626dfa89e5
- https://git.kernel.org/stable/c/61e04db3bec87f7dd10074296deb7d083e2ccade
- https://git.kernel.org/stable/c/701bb3ed5a88a73ebbe1266895bdeff065226dca
- https://git.kernel.org/stable/c/771e207a839a29ba943e89f473b0fecd16089e2e
- https://git.kernel.org/stable/c/846bfba34175c23b13cc2023c2d67b96e8c14c43
- https://git.kernel.org/stable/c/e1b73fe4f4c6bb80755eb4bf4b867a8fd8b1a7fe
- https://git.kernel.org/stable/c/f7adb740f97b6fa84e658892dcb08e37a31a4e77
Modified: 2026-01-14
CVE-2023-53267
In the Linux kernel, the following vulnerability has been resolved: driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event() The kfree() should be called when memory fails to be allocated for cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be a memory leak, so add kfree() to fix it.
Modified: 2026-01-14
CVE-2023-53268
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_mqs: move of_node_put() to the correct location of_node_put() should have been done directly after mqs_priv->regmap = syscon_node_to_regmap(gpr_np); otherwise it creates a reference leak on the success path. To fix this, of_node_put() is moved to the correct location, and change all the gotos to direct returns.
- https://git.kernel.org/stable/c/1bdb4a5ccab2316935ce4ad4fd4df8d36f0ffc6e
- https://git.kernel.org/stable/c/1c34890273a020d61d6127ade3f68ed1cb21c16a
- https://git.kernel.org/stable/c/402299cca89273b62384b5f9645ea49cd5fc4a57
- https://git.kernel.org/stable/c/6a129c0e9935112ecf2ffb6de98f83b8fd090c86
- https://git.kernel.org/stable/c/9a2585088a7d6f98a5a910f5b4b74b6d24e63156
- https://git.kernel.org/stable/c/b5a6930fc6a432e32714c4ed3c597077d999cf6d
Modified: 2026-01-14
CVE-2023-53269
In the Linux kernel, the following vulnerability has been resolved: block: ublk: make sure that block size is set correctly block size is one very key setting for block layer, and bad block size could panic kernel easily. Make sure that block size is set correctly. Meantime if ublk_validate_params() fails, clear ub->params so that disk is prevented from being added.
Modified: 2026-01-14
CVE-2023-53270
In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_disksize exceeding i_size problem in paritally written case It is possible for i_disksize can exceed i_size, triggering a warning. generic_perform_write copied = iov_iter_copy_from_user_atomic(len) // copied < len ext4_da_write_end | ext4_update_i_disksize | new_i_size = pos + copied; | WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize | generic_write_end | copied = block_write_end(copied, len) // copied = 0 | if (unlikely(copied < len)) | if (!PageUptodate(page)) | copied = 0; | if (pos + copied > inode->i_size) // return false if (unlikely(copied == 0)) goto again; if (unlikely(iov_iter_fault_in_readable(i, bytes))) { status = -EFAULT; break; } We get i_disksize greater than i_size here, which could trigger WARNING check 'i_size_read(inode) < EXT4_I(inode)->i_disksize' while doing dio: ext4_dio_write_iter iomap_dio_rw __iomap_dio_rw // return err, length is not aligned to 512 ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize) // Oops WARNING: CPU: 2 PID: 2609 at fs/ext4/file.c:319 CPU: 2 PID: 2609 Comm: aa Not tainted 6.3.0-rc2 RIP: 0010:ext4_file_write_iter+0xbc7 Call Trace: vfs_write+0x3b1 ksys_write+0x77 do_syscall_64+0x39 Fix it by updating 'copied' value before updating i_disksize just like ext4_write_inline_data_end() does. A reproducer can be found in the buganizer link below.
- https://git.kernel.org/stable/c/18eb23891aeae3229baf8c7c23b76be3364e1967
- https://git.kernel.org/stable/c/1dedde690303c05ef732b7c5c8356fdf60a4ade3
- https://git.kernel.org/stable/c/3ecea2fee14227712694c8b54ad99d471e61de92
- https://git.kernel.org/stable/c/53877ed201baa6b58f7ce9df92664a839113c30e
- https://git.kernel.org/stable/c/d30090eb546d993ea3f3023452540c476ea614a5
Modified: 2026-01-14
CVE-2023-53271
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()
There is a memory leaks problem reported by kmemleak:
unreferenced object 0xffff888102007a00 (size 128):
comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s)
hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
backtrace:
[
- https://git.kernel.org/stable/c/07b60f7452d2fa731737552937cb81821919f874
- https://git.kernel.org/stable/c/09780a44093b53f9cbca76246af2e4ff0884e512
- https://git.kernel.org/stable/c/1e591ea072df7211f64542a09482b5f81cb3ad27
- https://git.kernel.org/stable/c/26ec2d66aecab8ff997b912c20247fedba4f5740
- https://git.kernel.org/stable/c/27b760b81951d8d5e5c952a696af8574052b0709
- https://git.kernel.org/stable/c/31d60afe2cc2b712dbefcaab6b7d6a47036f844e
- https://git.kernel.org/stable/c/5c0c81a313492b83bd0c038b8839b0e04eb87563
- https://git.kernel.org/stable/c/95a72417dd13ebcdcb1bd0c5d4d15f7c5bfbb288
Modified: 2026-01-14
CVE-2023-53272
In the Linux kernel, the following vulnerability has been resolved:
net: ena: fix shift-out-of-bounds in exponential backoff
The ENA adapters on our instances occasionally reset. Once recently
logged a UBSAN failure to console in the process:
UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13
shift exponent 32 is too large for 32-bit type 'unsigned int'
CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117
Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017
Workqueue: ena ena_fw_reset_device [ena]
Call Trace:
- https://git.kernel.org/stable/c/0939c264729d4a081ff88efce2ffdf85dc5331e0
- https://git.kernel.org/stable/c/1e760b2d18bf129b3da052c2946c02758e97d15e
- https://git.kernel.org/stable/c/1e9cb763e9bacf0c932aa948f50dcfca6f519a26
- https://git.kernel.org/stable/c/3e36cc94d6e60a27f27498adf1c71eeba769ab33
- https://git.kernel.org/stable/c/90947ebf8794e3c229fb2e16e37f1bfea6877f14
Modified: 2026-01-14
CVE-2023-53273
In the Linux kernel, the following vulnerability has been resolved: Drivers: vmbus: Check for channel allocation before looking up relids relid2channel() assumes vmbus channel array to be allocated when called. However, in cases such as kdump/kexec, not all relids will be reset by the host. When the second kernel boots and if the guest receives a vmbus interrupt during vmbus driver initialization before vmbus_connect() is called, before it finishes, or if it fails, the vmbus interrupt service routine is called which in turn calls relid2channel() and can cause a null pointer dereference. Print a warning and error out in relid2channel() for a channel id that's invalid in the second kernel.
- https://git.kernel.org/stable/c/176c6b4889195fbe7016d9401175b48c5c9edf68
- https://git.kernel.org/stable/c/1eb65c8687316c65140b48fad27133d583178e15
- https://git.kernel.org/stable/c/8c3f0ae5435fd20bb1e3a8308488aa6ac33151ee
- https://git.kernel.org/stable/c/a5c44f3446a0565139b7d8abc78f58b86c398123
- https://git.kernel.org/stable/c/c373e49fbb87aa177819866ed9194ebc5414dfd6
Modified: 2026-01-14
CVE-2023-53275
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync() The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ]
- https://git.kernel.org/stable/c/109f0aaa0b8838a88af9125b79579023539300a7
- https://git.kernel.org/stable/c/1f4a08fed450db87fbb5ff5105354158bdbe1a22
- https://git.kernel.org/stable/c/8703b26387e1fa4f8749db98d24c67617b873acb
- https://git.kernel.org/stable/c/9f9eed451176ffcac6b5ba0f6dae1a6b4a1cb0eb
- https://git.kernel.org/stable/c/b32e40379e5b2814de0c4bc199edc2d82317dc07
- https://git.kernel.org/stable/c/cdd412b528dee6e0851c4735d6676ec138da13a4
Modified: 2026-01-14
CVE-2023-53276
In the Linux kernel, the following vulnerability has been resolved: ubifs: Free memory for tmpfile name When opening a ubifs tmpfile on an encrypted directory, function fscrypt_setup_filename allocates memory for the name that is to be stored in the directory entry, but after the name has been copied to the directory entry inode, the memory is not freed. When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program 'tmpfile' just opening a tmpfile: unreferenced object 0xffff88810178f380 (size 32): comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename ubifs_tmpfile vfs_tmpfile path_openat Free this memory after it has been copied to the inode.
- https://git.kernel.org/stable/c/107d481642c356a5668058066360fc473911e628
- https://git.kernel.org/stable/c/1e43d4284bdc3bd34bd770fea13910ac37ab0618
- https://git.kernel.org/stable/c/1fb815b38bb31d6af9bd0540b8652a0d6fe6cfd3
- https://git.kernel.org/stable/c/29738e1bcc799dd754711d4e4aab967f0c018175
- https://git.kernel.org/stable/c/823f554747f8aafaa965fb2f3ae794110ed429ef
- https://git.kernel.org/stable/c/8ad8c67a897e68426e85990ebfe0a7d1f71fc79f
- https://git.kernel.org/stable/c/b8f444a4fadfb5070ed7e298e0a5ceb4a18014f3
- https://git.kernel.org/stable/c/ce840284929b75dbbf062e0ce7fcb78a63b08b5e
- https://git.kernel.org/stable/c/fd197308c0e4f738c7ea687d5332035c5753881c
Modified: 2026-01-14
CVE-2023-53277
In the Linux kernel, the following vulnerability has been resolved: wifi: iwl3945: Add missing check for create_singlethread_workqueue Add the check for the return value of the create_singlethread_workqueue in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/17e07d6587c55015956862ef3b101fd45fa49fbc
- https://git.kernel.org/stable/c/1fdeb8b9f29dfd64805bb49475ac7566a3cb06cb
- https://git.kernel.org/stable/c/2f80b3ff92514ebd227e5c55d3d1e480401b02b7
- https://git.kernel.org/stable/c/34f611204ae589bd5c494b10b41fb13436bd3c3f
- https://git.kernel.org/stable/c/3ae2fc4de12686f3fe695824169c1272c9f798f7
- https://git.kernel.org/stable/c/505c74c4c0b1c5bcaa98a93b3087c268156070f1
- https://git.kernel.org/stable/c/7e594abc0424e4f8c2385f11aefeaadcfc507aa5
Modified: 2026-01-14
CVE-2023-53278
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix memory leak in ubifs_sysfs_init()
When insmod ubifs.ko, a kmemleak reported as below:
unreferenced object 0xffff88817fb1a780 (size 8):
comm "insmod", pid 25265, jiffies 4295239702 (age 100.130s)
hex dump (first 8 bytes):
75 62 69 66 73 00 ff ff ubifs...
backtrace:
[
Modified: 2026-01-14
CVE-2023-53279
In the Linux kernel, the following vulnerability has been resolved: misc: vmw_balloon: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53280
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue System crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_up gets called for uninitialized wait queue sp->nvme_ls_waitq. qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0 qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removed previously in the commits tagged Fixed: below.
- https://git.kernel.org/stable/c/0b1ce92fabdb7d02ddf8641230a06e2752ae5baa
- https://git.kernel.org/stable/c/20fce500b232b970e40312a9c97e7f3b6d7a709c
- https://git.kernel.org/stable/c/522ee1b3030f3b6b5fd59489d12b4ca767c9e5da
- https://git.kernel.org/stable/c/92529387a0066754fd9cda080fb3298b8cca750c
- https://git.kernel.org/stable/c/b7084ebf4f54d46fed5153112d685f4137334175
- https://git.kernel.org/stable/c/f459d586fdf12c53116c9fddf43065165fdd5969
Modified: 2026-01-14
CVE-2023-53281
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler()
Commit 041879b12ddb ("drivers: staging: rtl8192bs: Fix deadlock in
rtw_joinbss_event_prehandle()") besides fixing the deadlock also
modified _rtw_join_timeout_handler() to use spin_[un]lock_irq()
instead of spin_[un]lock_bh().
_rtw_join_timeout_handler() calls rtw_do_join() which takes
pmlmepriv->scanned_queue.lock using spin_[un]lock_bh(). This
spin_unlock_bh() call re-enables softirqs which triggers an oops in
kernel/softirq.c: __local_bh_enable_ip() when it calls
lockdep_assert_irqs_enabled():
[ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376 __local_bh_enable_ip+0xa6/0x100
...
[ 244.509022] Call Trace:
[ 244.509048]
- https://git.kernel.org/stable/c/209850f17717a3b5cc558578bef5631ac7045539
- https://git.kernel.org/stable/c/215792eda008f6a1e7ed9d77fa20d582d22bb114
- https://git.kernel.org/stable/c/2a50e44a66d268ee5db3d177f1fdc1503dbce6e7
- https://git.kernel.org/stable/c/4ab1bace1dd3875371b481ef4301c4671bddea22
- https://git.kernel.org/stable/c/dc327e87c6d9bfd9ee08e76396b3c0ba848ec554
Modified: 2026-01-14
CVE-2023-53282
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine: BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool. Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.
Modified: 2026-01-14
CVE-2023-53284
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for null return of devm_kzalloc() in dpu_writeback_init() Because of the possilble failure of devm_kzalloc(), dpu_wb_conn might be NULL and will cause null pointer dereference later. Therefore, it might be better to check it and directly return -ENOMEM. Patchwork: https://patchwork.freedesktop.org/patch/512277/ [DB: fixed typo in commit message]
Modified: 2026-01-14
CVE-2023-53285
In the Linux kernel, the following vulnerability has been resolved: ext4: add bounds checking in get_max_inline_xattr_value_size() Normally the extended attributes in the inode body would have been checked when the inode is first opened, but if someone is writing to the block device while the file system is mounted, it's possible for the inode table to get corrupted. Add bounds checking to avoid reading beyond the end of allocated memory if this happens.
- https://git.kernel.org/stable/c/1d2caddbeeee56fbbc36b428c5b909c3ad88eb7f
- https://git.kernel.org/stable/c/2220eaf90992c11d888fe771055d4de330385f01
- https://git.kernel.org/stable/c/3d7b8fbcd2273e2b9f4c6de5ce2f4c0cd3cb1205
- https://git.kernel.org/stable/c/4597554b4f7b29e7fd78aa449bab648f8da4ee2c
- https://git.kernel.org/stable/c/486efbbc9445dca7890a1b86adbccb88b91284b0
- https://git.kernel.org/stable/c/5a229d21b98d132673096710e8281ef522dab1d1
- https://git.kernel.org/stable/c/88a06a94942c5c0a896e9da1113a6bb29e36cbef
- https://git.kernel.org/stable/c/e780058bd75614b66882bc02620ddbd884171560
- https://git.kernel.org/stable/c/f22b274429e88d3dc7e79d375b56ce4f2f59f0b4
Modified: 2026-01-14
CVE-2023-53286
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Return the firmware result upon destroying QP/RQ
Previously when destroying a QP/RQ, the result of the firmware
destruction function was ignored and upper layers weren't informed
about the failure.
Which in turn could lead to various problems since when upper layer
isn't aware of the failure it continues its operation thinking that the
related QP/RQ was successfully destroyed while it actually wasn't,
which could lead to the below kernel WARN.
Currently, we return the correct firmware destruction status to upper
layers which in case of the RQ would be mlx5_ib_destroy_wq() which
was already capable of handling RQ destruction failure or in case of
a QP to destroy_qp_common(), which now would actually warn upon qp
destruction failure.
WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]
Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse
CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]
Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f
RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287
RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000
RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0
RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009
R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780
R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000
FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/04704c201bb08efaf96d7b1396c6864f8984e244
- https://git.kernel.org/stable/c/1a650d3ccd79cdd5796edd864683a6b8dd0bf576
- https://git.kernel.org/stable/c/22664c06e997087fe37f9ba208008c948571214a
- https://git.kernel.org/stable/c/5fe7815e784bf21061885f8112a7108aef5c45bd
- https://git.kernel.org/stable/c/73311dd831858d797cf8ebe140654ed519b41c36
Modified: 2026-01-14
CVE-2023-53287
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: Put the cdns set active part outside the spin lock The device may be scheduled during the resume process, so this cannot appear in atomic operations. Since pm_runtime_set_active will resume suppliers, put set active outside the spin lock, which is only used to protect the struct cdns data structure, otherwise the kernel will report the following warning: BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 PID: 651 Comm: sh Tainted: G WC 6.1.20 #1 Hardware name: Freescale i.MX8QM MEK (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x64/0x80 dump_stack+0x1c/0x38 __might_resched+0x1fc/0x240 __might_sleep+0x68/0xc0 __pm_runtime_resume+0x9c/0xe0 rpm_get_suppliers+0x68/0x1b0 __pm_runtime_set_status+0x298/0x560 cdns_resume+0xb0/0x1c0 cdns3_controller_resume.isra.0+0x1e0/0x250 cdns3_plat_resume+0x28/0x40
Modified: 2026-01-14
CVE-2023-53288
In the Linux kernel, the following vulnerability has been resolved: drm/client: Fix memory leak in drm_client_modeset_probe When a new mode is set to modeset->mode, the previous mode should be freed. This fixes the following kmemleak report: drm_mode_duplicate+0x45/0x220 [drm] drm_client_modeset_probe+0x944/0xf50 [drm] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper] drm_client_register+0x169/0x240 [drm] ast_pci_probe+0x142/0x190 [ast] local_pci_probe+0xdc/0x180 work_for_cpu_fn+0x4e/0xa0 process_one_work+0x8b7/0x1540 worker_thread+0x70a/0xed0 kthread+0x29f/0x340 ret_from_fork+0x1f/0x30
- https://git.kernel.org/stable/c/1369d0c586ad44f2d18fe2f4cbc5bcb24132fa71
- https://git.kernel.org/stable/c/2329cc7a101af1a844fbf706c0724c0baea38365
- https://git.kernel.org/stable/c/5d580017bdb9b3e930b6009e467e5e1589f8ca8a
- https://git.kernel.org/stable/c/5f2a12f64347f535c6ef55fa7eb36a2874d69b59
- https://git.kernel.org/stable/c/8108a494639e56aea77e7196a1d6ea89792b9d4a
- https://git.kernel.org/stable/c/917bef37cfaca07781c6fbaf6cd9404d27e64e6f
Modified: 2026-01-14
CVE-2023-53289
In the Linux kernel, the following vulnerability has been resolved: media: bdisp: Add missing check for create_workqueue Add the check for the return value of the create_workqueue in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/0d09ce05724cfb3f5c5136893bec95305c641875
- https://git.kernel.org/stable/c/2371adeab717d8fe32144a84f3491a03c5838cfb
- https://git.kernel.org/stable/c/2bfbe3ad371ac5349302833198df14e442622cbc
- https://git.kernel.org/stable/c/4362444dca02ab44ac844feda3cf6238ef953673
- https://git.kernel.org/stable/c/519b0849401194745ea40f9e07513b870afc1b42
- https://git.kernel.org/stable/c/c2e55481731b0e8c96f30f661e430aa884fbd354
- https://git.kernel.org/stable/c/c6a315f0b14074ac89723f55b749a557dda0ae2b
- https://git.kernel.org/stable/c/eef95a2745cb91559bb03aa111c228fe38deaf64
- https://git.kernel.org/stable/c/fc1aeafdf6fb0a136c2257000f0d478ee62953fe
Modified: 2026-01-14
CVE-2023-53290
In the Linux kernel, the following vulnerability has been resolved: samples/bpf: Fix fout leak in hbm's run_bpf_prog Fix fout being fopen'ed but then not subsequently fclose'd. In the affected branch, fout is otherwise going out of scope.
- https://git.kernel.org/stable/c/23acb14af1914010dd0aae1bbb7fab28bf518b8e
- https://git.kernel.org/stable/c/7560ed6592ff4077528c239c71e91b19de985b97
- https://git.kernel.org/stable/c/a7ec2f424f6edad34651137783a0a59eca9aa37e
- https://git.kernel.org/stable/c/e3e6e252d74f20f6fc610c7fef3ae7dda0109a6f
- https://git.kernel.org/stable/c/edf37bc8b03d3f948e679b2fd2d14464495f5d1b
- https://git.kernel.org/stable/c/f2065b8b0a215bc6aa061287a2e3d9eab2446422
Modified: 2026-01-14
CVE-2023-53291
In the Linux kernel, the following vulnerability has been resolved:
rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscale
Running the 'kfree_rcu_test' test case [1] results in a splat [2].
The root cause is the kfree_scale_thread thread(s) continue running
after unloading the rcuscale module. This commit fixes that isue by
invoking kfree_scale_cleanup() from rcu_scale_cleanup() when removing
the rcuscale module.
[1] modprobe rcuscale kfree_rcu_test=1
// After some time
rmmod rcuscale
rmmod torture
[2] BUG: unable to handle page fault for address: ffffffffc0601a87
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0010) - not-present page
PGD 11de4f067 P4D 11de4f067 PUD 11de51067 PMD 112f4d067 PTE 0
Oops: 0010 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 1798 Comm: kfree_scale_thr Not tainted 6.3.0-rc1-rcu+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
RIP: 0010:0xffffffffc0601a87
Code: Unable to access opcode bytes at 0xffffffffc0601a5d.
RSP: 0018:ffffb25bc2e57e18 EFLAGS: 00010297
RAX: 0000000000000000 RBX: ffffffffc061f0b6 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff962fd0de RDI: ffffffff962fd0de
RBP: ffffb25bc2e57ea8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
R13: 0000000000000000 R14: 000000000000000a R15: 00000000001c1dbe
FS: 0000000000000000(0000) GS:ffff921fa2200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffc0601a5d CR3: 000000011de4c006 CR4: 0000000000370ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1dd7547c7610723b2b6afe1a3c4ddb2bde63387c
- https://git.kernel.org/stable/c/23fc8df26dead16687ae6eb47b0561a4a832e2f6
- https://git.kernel.org/stable/c/29b1da4f90fc42c91beb4e400d926194925ad31b
- https://git.kernel.org/stable/c/604d6a5ff718874904b0fe614878a42b42c0d699
- https://git.kernel.org/stable/c/b8a6ba524d41f4da102e65f90498d9a910839621
- https://git.kernel.org/stable/c/f766d45ab294871a3d588ee76c666852f151cad9
Modified: 2026-01-14
CVE-2023-53294
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix null-ptr-deref on inode->i_op in ntfs_lookup()
Syzbot reported a null-ptr-deref bug:
ntfs3: loop0: Different NTFS' sector size (1024) and media sector size
(512)
ntfs3: loop0: Mark volume as dirty due to NTFS errors
general protection fault, probably for non-canonical address
0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline]
RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796
Call Trace:
- https://git.kernel.org/stable/c/254e69f284d7270e0abdc023ee53b71401c3ba0c
- https://git.kernel.org/stable/c/2ba22cbc6a1cf4b58195adbee0b80262e53992d3
- https://git.kernel.org/stable/c/d69d5e2a81df94534bdb468bcdd26060fcb7191a
- https://git.kernel.org/stable/c/e78240bc4b94fc42854d65e657bb998100cc8e1b
- https://git.kernel.org/stable/c/f8d9e062a695a3665c4635c4f216a75912687598
Modified: 2026-01-14
CVE-2023-53295
In the Linux kernel, the following vulnerability has been resolved: udf: Do not update file length for failed writes to inline files When write to inline file fails (or happens only partly), we still updated length of inline data as if the whole write succeeded. Fix the update of length of inline data to happen only if the write succeeds.
- https://git.kernel.org/stable/c/256fe4162f8b5a1625b8603ca5f7ff79725bfb47
- https://git.kernel.org/stable/c/5621f7a8139053d0c3c47fb68ee9f602139eb40a
- https://git.kernel.org/stable/c/5a6c373d761f55635e175fa2f407544bae8f583b
- https://git.kernel.org/stable/c/6837910aeb2c9101fc036dcd1b1f32615c20ec1a
- https://git.kernel.org/stable/c/6d18cedc1ef0caeb1567cab660079e48844ff6d6
- https://git.kernel.org/stable/c/7bd8d9e1cf5607ee14407f4060b9a1dbb3c42802
- https://git.kernel.org/stable/c/c5787d77a5c29fffd295d138bd118b334990a567
- https://git.kernel.org/stable/c/eb2133900cac2d2f78befd6be41666cf1a2315d9
Modified: 2026-01-14
CVE-2023-53296
In the Linux kernel, the following vulnerability has been resolved:
sctp: check send stream number after wait_for_sndbuf
This patch fixes a corner case where the asoc out stream count may change
after wait_for_sndbuf.
When the main thread in the client starts a connection, if its out stream
count is set to N while the in stream count in the server is set to N - 2,
another thread in the client keeps sending the msgs with stream number
N - 1, and waits for sndbuf before processing INIT_ACK.
However, after processing INIT_ACK, the out stream count in the client is
shrunk to N - 2, the same to the in stream count in the server. The crash
occurs when the thread waiting for sndbuf is awake and sends the msg in a
non-existing stream(N - 1), the call trace is as below:
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
Call Trace:
- https://git.kernel.org/stable/c/0443fff49d6352160c200064156c25898bd9f58c
- https://git.kernel.org/stable/c/2584024b23552c00d95b50255e47bd18d306d31a
- https://git.kernel.org/stable/c/667eb99cf7c15fe5b0ecefe75cf658e20ef20c9f
- https://git.kernel.org/stable/c/9346a1a21142357972a6f466ba6275ddc54b04ac
- https://git.kernel.org/stable/c/a615e7270318fa0b98bf1ff38daf6cf52d840312
- https://git.kernel.org/stable/c/b4b6dfad41aaae9e36e44327b18d5cf4b20dd2ce
- https://git.kernel.org/stable/c/d2128636b303aa9cf065055402ee6697409a8837
Modified: 2026-01-14
CVE-2023-53297
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix "bad unlock balance" in l2cap_disconnect_rsp conn->chan_lock isn't acquired before l2cap_get_chan_by_scid, if l2cap_get_chan_by_scid returns NULL, then 'bad unlock balance' is triggered.
- https://git.kernel.org/stable/c/116b9c002c894097adc2b8684db2d1da4229ed46
- https://git.kernel.org/stable/c/2112c4c47d36bc5aba3ddeb9afedce6ae6a67e7d
- https://git.kernel.org/stable/c/25e97f7b1866e6b8503be349eeea44bb52d661ce
- https://git.kernel.org/stable/c/5134556c9be582793f30695c09d18a26fe1ff2d7
- https://git.kernel.org/stable/c/55410a9144c76ecda126e6cdec556dfcd8f343b2
- https://git.kernel.org/stable/c/5f352a56f0e607e6ff539cbf12156bfd8af232be
- https://git.kernel.org/stable/c/6a27762340ad08643de3bc17fe1646ea489ca2e2
- https://git.kernel.org/stable/c/fd269a0435f8e9943b7a57c5a59688848d42d449
Modified: 2026-01-14
CVE-2023-53298
In the Linux kernel, the following vulnerability has been resolved: nfc: fix memory leak of se_io context in nfc_genl_se_io The callback context for sending/receiving APDUs to/from the selected secure element is allocated inside nfc_genl_se_io and supposed to be eventually freed in se_io_cb callback function. However, there are several error paths where the bwi_timer is not charged to call se_io_cb later, and the cb_context is leaked. The patch proposes to free the cb_context explicitly on those error paths. At the moment we can't simply check 'dev->ops->se_io()' return value as it may be negative in both cases: when the timer was charged and was not.
- https://git.kernel.org/stable/c/25ff6f8a5a3b8dc48e8abda6f013e8cc4b14ffea
- https://git.kernel.org/stable/c/271eed1736426103335c5aac50f15b0f4d236bc0
- https://git.kernel.org/stable/c/5321da6d84b87a34eea441677d649c34bd854169
- https://git.kernel.org/stable/c/8978315cb4bf8878c9c8ec05dafd8f7ff539860d
- https://git.kernel.org/stable/c/af452e35b9e6a87cd49e54a7a3d60d934b194651
- https://git.kernel.org/stable/c/b2036a252381949d3b743a3de069324ae3028a57
- https://git.kernel.org/stable/c/ba98db08895748c12e5ded52cd1598dce2c79e55
- https://git.kernel.org/stable/c/c494365432dcdc549986f4d9af9eb6190cbdb153
Modified: 2026-01-14
CVE-2023-53299
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix leak of 'r10bio->remaining' for recovery raid10_sync_request() will add 'r10bio->remaining' for both rdev and replacement rdev. However, if the read io fails, recovery_request_write() returns without issuing the write io, in this case, end_sync_request() is only called once and 'remaining' is leaked, cause an io hang. Fix the problem by decreasing 'remaining' according to if 'bio' and 'repl_bio' is valid.
- https://git.kernel.org/stable/c/11141630f03efffdfe260b3582b2d93d38171b97
- https://git.kernel.org/stable/c/1697fb124c6d6c5237e9cbd78890310154738084
- https://git.kernel.org/stable/c/1d2c6c6e37fe5de11fd01a82badf03390e12df7a
- https://git.kernel.org/stable/c/26208a7cffd0c7cbf14237ccd20c7270b3ffeb7e
- https://git.kernel.org/stable/c/3481dec5ecbbbbe44ab23e22c2b14bd65c644ec6
- https://git.kernel.org/stable/c/4f82e7e07cdaf2947d71968e3d6b73370a217093
- https://git.kernel.org/stable/c/8c5d5d7ffd1e76734811b8ea5417cf0432b9952c
- https://git.kernel.org/stable/c/8d09065802c53cc938d162b62f6c4150b392c90e
- https://git.kernel.org/stable/c/cb827ed2bb34480dc102146d3a1f89fdbcafc028
Modified: 2026-01-14
CVE-2023-53300
In the Linux kernel, the following vulnerability has been resolved: media: hi846: Fix memleak in hi846_init_controls() hi846_init_controls doesn't clean the allocated ctrl_hdlr in case there is a failure, which causes memleak. Add v4l2_ctrl_handler_free to free the resource properly.
Modified: 2026-03-17
CVE-2023-53301
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix kernel crash due to null io->bio
We should return when io->bio is null before doing anything. Otherwise, panic.
BUG: kernel NULL pointer dereference, address: 0000000000000010
RIP: 0010:__submit_merged_write_cond+0x164/0x240 [f2fs]
Call Trace:
Modified: 2026-01-14
CVE-2023-53302
In the Linux kernel, the following vulnerability has been resolved: wifi: iwl4965: Add missing check for create_singlethread_workqueue() Add the check for the return value of the create_singlethread_workqueue() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/26e6775f75517ad6844fe5b79bc5f3fa8c22ee61
- https://git.kernel.org/stable/c/2f85c768bea2057e3299d19514da9e932c4f92d2
- https://git.kernel.org/stable/c/3185d6cfc59277a77bf311dce701b7e25193f66a
- https://git.kernel.org/stable/c/874a85051cc8df8c5b928d8ff172b342cdc5424b
- https://git.kernel.org/stable/c/878a7c8357764e08bc778bcb26127fc12a4b36b7
- https://git.kernel.org/stable/c/c002d2741400771171b68dde9af937a4dfa0d1b3
- https://git.kernel.org/stable/c/f15ef0ebcf56be1d4a3c9a7a80a1f1f82ab0eaad
Modified: 2026-01-14
CVE-2023-53305
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix use-after-free Fix potential use-after-free in l2cap_le_command_rej.
- https://git.kernel.org/stable/c/149daab45922ab1ac7f0cbeacab7251a46bf5e63
- https://git.kernel.org/stable/c/1a40c56e8bff3e424724d78a9a6b3272dd8a371d
- https://git.kernel.org/stable/c/255be68150291440657b2cdb09420b69441af3d8
- https://git.kernel.org/stable/c/2958cf9f805b9f0bdc4a761bf6ea281eb8d44f8e
- https://git.kernel.org/stable/c/548a6b64b3c0688f01119a6fcccceb41f8c984e4
- https://git.kernel.org/stable/c/e76bab1b7afa580cd76362540fc37551ada4359b
- https://git.kernel.org/stable/c/f752a0b334bb95fe9b42ecb511e0864e2768046f
- https://git.kernel.org/stable/c/fe49aa73cca6608714477b74bfc6874b9db979df
Modified: 2026-01-14
CVE-2023-53307
In the Linux kernel, the following vulnerability has been resolved:
rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails
If getting an ID or setting up a work queue in rbd_dev_create() fails,
use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts
is triggered in do_rbd_add(). The root cause is that the ownership of
these structures is transfered to rbd_dev prematurely and they all end
up getting freed when rbd_dev_create() calls rbd_dev_free() prior to
returning to do_rbd_add().
Found by Linux Verification Center (linuxtesting.org) with SVACE, an
incomplete patch submitted by Natalia Petrova
- https://git.kernel.org/stable/c/71da2a151ed1adb0aea4252b16d81b53012e7afd
- https://git.kernel.org/stable/c/9787b328c42c13c4f31e7d5042c4e877e9344068
- https://git.kernel.org/stable/c/a73783e4e0c4d1507794da211eeca75498544dff
- https://git.kernel.org/stable/c/ae16346078b1189aee934afd872d9f3d0a682c33
- https://git.kernel.org/stable/c/cc8c0dd2984503ed09efa37bcafcef3d3da104e8
- https://git.kernel.org/stable/c/e3cbb4d60764295992c95344f2d779439e8b34ce
- https://git.kernel.org/stable/c/f7c4d9b133c7a04ca619355574e96b6abf209fba
- https://git.kernel.org/stable/c/faa7b683e436664fff5648426950718277831348
Modified: 2026-01-14
CVE-2023-53308
In the Linux kernel, the following vulnerability has been resolved: net: fec: Better handle pm_runtime_get() failing in .remove() In the (unlikely) event that pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, the remove callback returned an error early. The problem with this is that the driver core ignores the error value and continues removing the device. This results in a resource leak. Worse the devm allocated resources are freed and so if a callback of the driver is called later the register mapping is already gone which probably results in a crash.
- https://git.kernel.org/stable/c/83996d317b1deddc85006376082e8886f55aa709
- https://git.kernel.org/stable/c/9407454a9b18bbeff216e8ecde87ffb2171e9ccf
- https://git.kernel.org/stable/c/b22b514209ff8c4287abb853399890ab97e1b5ca
- https://git.kernel.org/stable/c/be85912c36ddca3e8b2eef1b5392cd8db6bdb730
- https://git.kernel.org/stable/c/c1bc2870f14e526a01897e14c747a0a0ca125231
- https://git.kernel.org/stable/c/d52a0cca591e899d4e5c8ab19e067b4c6b7d104f
- https://git.kernel.org/stable/c/e02d8d5b1602689b98d9b91550a11b9b57baedbe
- https://git.kernel.org/stable/c/f816b9829b19394d318e01953aa3b2721bca040d
Modified: 2026-01-14
CVE-2023-53309
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix integer overflow in radeon_cs_parser_init The type of size is unsigned, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later
- https://git.kernel.org/stable/c/25e634d7f44eb13113139040e5366bebe48c882f
- https://git.kernel.org/stable/c/2e1be420b86980c25a75325e90dfc3fc73126f61
- https://git.kernel.org/stable/c/b8fab6aebdf2115ec2d7bd2f3498d5b911ff351e
- https://git.kernel.org/stable/c/c0d7dbc6b7a61a56028118c00af2c8319d44a682
- https://git.kernel.org/stable/c/cfa9148bafb2d3292b65de1bac79dcca65be2643
- https://git.kernel.org/stable/c/d05ba46134d07e889de7d23cf8503574a22ede09
- https://git.kernel.org/stable/c/e6825b30d37fe89ceb87f926d33d4fad321a331e
- https://git.kernel.org/stable/c/f828b681d0cd566f86351c0b913e6cb6ed8c7b9c
Modified: 2026-01-14
CVE-2023-53310
In the Linux kernel, the following vulnerability has been resolved: power: supply: axp288_fuel_gauge: Fix external_power_changed race fuel_gauge_external_power_changed() dereferences info->bat, which gets sets in axp288_fuel_gauge_probe() like this: info->bat = devm_power_supply_register(dev, &fuel_gauge_desc, &psy_cfg); As soon as devm_power_supply_register() has called device_add() the external_power_changed callback can get called. So there is a window where fuel_gauge_external_power_changed() may get called while info->bat has not been set yet leading to a NULL pointer dereference. Fixing this is easy. The external_power_changed callback gets passed the power_supply which will eventually get stored in info->bat, so fuel_gauge_external_power_changed() can simply directly use the passed in psy argument which is always valid.
Modified: 2026-01-14
CVE-2023-53311
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput During unmount process of nilfs2, nothing holds nilfs_root structure after nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously, nilfs_evict_inode() could cause use-after-free read for nilfs_root if inodes are left in "garbage_list" and released by nilfs_dispose_list at the end of nilfs_detach_log_writer(), and this bug was fixed by commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()"). However, it turned out that there is another possibility of UAF in the call path where mark_inode_dirty_sync() is called from iput(): nilfs_detach_log_writer() nilfs_dispose_list() iput() mark_inode_dirty_sync() __mark_inode_dirty() nilfs_dirty_inode() __nilfs_mark_inode_dirty() nilfs_load_inode_block() --> causes UAF of nilfs_root struct This can happen after commit 0ae45f63d4ef ("vfs: add support for a lazytime mount option"), which changed iput() to call mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME flag and i_nlink is non-zero. This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only") when using the syzbot reproducer, but the issue has potentially existed before. Fix this issue by adding a "purging flag" to the nilfs structure, setting that flag while disposing the "garbage_list" and checking it in __nilfs_mark_inode_dirty(). Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()"), this patch does not rely on ns_writer to determine whether to skip operations, so as not to break recovery on mount. The nilfs_salvage_orphan_logs routine dirties the buffer of salvaged data before attaching the log writer, so changing __nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL will cause recovery write to fail. The purpose of using the cleanup-only flag is to allow for narrowing of such conditions.
- https://git.kernel.org/stable/c/11afd67f1b3c28eb216e50a3ca8dbcb69bb71793
- https://git.kernel.org/stable/c/3645510cf926e6af2f4d44899370d7e5331c93bd
- https://git.kernel.org/stable/c/37207240872456fbab44a110bde6640445233963
- https://git.kernel.org/stable/c/5828d5f5dc877dcfdd7b23102e978e2ecfd86d82
- https://git.kernel.org/stable/c/7532ff6edbf5242376b24a95a2fefb59bb653e5a
- https://git.kernel.org/stable/c/a3c3b4cbf9b8554120fb230e6516e980c6277487
- https://git.kernel.org/stable/c/d2c539c216cce74837a9cf5804eb205939b82227
- https://git.kernel.org/stable/c/f8654743a0e6909dc634cbfad6db6816f10f3399
Modified: 2026-01-14
CVE-2023-53312
In the Linux kernel, the following vulnerability has been resolved:
net: fix net_dev_start_xmit trace event vs skb_transport_offset()
After blamed commit, we must be more careful about using
skb_transport_offset(), as reminded us by syzbot:
WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline]
WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14
Modules linked in:
CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
RIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline]
RIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline]
RIP: 0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14
Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd <0f> 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff
RSP: 0018:ffffc900002bf700 EFLAGS: 00010293
RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280
RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff
RBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67
R13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0
Call Trace:
Modified: 2026-01-14
CVE-2023-53313
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix wrong setting of max_corr_read_errors There is no input check when echo md/max_read_errors and overflow might occur. Add check of input number.
- https://git.kernel.org/stable/c/025fde32fb957a5c271711bc66841f817ff5f299
- https://git.kernel.org/stable/c/05d10428e8dffed0bac2502f34151729fc189cd3
- https://git.kernel.org/stable/c/31c805a44b7569ca1017a4714385182d98bba212
- https://git.kernel.org/stable/c/3c76920e547d4b931bed758bad83fd658dd88b4e
- https://git.kernel.org/stable/c/74050a3fdd4aecfd2cbf74d3c145812ab2744375
- https://git.kernel.org/stable/c/aef6e98eb772594edd4399625e4e1bbe45971fa1
- https://git.kernel.org/stable/c/b1d8f38310bce3282374983b229d94edbaf1e570
- https://git.kernel.org/stable/c/e83cb411aa1c6c9617db9329897f4506ba9e9b9d
- https://git.kernel.org/stable/c/f8b20a405428803bd9881881d8242c9d72c6b2b2
Modified: 2026-01-14
CVE-2023-53314
In the Linux kernel, the following vulnerability has been resolved: fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Do not assing the Linux device to struct fb_info.dev. The call to register_framebuffer() initializes the field to the fbdev device. Drivers should not override its value. Fixes a bug where the driver incorrectly decreases the hardware device's reference counter and leaks the fbdev device. v2: * add Fixes tag (Dan)
- https://git.kernel.org/stable/c/0517fc5a71333b315164736bbd32608894fbb872
- https://git.kernel.org/stable/c/1c6ff2a7c593db851f23e31ace2baf557ea9d0ff
- https://git.kernel.org/stable/c/309c27162afea79b3c7f8747bb650faf6923b639
- https://git.kernel.org/stable/c/4aade6c9100a3537788b6a9c7ac481037d19efdf
- https://git.kernel.org/stable/c/8ffa40ff64aa43a9a28fcf209b48d86a3e0f4972
- https://git.kernel.org/stable/c/f83c1b13f8154e0284448912756d0a351a1a602a
- https://git.kernel.org/stable/c/f90a0e5265b60cdd3c77990e8105f79aa2fac994
- https://git.kernel.org/stable/c/ffdf2b020db717853167391a3a8d912e13428fa6
Modified: 2026-01-14
CVE-2023-53315
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Fix SKB corruption in REO destination ring While running traffics for a long time, randomly an RX descriptor filled with value "0" from REO destination ring is received. This descriptor which is invalid causes the wrong SKB (SKB stored in the IDR lookup with buffer id "0") to be fetched which in turn causes SKB memory corruption issue and the same leads to crash after some time. Changed the start id for idr allocation to "1" and the buffer id "0" is reserved for error validation. Introduced Sanity check to validate the descriptor, before processing the SKB. Crash Signature : Unable to handle kernel paging request at virtual address 3f004900 PC points to "b15_dma_inv_range+0x30/0x50" LR points to "dma_cache_maint_page+0x8c/0x128". The Backtrace obtained is as follows: [<8031716c>] (b15_dma_inv_range) from [<80313a4c>] (dma_cache_maint_page+0x8c/0x128) [<80313a4c>] (dma_cache_maint_page) from [<80313b90>] (__dma_page_dev_to_cpu+0x28/0xcc) [<80313b90>] (__dma_page_dev_to_cpu) from [<7fb5dd68>] (ath11k_dp_process_rx+0x1e8/0x4a4 [ath11k]) [<7fb5dd68>] (ath11k_dp_process_rx [ath11k]) from [<7fb53c20>] (ath11k_dp_service_srng+0xb0/0x2ac [ath11k]) [<7fb53c20>] (ath11k_dp_service_srng [ath11k]) from [<7f67bba4>] (ath11k_pci_ext_grp_napi_poll+0x1c/0x78 [ath11k_pci]) [<7f67bba4>] (ath11k_pci_ext_grp_napi_poll [ath11k_pci]) from [<807d5cf4>] (__napi_poll+0x28/0xb8) [<807d5cf4>] (__napi_poll) from [<807d5f28>] (net_rx_action+0xf0/0x280) [<807d5f28>] (net_rx_action) from [<80302148>] (__do_softirq+0xd0/0x280) [<80302148>] (__do_softirq) from [<80320408>] (irq_exit+0x74/0xd4) [<80320408>] (irq_exit) from [<803638a4>] (__handle_domain_irq+0x90/0xb4) [<803638a4>] (__handle_domain_irq) from [<805bedec>] (gic_handle_irq+0x58/0x90) [<805bedec>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
- https://git.kernel.org/stable/c/068fd06148fbf0af95bb08dc77cff34ee679fdbc
- https://git.kernel.org/stable/c/3d3f8fe01a01d94a17fe1ae0d2e894049a972717
- https://git.kernel.org/stable/c/67459491f78146bcf7d93596e5b709d063dff5d8
- https://git.kernel.org/stable/c/866921dc06b94df91acfcf9359b57da943ed99b3
- https://git.kernel.org/stable/c/f9fff67d2d7ca6fa8066132003a3deef654c55b1
Modified: 2026-01-14
CVE-2023-53316
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: Free resources after unregistering them The DP component's unbind operation walks through the submodules to unregister and clean things up. But if the unbind happens because the DP controller itself is being removed, all the memory for those submodules has just been freed. Change the order of these operations to avoid the many use-after-free that otherwise happens in this code path. Patchwork: https://patchwork.freedesktop.org/patch/542166/
- https://git.kernel.org/stable/c/3c3f3d35f5e05c468b048eb42a4f8c62c6655692
- https://git.kernel.org/stable/c/4e9f1a2367aea7d61f6781213e25313cd983b0d7
- https://git.kernel.org/stable/c/5c3278db06e332fdc14f3f297499fb88ded264d2
- https://git.kernel.org/stable/c/c67a55f7cc8d767d624235bf1bcd0947e56abe0f
- https://git.kernel.org/stable/c/ca47d0dc00968358c136a1847cfed550cedfd1b5
- https://git.kernel.org/stable/c/fa0048a4b1fa7a50c8b0e514f5b428abdf69a6f8
Modified: 2026-01-14
CVE-2023-53317
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in mb_find_extent
Syzbot found the following issue:
EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
EXT4-fs (loop0): orphan cleanup on readonly fs
------------[ cut here ]------------
WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30
Modules linked in:
CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869
RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293
RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0
RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040
RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402
R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000
R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc
FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1b90fbc7590124c57a2e590de7fd07eba26606f1
- https://git.kernel.org/stable/c/5d356d902e9d5b1aaaaf2326d365340fa8a90c1b
- https://git.kernel.org/stable/c/775b00ba23f6f916fe2ac60c5ff7fd0fe4f28d0d
- https://git.kernel.org/stable/c/d55e76e11592a1d18a179c7fd34ca1b52632beb3
- https://git.kernel.org/stable/c/dba62fa84a8eac44a53a2862de8a40e5bdfa0ae3
- https://git.kernel.org/stable/c/dd45e536f47a82e0a405f9a4b6c7ceb367171ee9
- https://git.kernel.org/stable/c/e4d503c956a744cb59e509ca5f134cfad423c7a3
- https://git.kernel.org/stable/c/fa08a7b61dff8a4df11ff1e84abfc214b487caf7
Modified: 2026-01-14
CVE-2023-53318
In the Linux kernel, the following vulnerability has been resolved: recordmcount: Fix memory leaks in the uwrite function Common realloc mistake: 'file_append' nulled but not freed upon failure
- https://git.kernel.org/stable/c/25c9b185f121812cbc215fdaa1192c6b9025b428
- https://git.kernel.org/stable/c/2d9ca5f62f2ba160ff9c9be4adf401c46c04edef
- https://git.kernel.org/stable/c/3ed95a6f6c646e8bb15c354536e0ab10e8f39c08
- https://git.kernel.org/stable/c/444ec005404cead222ebce2561a9451c9ee5ad89
- https://git.kernel.org/stable/c/895130e63c93926f07caf5db286b97bd27b81de9
- https://git.kernel.org/stable/c/bd39f68a309a947670379bf9a39b16c584f86ddb
- https://git.kernel.org/stable/c/fa359d068574d29e7d2f0fdd0ebe4c6a12b5cfb9
- https://git.kernel.org/stable/c/ff70ad9159fbb566b2c15724f44207e8deccd527
Modified: 2026-01-14
CVE-2023-53320
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes "BUG: KASAN: slab-out-of-bounds". Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer().
Modified: 2026-01-14
CVE-2023-53321
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: drop short frames While technically some control frames like ACK are shorter and end after Address 1, such frames shouldn't be forwarded through wmediumd or similar userspace, so require the full 3-address header to avoid accessing invalid memory if shorter frames are passed in.
- https://git.kernel.org/stable/c/3beb97bed860d95b14ad23578ce8ddaea62023db
- https://git.kernel.org/stable/c/672205c6f2d11978fcd7f0f336bb2c708e28874b
- https://git.kernel.org/stable/c/89a41ed7f21476301659ebd25ccb48a60791c1a7
- https://git.kernel.org/stable/c/b9a175e3b250b0dc6e152988040aa5014e98e61e
- https://git.kernel.org/stable/c/c64ee9dd335832d5e2ab0a8fc83a34ad4c729799
- https://git.kernel.org/stable/c/fba360a047d5eeeb9d4b7c3a9b1c8308980ce9a6
Modified: 2026-01-14
CVE-2023-53322
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Wait for io return on terminate rport System crash due to use after free. Current code allows terminate_rport_io to exit before making sure all IOs has returned. For FCP-2 device, IO's can hang on in HW because driver has not tear down the session in FW at first sign of cable pull. When dev_loss_tmo timer pops, terminate_rport_io is called and upper layer is about to free various resources. Terminate_rport_io trigger qla to do the final cleanup, but the cleanup might not be fast enough where it leave qla still holding on to the same resource. Wait for IO's to return to upper layer before resources are freed.
- https://git.kernel.org/stable/c/079c8264ed9fea8cbcac01ad29040f901cbc3692
- https://git.kernel.org/stable/c/4647d2e88918a078359d1532d90c417a38542c9e
- https://git.kernel.org/stable/c/5bcdaafd92be6035ddc77fa76650cf9dd5b864c4
- https://git.kernel.org/stable/c/8a55556cd7e0220486163b1285ce11a8be2ce5fa
- https://git.kernel.org/stable/c/90770dad1eb30967ebd8d37d82830bcf270b3293
- https://git.kernel.org/stable/c/a9fe97fb7b4ee21bffb76f2acb05769bad27ae70
- https://git.kernel.org/stable/c/d25fded78d88e1515439b3ba581684d683e0b6ab
- https://git.kernel.org/stable/c/fc0cba0c7be8261a1625098bd1d695077ec621c9
Modified: 2026-01-14
CVE-2023-53323
In the Linux kernel, the following vulnerability has been resolved:
ext2/dax: Fix ext2_setsize when len is page aligned
PAGE_ALIGN(x) macro gives the next highest value which is multiple of
pagesize. But if x is already page aligned then it simply returns x.
So, if x passed is 0 in dax_zero_range() function, that means the
length gets passed as 0 to ->iomap_begin().
In ext2 it then calls ext2_get_blocks -> max_blocks as 0 and hits bug_on
here in ext2_get_blocks().
BUG_ON(maxblocks == 0);
Instead we should be calling dax_truncate_page() here which takes
care of it. i.e. it only calls dax_zero_range if the offset is not
page/block aligned.
This can be easily triggered with following on fsdax mounted pmem
device.
dd if=/dev/zero of=file count=1 bs=512
truncate -s 0 file
[79.525838] EXT2-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk
[79.529376] ext2 filesystem being mounted at /mnt1/test supports timestamps until 2038 (0x7fffffff)
[93.793207] ------------[ cut here ]------------
[93.795102] kernel BUG at fs/ext2/inode.c:637!
[93.796904] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[93.798659] CPU: 0 PID: 1192 Comm: truncate Not tainted 6.3.0-rc2-xfstests-00056-g131086faa369 #139
[93.806459] RIP: 0010:ext2_get_blocks.constprop.0+0x524/0x610
<...>
[93.835298] Call Trace:
[93.836253]
Modified: 2026-01-14
CVE-2023-53324
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Don't leak some plane state Apparently no one noticed that mdp5 plane states leak like a sieve ever since we introduced plane_state->commit refcount a few years ago in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.") Fix it by using the right helpers. Patchwork: https://patchwork.freedesktop.org/patch/551236/
- https://git.kernel.org/stable/c/12dfd02cbd1a678fbd66be0c2f79d5299c4921a9
- https://git.kernel.org/stable/c/2965015006ef18ca96d2eab9ebe6bca884c63291
- https://git.kernel.org/stable/c/5b0dd3a102f64996598bd1e8d8388848a7c561bc
- https://git.kernel.org/stable/c/7fc11a830b2eb07a0e3c6f917e5e636df6fc5d4c
- https://git.kernel.org/stable/c/815e42029f6e1e762898079f85546d6a0391ab95
- https://git.kernel.org/stable/c/b8a61df6f40448cf46611f7af05b00970d08d620
- https://git.kernel.org/stable/c/c0b1eee648702e04f1005d451f9689575b7f52ed
- https://git.kernel.org/stable/c/fd0ad3b2365c1c58aa5a761c18efc4817193beb6
Modified: 2026-01-14
CVE-2023-53325
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() Change logging from drm_{err,info}() to dev_{err,info}() in functions mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be essential to avoid getting NULL pointer kernel panics if any kind of error happens during AUX transfers happening before the bridge is attached. This may potentially start happening in a later commit implementing aux-bus support, as AUX transfers will be triggered from the panel driver (for EDID) before the mtk-dp bridge gets attached, and it's done in preparation for the same.
Modified: 2026-01-14
CVE-2023-53326
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Don't try to copy PPR for task with NULL pt_regs
powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
from my (arguably very short) checking is not commonly done for other
archs. This is fine, except when PF_IO_WORKER's have been created and
the task does something that causes a coredump to be generated. Then we
get this crash:
Kernel attempted to read user page (160) - exploit attempt? (uid: 1000)
BUG: Kernel NULL pointer dereference on read at 0x00000160
Faulting instruction address: 0xc0000000000c3a60
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries
Modules linked in: bochs drm_vram_helper drm_kms_helper xts binfmt_misc ecb ctr syscopyarea sysfillrect cbc sysimgblt drm_ttm_helper aes_generic ttm sg libaes evdev joydev virtio_balloon vmx_crypto gf128mul drm dm_mod fuse loop configfs drm_panel_orientation_quirks ip_tables x_tables autofs4 hid_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod
CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+ #88
Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
NIP: c0000000000c3a60 LR: c000000000039944 CTR: c0000000000398e0
REGS: c0000000041833b0 TRAP: 0300 Not tainted (6.3.0-rc2+)
MSR: 800000000280b033
- https://git.kernel.org/stable/c/01849382373b867ddcbe7536b9dfa89f3bcea60e
- https://git.kernel.org/stable/c/064a1c7b0f8403260d77627e62424a72ca26cee2
- https://git.kernel.org/stable/c/7624973bc15b76d000e8e6f9b8080fcb76d36595
- https://git.kernel.org/stable/c/80a4200d51e5a7e046f4a90f5faa5bafd5a60c58
- https://git.kernel.org/stable/c/fd7276189450110ed835eb0a334e62d2f1c4e3be
Modified: 2026-01-14
CVE-2023-53328
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Enhance sanity check while generating attr_list
ni_create_attr_list uses WARN_ON to catch error cases while generating
attribute list, which only prints out stack trace and may not be enough.
This repalces them with more proper error handling flow.
[ 59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e
[ 59.673268] #PF: supervisor read access in kernel mode
[ 59.678354] #PF: error_code(0x0000) - not-present page
[ 59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0
[ 59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI
[ 59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G B W 6.2.0-rc1+ #4
[ 59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[ 59.708795] RIP: 0010:ni_create_attr_list+0x505/0x860
[ 59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8
[ 59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282
[ 59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe
[ 59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0
[ 59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9
[ 59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180
[ 59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050
[ 59.768323] FS: 00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000
[ 59.776027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0
[ 59.787607] Call Trace:
[ 59.790271]
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-01-14
CVE-2023-53331
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Check start of empty przs during init After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as valid"), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to: sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ... To avoid this, also check if the prz start is 0 during the initialization phase. If not, the next prz sanity check case will discover it (start > size) and zap the buffer back to a sane state. [kees: update commit log with backtrace and clarifications]
- https://git.kernel.org/stable/c/25fb4e3402d46f425ec135ef6f09792a4c1b3003
- https://git.kernel.org/stable/c/89312657337e6e03ad6e9ea1a462bd9c158c85c8
- https://git.kernel.org/stable/c/c807ccdd812d18985860504b503899f3140a9549
- https://git.kernel.org/stable/c/dc2f60de9a7d3efd982440117dab5579898d808c
- https://git.kernel.org/stable/c/e95d7a8a6edd14f8fab44c777dd7281db91f6ae2
- https://git.kernel.org/stable/c/e972231db29b5d1dccc13bf9d5ba55b6979a69ed
- https://git.kernel.org/stable/c/f77990358628b01bdc03752126ff5f716ea37615
- https://git.kernel.org/stable/c/fe8c3623ab06603eb760444a032d426542212021
- https://git.kernel.org/stable/c/fedecaeef88899d940b69368c996e8b3b0b8650d
Modified: 2026-01-14
CVE-2023-53332
In the Linux kernel, the following vulnerability has been resolved: genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask() If ipi_send_{mask|single}() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does verify its 'data' parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Add a missing NULL pointer check in ipi_send_verify()... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
Modified: 2026-01-14
CVE-2023-53333
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one Eric Dumazet says: nf_conntrack_dccp_packet() has an unique: dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); And nothing more is 'pulled' from the packet, depending on the content. dh->dccph_doff, and/or dh->dccph_x ...) So dccp_ack_seq() is happily reading stuff past the _dh buffer. BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0 Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371 [..] Fix this by increasing the stack buffer to also include room for the extra sequence numbers and all the known dccp packet type headers, then pull again after the initial validation of the basic header. While at it, mark packets invalid that lack 48bit sequence bit but where RFC says the type MUST use them. Compile tested only. v2: first skb_header_pointer() now needs to adjust the size to only pull the generic header. (Eric) Heads-up: I intend to remove dccp conntrack support later this year.
- https://git.kernel.org/stable/c/26bd1f210d3783a691052c51d76bb8a8bbd24c67
- https://git.kernel.org/stable/c/337fdce450637ea663bc816edc2ba81e5cdad02e
- https://git.kernel.org/stable/c/5c618daa5038712c4a4ef8923905a2ea1b8836a1
- https://git.kernel.org/stable/c/8c0980493beed3a80d6329c44ab293dc8c032927
- https://git.kernel.org/stable/c/9bdcda7abaf22f6453e5b5efb7eb4e524095d5d8
- https://git.kernel.org/stable/c/c052797ac36813419ad3bfa54cb8615db4b41f15
- https://git.kernel.org/stable/c/ff0a3a7d52ff7282dbd183e7fc29a1fe386b0c30
Modified: 2026-01-14
CVE-2023-53334
In the Linux kernel, the following vulnerability has been resolved: USB: chipidea: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53335
In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish() If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is dereferenced later regardless of whether it is empty. This patch adds a simple sanity check to fix the issue. Found by Linux Verification Center (linuxtesting.org) with SVACE.
Modified: 2026-01-14
CVE-2023-53337
In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not write dirty data after degenerating to read-only According to syzbot's report, mark_buffer_dirty() called from nilfs_segctor_do_construct() outputs a warning with some patterns after nilfs2 detects metadata corruption and degrades to read-only mode. After such read-only degeneration, page cache data may be cleared through nilfs_clear_dirty_page() which may also clear the uptodate flag for their buffer heads. However, even after the degeneration, log writes are still performed by unmount processing etc., which causes mark_buffer_dirty() to be called for buffer heads without the "uptodate" flag and causes the warning. Since any writes should not be done to a read-only file system in the first place, this fixes the warning in mark_buffer_dirty() by letting nilfs_segctor_do_construct() abort early if in read-only mode. This also changes the retry check of nilfs_segctor_write_out() to avoid unnecessary log write retries if it detects -EROFS that nilfs_segctor_do_construct() returned.
- https://git.kernel.org/stable/c/13f73ef77baa4764dc1ca4fcbae9cade05b83866
- https://git.kernel.org/stable/c/28a65b49eb53e172d23567005465019658bfdb4d
- https://git.kernel.org/stable/c/4005cec6847c06ee191583270b7cdd7e696543cc
- https://git.kernel.org/stable/c/4569a292a84e340e97d178898ad1cfe1a3080a61
- https://git.kernel.org/stable/c/55f7810632f993cff622a0ddbc7c865892294b61
- https://git.kernel.org/stable/c/7c3e662048053802f6b0db3a78e97f4e1f7edc4f
- https://git.kernel.org/stable/c/a73201c607d8e506358d60aafddda4246bdd9350
- https://git.kernel.org/stable/c/bd89073fc7a5d03b1d06b372addbe405e5a925f4
- https://git.kernel.org/stable/c/e9c5412c5972124776c1b873533eb39e287a4dfa
Modified: 2026-01-14
CVE-2023-53338
In the Linux kernel, the following vulnerability has been resolved: lwt: Fix return values of BPF xmit ops BPF encap ops can return different types of positive values, such like NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in ip(6)_finish_output2. When this happens, skbs that have been freed would continue to the neighbor subsystem, causing use-after-free bug and kernel crashes. To fix the incorrect behavior, skb_do_redirect return values can be simply discarded, the same as tc-egress behavior. On the other hand, bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU information. Thus convert its return values to avoid the conflict with LWTUNNEL_XMIT_CONTINUE.
- https://git.kernel.org/stable/c/065d5f17096ec9161180e2c890afdff4dc6125f2
- https://git.kernel.org/stable/c/29b22badb7a84b783e3a4fffca16f7768fb31205
- https://git.kernel.org/stable/c/65583f9e070db7bece20710cfa2e3daeb0b831d9
- https://git.kernel.org/stable/c/67f8f2bae8e7ac72e09def2b667e44704c4d1ee1
- https://git.kernel.org/stable/c/a97f221651fcdc891166e9bc270e3d9bfa5a0080
- https://git.kernel.org/stable/c/d68c17402442f5f494a2c3ebde5cb82f6aa9160a
- https://git.kernel.org/stable/c/e3f647e4b642f9f6d32795a16f92c116c138d2af
Modified: 2026-01-05
CVE-2023-53339
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix BUG_ON condition in btrfs_cancel_balance
Pausing and canceling balance can race to interrupt balance lead to BUG_ON
panic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance
does not take this race scenario into account.
However, the race condition has no other side effects. We can fix that.
Reproducing it with panic trace like this:
kernel BUG at fs/btrfs/volumes.c:4618!
RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0
Call Trace:
Modified: 2026-01-14
CVE-2023-53340
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Collect command failures data only for known commands DEVX can issue a general command, which is not used by mlx5 driver. In case such command is failed, mlx5 is trying to collect the failure data, However, mlx5 doesn't create a storage for this command, since mlx5 doesn't use it. This lead to array-index-out-of-bounds error. Fix it by checking whether the command is known before collecting the failure data.
Modified: 2026-01-14
CVE-2023-53341
In the Linux kernel, the following vulnerability has been resolved: of/fdt: run soc memory setup when early_init_dt_scan_memory fails If memory has been found early_init_dt_scan_memory now returns 1. If it hasn't found any memory it will return 0, allowing other memory setup mechanisms to carry on. Previously early_init_dt_scan_memory always returned 0 without distinguishing between any kind of memory setup being done or not. Any code path after the early_init_dt_scan memory call in the ramips plat_mem_setup code wouldn't be executed anymore. Making early_init_dt_scan_memory the only way to initialize the memory. Some boards, including my mt7621 based Cudy X6 board, depend on memory initialization being done via the soc_info.mem_detect function pointer. Those wouldn't be able to obtain memory and panic the kernel during early bootup with the message "early_init_dt_alloc_memory_arch: Failed to allocate 12416 bytes align=0x40".
Modified: 2026-01-14
CVE-2023-53342
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix handling IPv4 routes with nhid Fix handling IPv4 routes referencing a nexthop via its id by replacing calls to fib_info_nh() with fib_info_nhc(). Trying to add an IPv4 route referencing a nextop via nhid: $ ip link set up swp5 $ ip a a 10.0.0.1/24 dev swp5 $ ip nexthop add dev swp5 id 20 via 10.0.0.2 $ ip route add 10.0.1.0/24 nhid 20 triggers warnings when trying to handle the route: [ 528.805763] ------------[ cut here ]------------ [ 528.810437] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 528.820434] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci] [ 528.837485] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G O 6.4.5 #1 [ 528.845178] Hardware name: delta,tn48m-dn (DT) [ 528.849641] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera] [ 528.857352] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 528.864347] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 528.870135] lr : prestera_k_arb_fib_evt+0xb20/0xd50 [prestera] [ 528.876007] sp : ffff80000b20bc90 [ 528.879336] x29: ffff80000b20bc90 x28: 0000000000000000 x27: ffff0001374d3a48 [ 528.886510] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800 [ 528.893683] x23: ffff000101c89148 x22: ffff000101c89000 x21: ffff000101c89200 [ 528.900855] x20: ffff00013641fda0 x19: ffff800009d01088 x18: 0000000000000059 [ 528.908027] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000 [ 528.915198] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000 [ 528.922371] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013d2020 [ 528.929543] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 : 000000001ca72f86 [ 528.936715] x5 : 0000000033399ea7 x4 : 0000000000000000 x3 : ffff0001374d3acc [ 528.943886] x2 : 0000000000000000 x1 : ffff00010200de00 x0 : ffff000134ae3f80 [ 528.951058] Call trace: [ 528.953516] __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 528.958952] __prestera_router_fib_event_work+0x100/0x158 [prestera] [ 528.965348] process_one_work+0x208/0x488 [ 528.969387] worker_thread+0x4c/0x430 [ 528.973068] kthread+0x120/0x138 [ 528.976313] ret_from_fork+0x10/0x20 [ 528.979909] ---[ end trace 0000000000000000 ]--- [ 528.984998] ------------[ cut here ]------------ [ 528.989645] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 528.999628] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci] [ 529.016676] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G W O 6.4.5 #1 [ 529.024368] Hardware name: delta,tn48m-dn (DT) [ 529.028830] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera] [ 529.036539] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 529.043533] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera] [ 529.049318] lr : __prestera_k_arb_fc_apply+0x280/0x2f8 [prestera] [ 529.055452] sp : ffff80000b20bc60 [ 529.058781] x29: ffff80000b20bc60 x28: 0000000000000000 x27: ffff0001374d3a48 [ 529.065953] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800 [ 529.073126] x23: ffff000101c89148 x22: ffff000101c89148 x21: ffff00013641fda0 [ 529.080299] x20: ffff000101c89000 x19: ffff000101c89020 x18: 0000000000000059 [ 529.087471] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000 [ 529.094642] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000 [ 529.101814] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013cee80 [ 529.108985] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 ---truncated---
Modified: 2026-01-14
CVE-2023-53343
In the Linux kernel, the following vulnerability has been resolved:
icmp6: Fix null-ptr-deref of ip6_null_entry->rt6i_idev in icmp6_dev().
With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet that
has the link-local address as src and dst IP and will be forwarded to
an external IP in the IPv6 Ext Hdr.
For example, the script below generates a packet whose src IP is the
link-local address and dst is updated to 11::.
# for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 > $f; done
# python3
>>> from socket import *
>>> from scapy.all import *
>>>
>>> SRC_ADDR = DST_ADDR = "fe80::5054:ff:fe12:3456"
>>>
>>> pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR)
>>> pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=["11::", "22::"], segleft=1)
>>>
>>> sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW)
>>> sk.sendto(bytes(pkt), (DST_ADDR, 0))
For such a packet, we call ip6_route_input() to look up a route for the
next destination in these three functions depending on the header type.
* ipv6_rthdr_rcv()
* ipv6_rpl_srh_rcv()
* ipv6_srh_rcv()
If no route is found, ip6_null_entry is set to skb, and the following
dst_input(skb) calls ip6_pkt_drop().
Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)->rt6i_idev->dev
as the input device is the loopback interface. Then, we have to check if
skb_rt6_info(skb)->rt6i_idev is NULL or not to avoid NULL pointer deref
for ip6_null_entry.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503)
Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 <48> 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01
RSP: 0018:ffffc90000003c70 EFLAGS: 00000286
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0
RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18
RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001
R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10
R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0
FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/1462e9d9aa52d14665eaca6d89d22c4af44ede04
- https://git.kernel.org/stable/c/2aaa8a15de73874847d62eb595c6683bface80fd
- https://git.kernel.org/stable/c/3fabca5d9cae0140b6aad09a1c6b9aa57089fbb8
- https://git.kernel.org/stable/c/61b4c4659746959056450b92a5d7e6bc1243b31b
- https://git.kernel.org/stable/c/8803c59fde4dd370a627dfbf7183682fa0cabf70
- https://git.kernel.org/stable/c/aa657d319e6c7502a4eb85cc0ee80cc81b8e5724
- https://git.kernel.org/stable/c/d30ddd7ff15df9d91a793ce3f06f0190ff7afacc
Modified: 2026-01-14
CVE-2023-53344
In the Linux kernel, the following vulnerability has been resolved: can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write Syzkaller reported the following issue: ===================================================== BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline] BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600 aio_rw_done fs/aio.c:1520 [inline] aio_write+0x899/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 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 Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc+0x11d/0x3b0 mm/slab_common.c:981 kmalloc_array include/linux/slab.h:636 [inline] bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930 bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] sock_write_iter+0x495/0x5e0 net/socket.c:1108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 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: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 ===================================================== We can follow the call chain and find that 'bcm_tx_setup' function calls 'memcpy_from_msg' to copy some content to the newly allocated frame of 'op->frames'. After that the 'len' field of copied structure being compared with some constant value (64 or 8). However, if 'memcpy_from_msg' returns an error, we will compare some uninitialized memory. This triggers 'uninit-value' issue. This patch will add 'memcpy_from_msg' possible errors processing to avoid uninit-value issue. Tested via syzkaller
- https://git.kernel.org/stable/c/2b4c99f7d9a57ecd644eda9b1fb0a1072414959f
- https://git.kernel.org/stable/c/2e6ad51c709fa794e0ce26003c9c9cd944e3383a
- https://git.kernel.org/stable/c/3fa0f1e0e31b1b73cdf59d4c36c7242e6ef821be
- https://git.kernel.org/stable/c/618b15d09fed6126356101543451d49860db4388
- https://git.kernel.org/stable/c/78bc7f0ab99458221224d3ab97199c0f8e6861f1
- https://git.kernel.org/stable/c/ab2a55907823f0bca56b6d03ea05e4071ba8535f
- https://git.kernel.org/stable/c/bf70e0eab64c625da84d9fdf4e84466b79418920
- https://git.kernel.org/stable/c/c11dbc7705b3739974ac31a13f4ab81e61a5fb07
Modified: 2026-01-14
CVE-2023-53346
In the Linux kernel, the following vulnerability has been resolved: kernel/fail_function: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
- https://git.kernel.org/stable/c/29d53c4c5a6f6d2b93aaac95b65cb4c907faf2ff
- https://git.kernel.org/stable/c/2bb3669f576559db273efe49e0e69f82450efbca
- https://git.kernel.org/stable/c/94f68f3e059c478e240f65fcb64746fe371295df
- https://git.kernel.org/stable/c/bb99db06b8b6ce9351633fc61bec9919d8f6f52b
- https://git.kernel.org/stable/c/dd9981a11d74ff2eb253bb5c459876f8bd3c6c36
- https://git.kernel.org/stable/c/f6d3aee1c66358471275df9dddd480010f061b0e
Modified: 2026-01-14
CVE-2023-53347
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Handle pairing of E-switch via uplink un/load APIs
In case user switch a device from switchdev mode to legacy mode, mlx5
first unpair the E-switch and afterwards unload the uplink vport.
From the other hand, in case user remove or reload a device, mlx5
first unload the uplink vport and afterwards unpair the E-switch.
The latter is causing a bug[1], hence, handle pairing of E-switch as
part of uplink un/load APIs.
[1]
In case VF_LAG is used, every tc fdb flow is duplicated to the peer
esw. However, the original esw keeps a pointer to this duplicated
flow, not the peer esw.
e.g.: if user create tc fdb flow over esw0, the flow is duplicated
over esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicated
flow.
During module unload while a peer tc fdb flow is still offloaded, in
case the first device to be removed is the peer device (esw1 in the
example above), the peer net-dev is destroyed, and so the mlx5e_priv
is memset to 0.
Afterwards, the peer device is trying to unpair himself from the
original device (esw0 in the example above). Unpair API invoke the
original device to clear peer flow from its eswitch (esw0), but the
peer flow, which is stored over the original eswitch (esw0), is
trying to use the peer mlx5e_priv, which is memset to 0 and result in
bellow kernel-oops.
[ 157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60
[ 157.964662 ] #PF: supervisor read access in kernel mode
[ 157.965123 ] #PF: error_code(0x0000) - not-present page
[ 157.965582 ] PGD 0 P4D 0
[ 157.965866 ] Oops: 0000 [#1] SMP
[ 157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core]
[ 157.976164 ] Call Trace:
[ 157.976437 ]
Modified: 2026-01-14
CVE-2023-53348
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock when aborting transaction during relocation with scrub
Before relocating a block group we pause scrub, then do the relocation and
then unpause scrub. The relocation process requires starting and committing
a transaction, and if we have a failure in the critical section of the
transaction commit path (transaction state >= TRANS_STATE_COMMIT_START),
we will deadlock if there is a paused scrub.
That results in stack traces like the following:
[42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6
[42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction.
[42.936] ------------[ cut here ]------------
[42.936] BTRFS: Transaction aborted (error -28)
[42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]
[42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...)
[42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1
[42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]
[42.936] Code: ff ff 45 8b (...)
[42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282
[42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000
[42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff
[42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8
[42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00
[42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0
[42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000
[42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0
[42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[42.936] Call Trace:
[42.936]
Modified: 2026-01-14
CVE-2023-53349
In the Linux kernel, the following vulnerability has been resolved: media: ov2740: Fix memleak in ov2740_init_controls() There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock device: unreferenced object 0xffff8881090e19e0 (size 16): comm "51-i2c-ov2740", pid 278, jiffies 4294781584 (age 23.613s) hex dump (first 16 bytes): 00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|......uj..... backtrace: [<000000004e9fad8f>] __kmalloc_node+0x44/0x1b0 [<0000000039c802f4>] kvmalloc_node+0x34/0x180 [<000000009b8b5c63>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<0000000038644056>] ov2740_probe+0x37d/0x84f [ov2740] [<0000000092489f59>] i2c_device_probe+0x28d/0x680 [<000000001038babe>] really_probe+0x17c/0x3f0 [<0000000098c7af1c>] __driver_probe_device+0xe3/0x170 [<00000000e1b3dc24>] device_driver_attach+0x34/0x80 [<000000005a04a34d>] bind_store+0x10b/0x1a0 [<00000000ce25d4f2>] drv_attr_store+0x49/0x70 [<000000007d9f4e9a>] sysfs_kf_write+0x8c/0xb0 [<00000000be6cff0f>] kernfs_fop_write_iter+0x216/0x2e0 [<0000000031ddb40a>] vfs_write+0x658/0x810 [<0000000041beecdd>] ksys_write+0xd6/0x1b0 [<0000000023755840>] do_syscall_64+0x38/0x90 [<00000000b2cc2da2>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ov2740_init_controls() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak.
- https://git.kernel.org/stable/c/2d899592ed7829d0d5140853bac4d58742a6b8af
- https://git.kernel.org/stable/c/3969b2ebc66039306f505c7c630c5530800f83c0
- https://git.kernel.org/stable/c/7c405ee63447f14eefcfe12a18aa749abbd596ea
- https://git.kernel.org/stable/c/a163ee11345d8322321c28bd61631de32455b987
- https://git.kernel.org/stable/c/fc33380ae06f438b652f66b9370b543976ac8a03
Modified: 2026-01-14
CVE-2023-53354
In the Linux kernel, the following vulnerability has been resolved:
skbuff: skb_segment, Call zero copy functions before using skbuff frags
Commit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions
once per nskb") added the call to zero copy functions in skb_segment().
The change introduced a bug in skb_segment() because skb_orphan_frags()
may possibly change the number of fragments or allocate new fragments
altogether leaving nrfrags and frag to point to the old values. This can
cause a panic with stacktrace like the one below.
[ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc
[ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26
[ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0
[ 194.021892] Call Trace:
[ 194.027422]
- https://git.kernel.org/stable/c/04c3eee4e13f60bf6f9a366ad39f88a01a57166e
- https://git.kernel.org/stable/c/2ea35288c83b3d501a88bc17f2df8f176b5cc96f
- https://git.kernel.org/stable/c/6c26ed3c6abe86ddab0510529000b970b05c9b40
- https://git.kernel.org/stable/c/8836c266201c29a5acb4f582227686f47b65ad61
- https://git.kernel.org/stable/c/d44403ec0676317b7f7edf2a035bb219fee3304e
- https://git.kernel.org/stable/c/d5790386595d06ea9decfd9ba5f1ea48cf09aa02
- https://git.kernel.org/stable/c/f99006e840a4dbc8f5a34cecc6b5b26c73ef49bb
- https://git.kernel.org/stable/c/fcab3f661dbfd88e27ddbbe65368f3fa2d823175
Modified: 2026-01-14
CVE-2023-53355
In the Linux kernel, the following vulnerability has been resolved: staging: pi433: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. This requires saving off the root directory dentry to make creation of individual device subdirectories easier.
Modified: 2026-01-14
CVE-2023-53356
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Add null pointer check in gserial_suspend Consider a case where gserial_disconnect has already cleared gser->ioport. And if gserial_suspend gets called afterwards, it will lead to accessing of gser->ioport and thus causing null pointer dereference. Avoid this by adding a null pointer check. Added a static spinlock to prevent gser->ioport from becoming null after the newly added null pointer check.
- https://git.kernel.org/stable/c/2788a3553f7497075653210b42e2aeb6ba95e28e
- https://git.kernel.org/stable/c/2f6ecb89fe8feb2b60a53325b0eeb9866d88909a
- https://git.kernel.org/stable/c/374447e3367767156405bedd230c5d391f4b7962
- https://git.kernel.org/stable/c/a8ea7ed644cbf6314b5b0136b5398754b549fb8f
- https://git.kernel.org/stable/c/e60a827ac074ce6bd58305fe5a86afab5fce6a04
Modified: 2026-01-14
CVE-2023-53357
In the Linux kernel, the following vulnerability has been resolved: md/raid10: check slab-out-of-bounds in md_bitmap_get_counter If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage() will return -EINVAL because 'page >= bitmap->pages', but the return value was not checked immediately in md_bitmap_get_counter() in order to set *blocks value and slab-out-of-bounds occurs. Move check of 'page >= bitmap->pages' to md_bitmap_get_counter() and return directly if true.
- https://git.kernel.org/stable/c/152bb26796ff054af50b2ee1b3ca56e364e4f61b
- https://git.kernel.org/stable/c/301867b1c16805aebbc306aafa6ecdc68b73c7e5
- https://git.kernel.org/stable/c/374fb914304d9b500721007f3837ea8f1f9a2418
- https://git.kernel.org/stable/c/39fa14e824acfd470db4f42c354297456bd82b53
- https://git.kernel.org/stable/c/a134dd582c0d5b6068efa308bd485cf1d00b3f65
- https://git.kernel.org/stable/c/b0b971fe7d61411ede63c3291764dbde1577ef2c
- https://git.kernel.org/stable/c/be1a3ec63a840cc9e59a033acf154f56255699a1
- https://git.kernel.org/stable/c/bea301c046110bf421a3ce153fb868cb8d618e90
Modified: 2026-01-14
CVE-2023-53358
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix racy issue under cocurrent smb2 tree disconnect There is UAF issue under cocurrent smb2 tree disconnect. This patch introduce TREE_CONN_EXPIRE flags for tcon to avoid cocurrent access.
- https://git.kernel.org/stable/c/30210947a343b6b3ca13adc9bfc88e1543e16dd5
- https://git.kernel.org/stable/c/39366b47a59d46af15ac57beb0996268bf911f6a
- https://git.kernel.org/stable/c/b36295c17fb97424406f0c3ab321b1ccaabb9be8
- https://git.kernel.org/stable/c/bd80d35725a0cf4df9307bfe2f1a3b2cb983d8e6
- https://git.kernel.org/stable/c/dc1c17716c099c90948ebb83e2170dd75a3be6b6
Modified: 2026-01-14
CVE-2023-53359
In the Linux kernel, the following vulnerability has been resolved: USB: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53361
In the Linux kernel, the following vulnerability has been resolved: LoongArch: mm: Add p?d_leaf() definitions When I do LTP test, LTP test case ksm06 caused panic at break_ksm_pmd_entry -> pmd_leaf (Huge page table but False) -> pte_present (panic) The reason is pmd_leaf() is not defined, So like commit 501b81046701 ("mips: mm: add p?d_leaf() definitions") add p?d_leaf() definition for LoongArch.
Modified: 2026-01-14
CVE-2023-53362
In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: don't assume child devices are all fsl-mc devices Changes in VFIO caused a pseudo-device to be created as child of fsl-mc devices causing a crash [1] when trying to bind a fsl-mc device to VFIO. Fix this by checking the device type when enumerating fsl-mc child devices. [1] Modules linked in: Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP CPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2 Hardware name: NXP Layerscape LX2160ARDB (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mc_send_command+0x24/0x1f0 lr : dprc_get_obj_region+0xfc/0x1c0 sp : ffff80000a88b900 x29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2 x26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000 x23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000 x20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001 x17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffff x14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386 x11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012 x8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0 x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8 x2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80 Call trace: mc_send_command+0x24/0x1f0 dprc_get_obj_region+0xfc/0x1c0 fsl_mc_device_add+0x340/0x590 fsl_mc_obj_device_add+0xd0/0xf8 dprc_scan_objects+0x1c4/0x340 dprc_scan_container+0x38/0x60 vfio_fsl_mc_probe+0x9c/0xf8 fsl_mc_driver_probe+0x24/0x70 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 device_driver_attach+0x30/0x68 bind_store+0xa8/0x130 drv_attr_store+0x24/0x38 sysfs_kf_write+0x44/0x60 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x334/0x448 ksys_write+0x68/0xf0 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x108 el0_svc_common.constprop.1+0x94/0xf8 do_el0_svc+0x38/0xb0 el0_svc+0x20/0x50 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x174/0x178 Code: aa0103f4 a9025bf5 d5384100 b9400801 (79401260) ---[ end trace 0000000000000000 ]---
Modified: 2026-01-14
CVE-2023-53365
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: Fix skb_under_panic in ip6mr_cache_report()
skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4
head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:192!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:skb_panic+0x152/0x1d0
Call Trace:
- https://git.kernel.org/stable/c/0438e60a00d4e335b3c36397dbf26c74b5d13ef0
- https://git.kernel.org/stable/c/1683124129a4263dd5bce2475bab110e95fa0346
- https://git.kernel.org/stable/c/1bb54a21f4d9b88442f8c3307c780e2db64417e4
- https://git.kernel.org/stable/c/30e0191b16e8a58e4620fa3e2839ddc7b9d4281c
- https://git.kernel.org/stable/c/3326c711f18d18fe6e1f5d83d3a7eab07e5a1560
- https://git.kernel.org/stable/c/691a09eecad97e745b9aa0e3918db46d020bdacb
- https://git.kernel.org/stable/c/8382e7ed2d63e6c2daf6881fa091526dc6c879cd
- https://git.kernel.org/stable/c/a96d74d1076c82a4cef02c150d9996b21354c78d
Modified: 2026-01-14
CVE-2023-53366
In the Linux kernel, the following vulnerability has been resolved: block: be a bit more careful in checking for NULL bdev while polling Wei reports a crash with an application using polled IO: PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 21915 Comm: iocore_0 Kdump: loaded Tainted: G S 5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1 Hardware name: Wiwynn Delta Lake MP T8/Delta Lake-Class2, BIOS Y3DLM08 04/10/2022 RIP: 0010:bio_poll+0x25/0x200 Code: 0f 1f 44 00 00 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 70 02 00 00 4c 8b 70 50 8b 6f 34 31 db 83 fd ff 75 25 65 RSP: 0018:ffffc90005fafdf8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600 RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140 RBP: ffff88849964df78 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00 R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001 FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: iocb_bio_iopoll+0x1d/0x30 io_do_iopoll+0xac/0x250 __se_sys_io_uring_enter+0x3c5/0x5a0 ? __x64_sys_write+0x89/0xd0 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x94f225d Code: 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 01 00 00 0f 05 <85> c0 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7 RSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa RAX: ffffffffffffffda RBX: 00007fd194ffcdc0 RCX: 00000000094f225d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000001 R11: 0000000000000202 R12: 00007fd269d68030 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000 which is due to bio->bi_bdev being NULL. This can happen if we have two tasks doing polled IO, and task B ends up completing IO from task A if they are sharing a poll queue. If task B completes the IO and puts the bio into our cache, then it can allocate that bio again before task A is done polling for it. As that would necessitate a preempt between the two tasks, it's enough to just be a bit more careful in checking for whether or not bio->bi_bdev is NULL.
Modified: 2026-01-14
CVE-2023-53368
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race issue between cpu buffer write and swap Warning happened in rb_end_commit() at code: if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))) WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142 rb_commit+0x402/0x4a0 Call Trace: ring_buffer_unlock_commit+0x42/0x250 trace_buffer_unlock_commit_regs+0x3b/0x250 trace_event_buffer_commit+0xe5/0x440 trace_event_buffer_reserve+0x11c/0x150 trace_event_raw_event_sched_switch+0x23c/0x2c0 __traceiter_sched_switch+0x59/0x80 __schedule+0x72b/0x1580 schedule+0x92/0x120 worker_thread+0xa0/0x6f0 It is because the race between writing event into cpu buffer and swapping cpu buffer through file per_cpu/cpu0/snapshot: Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1 -------- -------- tracing_snapshot_write() [...] ring_buffer_lock_reserve() cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a'; [...] rb_reserve_next_event() [...] ring_buffer_swap_cpu() if (local_read(&cpu_buffer_a->committing)) goto out_dec; if (local_read(&cpu_buffer_b->committing)) goto out_dec; buffer_a->buffers[cpu] = cpu_buffer_b; buffer_b->buffers[cpu] = cpu_buffer_a; // 2. cpu_buffer has swapped here. rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) { // 3. This check passed due to 'cpu_buffer->buffer' [...] // has not changed here. return NULL; } cpu_buffer_b->buffer = buffer_a; cpu_buffer_a->buffer = buffer_b; [...] // 4. Reserve event from 'cpu_buffer_a'. ring_buffer_unlock_commit() [...] cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!! rb_commit(cpu_buffer) rb_end_commit() // 6. WARN for the wrong 'committing' state !!! Based on above analysis, we can easily reproduce by following testcase: ``` bash #!/bin/bash dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 > ${TR}/buffer_size_kb echo "sched:sched_switch" > ${TR}/set_event while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & ``` To fix it, IIUC, we can use smp_call_function_single() to do the swap on the target cpu where the buffer is located, so that above race would be avoided.
- https://git.kernel.org/stable/c/3163f635b20e9e1fb4659e74f47918c9dddfe64e
- https://git.kernel.org/stable/c/37ca1b686078b00cc4ffa008e2190615f7709b5d
- https://git.kernel.org/stable/c/6182318ac04648b46db9d441fd7d696337fcdd0b
- https://git.kernel.org/stable/c/74c85396bd73eca80b96510b4edf93b9a3aff75f
- https://git.kernel.org/stable/c/89c89da92a60028013f9539be0dcce7e44405a43
- https://git.kernel.org/stable/c/90e037cabc2c2dfc39b3dd9c5b22ea91f995539a
- https://git.kernel.org/stable/c/c5d30d6aa83d99fba8dfdd9cf6c4e4e7a63244db
Modified: 2026-01-14
CVE-2023-53369
In the Linux kernel, the following vulnerability has been resolved: net: dcb: choose correct policy to parse DCB_ATTR_BCN The dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN], which is introduced in commit 859ee3c43812 ("DCB: Add support for DCB BCN"). Please see the comment in below code static int dcbnl_bcn_setcfg(...) { ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) { // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs ... value_int = nla_get_u32(data[i]); ... } ... } That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest attributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the following access code fetch each nlattr as dcbnl_bcn_attrs attributes. By looking up the associated nla_policy for dcbnl_bcn_attrs. We can find the beginning part of these two policies are "same". static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG}, }; static const struct nla_policy dcbnl_bcn_nest[...] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG}, }; Therefore, the current code is buggy and this nla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use the adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0. Hence use the correct policy dcbnl_bcn_nest to parse the nested tb[DCB_ATTR_BCN] TLV.
- https://git.kernel.org/stable/c/199fde04bd875d28b3a5ca525eaaa004eec6e947
- https://git.kernel.org/stable/c/31d49ba033095f6e8158c60f69714a500922e0c3
- https://git.kernel.org/stable/c/5b3dbedb8d4a0f9f7ce904d76b885438af2a21f9
- https://git.kernel.org/stable/c/8e309f43d0ca4051d20736c06a6f84bbddd881da
- https://git.kernel.org/stable/c/a0da2684db18dead3bcee12fb185e596e3d63c2b
- https://git.kernel.org/stable/c/ecff20e193207b44fdbfe64d7de89890f0a7fe6c
Modified: 2026-01-14
CVE-2023-53370
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix memory leak in mes self test The fences associated with mes queue have to be freed up during amdgpu_ring_fini.
Modified: 2026-01-14
CVE-2023-53371
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create The memory pointed to by the fs->any pointer is not freed in the error path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak. Fix by freeing the memory in the error path, thereby making the error path identical to mlx5e_fs_tt_redirect_any_destroy().
Modified: 2026-01-14
CVE-2023-53372
In the Linux kernel, the following vulnerability has been resolved: sctp: fix a potential overflow in sctp_ifwdtsn_skip Currently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only checks the pos against the end of the chunk. However, the data left for the last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereference it as struct sctp_ifwdtsn_skip may cause coverflow. This patch fixes it by checking the pos against "the end of the chunk - sizeof(struct sctp_ifwdtsn_skip)" in sctp_ifwdtsn_skip, similar to sctp_fwdtsn_skip.
- https://git.kernel.org/stable/c/32832a2caf82663870126c5186cf8f86c8b2a649
- https://git.kernel.org/stable/c/4fbd094d4131a10d06a45d64158567052a35b3f4
- https://git.kernel.org/stable/c/5c9367ac5a22d71841bcd00130f9146c9b227d57
- https://git.kernel.org/stable/c/6109f5b13ce3e3e537db6f18976ec0e9118d1c6f
- https://git.kernel.org/stable/c/79b28f42214a3d0d6a8c514db3602260bd5d6cb5
- https://git.kernel.org/stable/c/ad831a7079c99c01e801764b53bc9997c2e9c0f7
- https://git.kernel.org/stable/c/ad988e9b5ff04607e624a459209e8c2d0c15fc73
Modified: 2026-01-14
CVE-2023-53373
In the Linux kernel, the following vulnerability has been resolved: crypto: seqiv - Handle EBUSY correctly As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request. However, as the caller of seqiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.
- https://git.kernel.org/stable/c/1effbddaff60eeef8017c6dea1ee0ed970164d14
- https://git.kernel.org/stable/c/32e62025e5e52fbe4812ef044759de7010b15dbc
- https://git.kernel.org/stable/c/36ec108b7bd7e280edb22de028467bd09d644620
- https://git.kernel.org/stable/c/4d497e8b200a175094e0ac252ed878add39b8771
- https://git.kernel.org/stable/c/63551e4b7cbcd9914258827699eb2cb6ed6e4a16
- https://git.kernel.org/stable/c/9477db935eb690f697d9bcc4f608927841bc8b36
- https://git.kernel.org/stable/c/ae849d2f48019ff9c104e32bf588ccbfb200e971
- https://git.kernel.org/stable/c/cc4d0d4251748a8a68026938f4055d2ac47c5719
Modified: 2026-01-14
CVE-2023-53375
In the Linux kernel, the following vulnerability has been resolved: tracing: Free error logs of tracing instances When a tracing instance is removed, the error messages that hold errors that occurred in the instance needs to be freed. The following reports a memory leak: # cd /sys/kernel/tracing # mkdir instances/foo # echo 'hist:keys=x' > instances/foo/events/sched/sched_switch/trigger # cat instances/foo/error_log [ 117.404795] hist:sched:sched_switch: error: Couldn't find field Command: hist:keys=x ^ # rmdir instances/foo Then check for memory leaks: # echo scan > /sys/kernel/debug/kmemleak # cat /sys/kernel/debug/kmemleak unreferenced object 0xffff88810d8ec700 (size 192): comm "bash", pid 869, jiffies 4294950577 (age 215.752s) hex dump (first 32 bytes): 60 dd 68 61 81 88 ff ff 60 dd 68 61 81 88 ff ff `.ha....`.ha.... a0 30 8c 83 ff ff ff ff 26 00 0a 00 00 00 00 00 .0......&....... backtrace: [<00000000dae26536>] kmalloc_trace+0x2a/0xa0 [<00000000b2938940>] tracing_log_err+0x277/0x2e0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560 [<00000000293a9645>] trigger_process_regex+0x135/0x1a0 [<000000005c22b4f2>] event_trigger_write+0x87/0xf0 [<000000002cadc509>] vfs_write+0x162/0x670 [<0000000059c3b9be>] ksys_write+0xca/0x170 [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc unreferenced object 0xffff888170c35a00 (size 32): comm "bash", pid 869, jiffies 4294950577 (age 215.752s) hex dump (first 32 bytes): 0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist 3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=x......... backtrace: [<000000006a747de5>] __kmalloc+0x4d/0x160 [<000000000039df5f>] tracing_log_err+0x29b/0x2e0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560 [<00000000293a9645>] trigger_process_regex+0x135/0x1a0 [<000000005c22b4f2>] event_trigger_write+0x87/0xf0 [<000000002cadc509>] vfs_write+0x162/0x670 [<0000000059c3b9be>] ksys_write+0xca/0x170 [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc The problem is that the error log needs to be freed when the instance is removed.
- https://git.kernel.org/stable/c/3357c6e429643231e60447b52ffbb7ac895aca22
- https://git.kernel.org/stable/c/33d5d4e67a0e13c3ca6257fa67bf6503bc000878
- https://git.kernel.org/stable/c/46771c34d6721abfd9e7903eaed2201051eebec6
- https://git.kernel.org/stable/c/6e36373aa5ffa8e00fe7c71b3209f6f17081e552
- https://git.kernel.org/stable/c/987f599fc556a4e64c405d8dde32c70311e8c278
- https://git.kernel.org/stable/c/c0cf0f55be043ef67c38f492aa37ed1986d2f6b6
Modified: 2026-01-14
CVE-2023-53376
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Use number of bits to manage bitmap sizes To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using byte as unit. However, bitmap helper functions assume that bitmaps are allocated using unsigned long as unit. This gap causes memory access beyond the bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUG was observed at firmware download to eHBA-9600. Call trace indicated that the out-of-bounds access happened in find_first_zero_bit() called from mpi3mr_send_event_ack() for miroc->evtack_cmds_bitmap. To fix the BUG, do not use bytes to manage bitmap sizes. Instead, use number of bits, and call bitmap helper functions which take number of bits as arguments. For memory allocation, call bitmap_zalloc() instead of kzalloc() and krealloc(). For memory free, call bitmap_free() instead of kfree(). For zero clear, call bitmap_clear() instead of memset(). Remove three fields for bitmap byte sizes in struct scmd_priv which are no longer required. Replace the field dev_handle_bitmap_sz with dev_handle_bitmap_bits to keep number of bits of removepend_bitmap across resize.
Modified: 2026-01-14
CVE-2023-53377
In the Linux kernel, the following vulnerability has been resolved: cifs: prevent use-after-free by freeing the cfile later In smb2_compound_op we have a possible use-after-free which can cause hard to debug problems later on. This was revealed during stress testing with KASAN enabled kernel. Fixing it by moving the cfile free call to a few lines below, after the usage.
Modified: 2026-01-14
CVE-2023-53378
In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Treat the DPT BO as a framebuffer Currently i915_gem_object_is_framebuffer() doesn't treat the BO containing the framebuffer's DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I'm still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)
Modified: 2026-01-14
CVE-2023-53379
In the Linux kernel, the following vulnerability has been resolved: usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe() Smatch reports: drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe() warn: missing unwind goto? After geting irq, if ret < 0, it will return without error handling to free memory. Just add error handling to fix this problem.
- https://git.kernel.org/stable/c/342161c11403ea00e9febc16baab1d883d589d04
- https://git.kernel.org/stable/c/38dbd6f72bfbeba009efe0e9ec1f3ff09f9e23fa
- https://git.kernel.org/stable/c/3e5a7bebf832b1482efe27bcc15a88c5b28a30d0
- https://git.kernel.org/stable/c/4da9edeccf77d7b4c6dbcb34d5908acdaa5bd7e3
- https://git.kernel.org/stable/c/56901de563359de20513e16a9ae008ae2c22e9a9
- https://git.kernel.org/stable/c/dd9b7c89a80428cc5f4ae0d2e1311fdedb2a1aac
- https://git.kernel.org/stable/c/ecf26d6e1b5450620c214feea537bb6ce05c6741
- https://git.kernel.org/stable/c/fe9cdc19861950582f077f254a12026e169eaee5
Modified: 2026-01-14
CVE-2023-53380
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request There are two check of 'mreplace' in raid10_sync_request(). In the first check, 'need_replace' will be set and 'mreplace' will be used later if no-Faulty 'mreplace' exists, In the second check, 'mreplace' will be set to NULL if it is Faulty, but 'need_replace' will not be changed accordingly. null-ptr-deref occurs if Faulty is set between two check. Fix it by merging two checks into one. And replace 'need_replace' with 'mreplace' because their values are always the same.
- https://git.kernel.org/stable/c/144c7fd008e0072b0b565f1157eec618de54ca8a
- https://git.kernel.org/stable/c/222cc459d59857ee28a5366dc225ab42b22f9272
- https://git.kernel.org/stable/c/2990e2ece18dd4cca71b3109c80517ad94adb065
- https://git.kernel.org/stable/c/34817a2441747b48e444cb0e05d84e14bc9443da
- https://git.kernel.org/stable/c/45fa023b3334a7ae6f6c4eb977295804222dfa28
- https://git.kernel.org/stable/c/b5015b97adda6a24dd3e713c63e521ecbeff25c6
- https://git.kernel.org/stable/c/f4368a462b1f9a8ecc2fdb09a28c3d4cad302a4f
Modified: 2026-01-14
CVE-2023-53381
In the Linux kernel, the following vulnerability has been resolved: NFSD: fix leaked reference count of nfsd4_ssc_umount_item The reference count of nfsd4_ssc_umount_item is not decremented on error conditions. This prevents the laundromat from unmounting the vfsmount of the source file. This patch decrements the reference count of nfsd4_ssc_umount_item on error.
- https://git.kernel.org/stable/c/2da50149981d05955e51c28e982e9ac29bd73417
- https://git.kernel.org/stable/c/34e8f9ec4c9ac235f917747b23a200a5e0ec857b
- https://git.kernel.org/stable/c/6c3c05402547aaca3edb23327b50f01a881831b9
- https://git.kernel.org/stable/c/80a15dc4a0214b55ca42675bb0bb2a8d857eb1d0
- https://git.kernel.org/stable/c/9f0df37520a27ad99eaacf38418b3d2bb5023105
Modified: 2026-01-14
CVE-2023-53382
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Reset connection when trying to use SMCRv2 fails.
We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It
can be reproduced by:
- smc_run nginx
- smc_run wrk -t 32 -c 500 -d 30 http://
Modified: 2026-01-14
CVE-2023-53383
In the Linux kernel, the following vulnerability has been resolved: irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4 The T241 platform suffers from the T241-FABRIC-4 erratum which causes unexpected behavior in the GIC when multiple transactions are received simultaneously from different sources. This hardware issue impacts NVIDIA server platforms that use more than two T241 chips interconnected. Each chip has support for 320 {E}SPIs. This issue occurs when multiple packets from different GICs are incorrectly interleaved at the target chip. The erratum text below specifies exactly what can cause multiple transfer packets susceptible to interleaving and GIC state corruption. GIC state corruption can lead to a range of problems, including kernel panics, and unexpected behavior. >From the erratum text: "In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving. The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: - Register reads from GICD_I* and GICD_N* - Register writes to 64-bit GICD registers other than GICD_IROUTERn* - ITS command MOVALL Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses." This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4." Writing to the chip alias region of the GICD_In{E} registers except GICD_ICENABLERn has an equivalent effect as writing to the global distributor. The SPI interrupt deactivate path is not impacted by the erratum. To fix this problem, implement a workaround that ensures read accesses to the GICD_In{E} registers are directed to the chip that owns the SPI, and disable GICv4.x features. To simplify code changes, the gic_configure_irq() function uses the same alias region for both read and write operations to GICD_ICFGR.
Modified: 2026-01-14
CVE-2023-53384
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: avoid possible NULL skb pointer dereference In 'mwifiex_handle_uap_rx_forward()', always check the value returned by 'skb_copy()' to avoid potential NULL pointer dereference in 'mwifiex_uap_queue_bridged_pkt()', and drop original skb in case of copying failure. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/0c57f9ad2c3ed43abb764b0247d610ff7fdb7a00
- https://git.kernel.org/stable/c/139d285e7695279f030dbb172e2d0245425c86c6
- https://git.kernel.org/stable/c/231086e6a36316b823654f4535653f22d6344420
- https://git.kernel.org/stable/c/35a7a1ce7c7d61664ee54f5239a1f120ab95a87e
- https://git.kernel.org/stable/c/7e7197e4d6a1bc72a774590d8765909f898be1dc
- https://git.kernel.org/stable/c/bef85d58f7709896ed8426560ad117a73a37762f
- https://git.kernel.org/stable/c/c2509f7c37355e1f0bd5b7087815b845fd383723
- https://git.kernel.org/stable/c/d155c5f64cefacdc6a9a26d40be53ee2903c28ff
- https://git.kernel.org/stable/c/d7fd24b8d1bb54c5bcf583139e11a5e651e0263c
Modified: 2026-01-14
CVE-2023-53385
In the Linux kernel, the following vulnerability has been resolved: media: mdp3: Fix resource leaks in of_find_device_by_node Use put_device to release the object get through of_find_device_by_node, avoiding resource leaks.
Modified: 2026-01-14
CVE-2023-53386
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix potential use-after-free when clear keys Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu() call.
- https://git.kernel.org/stable/c/35cc42f04bc49f0656f6840cb7451b3df6049649
- https://git.kernel.org/stable/c/3673952cf0c6cf81b06c66a0b788abeeb02ff3ae
- https://git.kernel.org/stable/c/942d8cefb022f384d5424f8b90c7878f3f93726f
- https://git.kernel.org/stable/c/94617b736c25091b60e514e2e7aeafcbbee6b700
- https://git.kernel.org/stable/c/da19f35868dfbecfff4f81166c054d2656cb1be4
- https://git.kernel.org/stable/c/e87da6a0ac6e631454e7da53a76aa9fe44aaa5dd
Modified: 2026-01-14
CVE-2023-53387
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix device management cmd timeout flow In the UFS error handling flow, the host will send a device management cmd (NOP OUT) to the device for link recovery. If this cmd times out and clearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and return. hba->dev_cmd.complete struct is not set to NULL. When this happens, if cmd has been completed by device, then we will call complete() in __ufshcd_transfer_req_compl(). Because the complete struct is allocated on the stack, the following crash will occur: ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync+0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30
Modified: 2026-01-14
CVE-2023-53388
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Clean dangling pointer on bind error path mtk_drm_bind() can fail, in which case drm_dev_put() is called, destroying the drm_device object. However a pointer to it was still being held in the private object, and that pointer would be passed along to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that point, resulting in a panic. Clean the pointer when destroying the object in the error path to prevent this from happening.
- https://git.kernel.org/stable/c/36aa8c61af55675ed967900fbe5deb32d776f051
- https://git.kernel.org/stable/c/49cf87919daeeeeeb9e924c39bdd9203af434461
- https://git.kernel.org/stable/c/6a89ddee1686a8872384aaa9f0bcfa6b675acd86
- https://git.kernel.org/stable/c/7b551a501fa714890e55bae73efede1185728d72
- https://git.kernel.org/stable/c/9a48f99aa7bea15e0b1d8b0040c46b4792eddf3b
- https://git.kernel.org/stable/c/a161f1d92aabb3b8463f752bdc3474dc3a5ec0e5
- https://git.kernel.org/stable/c/f3887c771576c5d740c5c5b8bf654a8ab8020b7d
Modified: 2026-01-14
CVE-2023-53389
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: dp: Only trigger DRM HPD events if bridge is attached The MediaTek DisplayPort interface bridge driver starts its interrupts as soon as its probed. However when the interrupts trigger the bridge might not have been attached to a DRM device. As drm_helper_hpd_irq_event() does not check whether the passed in drm_device is valid or not, a NULL pointer passed in results in a kernel NULL pointer dereference in it. Check whether the bridge is attached and only trigger an HPD event if it is.
Modified: 2026-01-14
CVE-2023-53390
In the Linux kernel, the following vulnerability has been resolved: drivers: base: dd: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53391
In the Linux kernel, the following vulnerability has been resolved: shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs As the ramfs-based tmpfs uses ramfs_init_fs_context() for the init_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb() to free it and avoid a memory leak.
- https://git.kernel.org/stable/c/1f34bf8b442c6d720e7fa6f15e8702427e48aea9
- https://git.kernel.org/stable/c/36ce9d76b0a93bae799e27e4f5ac35478c676592
- https://git.kernel.org/stable/c/487f229efea80c00dd7397547ec4f25fb8999d99
- https://git.kernel.org/stable/c/5fada375113767b3b57f1b04f7a4fe64ffaa626f
- https://git.kernel.org/stable/c/ebe07db840992a3886694ac3d303b06f4b70ce00
Modified: 2026-03-17
CVE-2023-53392
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix kernel panic during warm reset During warm reset device->fw_client is set to NULL. If a bus driver is registered after this NULL setting and before new firmware clients are enumerated by ISHTP, kernel panic will result in the function ishtp_cl_bus_match(). This is because of reference to device->fw_client->props.protocol_name. ISH firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the bus and sets device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel module drivers were loaded right after any of the first ISHTP device was registered, regardless of whether it was a matched or an unmatched device. This resulted in all drivers getting registered much before the warm reset notification from ISH. Starting kernel v5.16, this issue got exposed after the change was introduced to load only bus drivers for the respective matching devices. In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are registered after the warm reset device fw_client NULL setting. cros_ec_ishtp driver_register() triggers the callback to ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel panic in guid_equal() when dereferencing fw_client NULL pointer to get protocol_name.
Modified: 2026-01-14
CVE-2023-53393
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device
Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0),
there is a special handling in order to use the correct counters, but,
port_num is being passed down the stack without any change. Also, some
functions assume that port_num >=1. As a result, the following oops can
occur.
BUG: unable to handle page fault for address: ffff89510294f1a8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP
CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:_raw_spin_lock+0xc/0x20
Call Trace:
Modified: 2026-01-14
CVE-2023-53395
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5 According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode. When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed. ============================================================= UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter]
- https://git.kernel.org/stable/c/23c67fa615c52712bfa02a6dfadbd4656c87c066
- https://git.kernel.org/stable/c/2f2a5905303ae230b5159fcd8cdcd5b3e7ad5e2d
- https://git.kernel.org/stable/c/3a21ffdbc825e0919db9da0e27ee5ff2cc8a863e
- https://git.kernel.org/stable/c/3bf4463e40a17a23f2f261dfd7fe23129bdd04a4
- https://git.kernel.org/stable/c/430787056dd3c591eb553d5c3b2717efcf307d4e
- https://git.kernel.org/stable/c/625c12dc04a607b79f180ef3ee5a12bf2e3324c0
- https://git.kernel.org/stable/c/b102113469487b460e9e77fe9e00d49c50fe8c86
- https://git.kernel.org/stable/c/e1f686930ee4b059c7baa3c3904b2401829f2589
Modified: 2026-01-14
CVE-2023-53396
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix memory leak in do_rename If renaming a file in an encrypted directory, function fscrypt_setup_filename allocates memory for a file name. This name is never used, and before returning to the caller the memory for it is not freed. When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program 'rename' that renames a file in an encrypted directory: unreferenced object 0xffff888101502840 (size 32): comm "rename", pid 9404, jiffies 4302582475 (age 435.735s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename do_rename ubifs_rename vfs_rename do_renameat2 To fix this we can remove the call to fscrypt_setup_filename as it's not needed.
- https://git.kernel.org/stable/c/3a36d20e012903f45714df2731261fdefac900cb
- https://git.kernel.org/stable/c/43b2f7d690697182beed6f71aa57b7249d3cfc9c
- https://git.kernel.org/stable/c/517ddc0259d7a7231486bdafde8035c478bc4088
- https://git.kernel.org/stable/c/7e264f67b7d6580eff5c2696961039fd05c69258
- https://git.kernel.org/stable/c/9f565752b328fe53c9e42b7d4e4d89a1da63d738
Modified: 2026-01-14
CVE-2023-53397
In the Linux kernel, the following vulnerability has been resolved: modpost: fix off by one in is_executable_section() The > comparison should be >= to prevent an out of bounds array access.
- https://git.kernel.org/stable/c/02dc8e8bdbe4412cfcf17ee3873e63fa5a55b957
- https://git.kernel.org/stable/c/3a3f1e573a105328a2cca45a7cfbebabbf5e3192
- https://git.kernel.org/stable/c/5e0424cd8a44b5f480feb06753cdf4e1f248d148
- https://git.kernel.org/stable/c/7ee557590bac154d324de446d1cd0444988bd511
- https://git.kernel.org/stable/c/8b2e77050b91199453bf19d0517b047b7339a9e3
- https://git.kernel.org/stable/c/cade370efe2f9e2a79ea8587506ffe2b51ac6d2b
- https://git.kernel.org/stable/c/cb0cdca5c979bc34c27602e2039562932c2591a4
- https://git.kernel.org/stable/c/dd872d5576cc94528f427c7264c2c438928cc6d2
Modified: 2026-01-14
CVE-2023-53398
In the Linux kernel, the following vulnerability has been resolved: mlx5: fix possible ptp queue fifo use-after-free Fifo indexes are not checked during pop operations and it leads to potential use-after-free when poping from empty queue. Such case was possible during re-sync action. WARN_ON_ONCE covers future cases. There were out-of-order cqe spotted which lead to drain of the queue and use-after-free because of lack of fifo pointers check. Special check and counter are added to avoid resync operation if SKB could not exist in the fifo because of OOO cqe (skb_id must be between consumer and producer index).
Modified: 2026-01-14
CVE-2023-53399
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix NULL pointer dereference in smb2_get_info_filesystem() If share is , share->path is NULL and it cause NULL pointer dereference issue.
- https://git.kernel.org/stable/c/1636e09779f83e10e6ed57d91ef94abcefdd206b
- https://git.kernel.org/stable/c/227eb2689b44d0d60da3839b146983e73435924c
- https://git.kernel.org/stable/c/3ac00a2ab69b34189942afa9e862d5170cdcb018
- https://git.kernel.org/stable/c/a70751dd7b60eab025e97e19b6b2477c6eaf2bbb
- https://git.kernel.org/stable/c/b35f6c031b87d9e51f141ff6de0ea59756a8e313
Modified: 2026-01-14
CVE-2023-53400
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix Oops by 9.1 surround channel names get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec. As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
- https://git.kernel.org/stable/c/082dcd51667b29097500c824c37f24da997a6a8a
- https://git.kernel.org/stable/c/3b44ec8c5c44790a82f07e90db45643c762878c6
- https://git.kernel.org/stable/c/4ef155ddf9578bf035964d58739fdcd7dd44b4a4
- https://git.kernel.org/stable/c/546b1f5f45a355ae0d3a8041cdaca597dfcac825
- https://git.kernel.org/stable/c/b5694aae4c2d9a288bafce7d38f122769e0428e6
- https://git.kernel.org/stable/c/dc8c569d59f17b17d7bca4f68c36bd571659921e
- https://git.kernel.org/stable/c/e8c7d7c43d5edd20e518fe1dfb2371d1fe6e8bb8
- https://git.kernel.org/stable/c/fcf637461019e9a5a0c12fc5c42a9db1779b0634
Modified: 2026-01-14
CVE-2023-53401
In the Linux kernel, the following vulnerability has been resolved: mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required() KCSAN found an issue in obj_stock_flush_required(): stock->cached_objcg can be reset between the check and dereference: ================================================================== BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 memcg_slab_free_hook mm/slab.h:587 [inline] __cache_free mm/slab.c:3373 [inline] __do_kmem_cache_free mm/slab.c:3577 [inline] kmem_cache_free+0x105/0x280 mm/slab.c:3602 __d_free fs/dcache.c:298 [inline] dentry_free fs/dcache.c:375 [inline] __dentry_kill+0x422/0x4a0 fs/dcache.c:621 dentry_kill+0x8d/0x1e0 dput+0x118/0x1f0 fs/dcache.c:913 __fput+0x3bf/0x570 fs/file_table.c:329 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x123/0x160 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: obj_stock_flush_required mm/memcontrol.c:3319 [inline] drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 try_charge mm/memcontrol.c:2837 [inline] mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 __do_sys_setsockopt net/socket.c:2282 [inline] __se_sys_setsockopt net/socket.c:2279 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffff8881382d52c0 -> 0xffff888138893740 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 Fix it by using READ_ONCE()/WRITE_ONCE() for all accesses to stock->cached_objcg.
Modified: 2026-01-14
CVE-2023-53402
In the Linux kernel, the following vulnerability has been resolved: kernel/printk/index.c: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53403
In the Linux kernel, the following vulnerability has been resolved: time/debug: Fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53404
In the Linux kernel, the following vulnerability has been resolved: USB: fotg210: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53405
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: gr_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53406
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: pxa25x_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53407
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: pxa27x_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53408
In the Linux kernel, the following vulnerability has been resolved: trace/blktrace: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53409
In the Linux kernel, the following vulnerability has been resolved: drivers: base: component: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53410
In the Linux kernel, the following vulnerability has been resolved: USB: ULPI: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53411
In the Linux kernel, the following vulnerability has been resolved: PM: EM: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
- https://git.kernel.org/stable/c/30fee10192e1239478a0987bc7ee445d5e980d46
- https://git.kernel.org/stable/c/5100c4efc30636aa48ac517dece3c3b7f84fe367
- https://git.kernel.org/stable/c/84e4d4885d0ae011860fb599d50d01b8fdca2b87
- https://git.kernel.org/stable/c/a0e8c13ccd6a9a636d27353da62c2410c4eca337
- https://git.kernel.org/stable/c/e974e8f1e37d22c0de07374f8ddc84073fef2f1d
Modified: 2026-01-14
CVE-2023-53412
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: bcm63xx_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53413
In the Linux kernel, the following vulnerability has been resolved: USB: isp116x: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53414
In the Linux kernel, the following vulnerability has been resolved: scsi: snic: Fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53415
In the Linux kernel, the following vulnerability has been resolved: USB: dwc3: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Note, the root dentry for the debugfs directory for the device needs to be saved so we don't have to keep looking it up, which required a bit more refactoring to properly create and remove it when needed.
Modified: 2026-01-14
CVE-2023-53416
In the Linux kernel, the following vulnerability has been resolved: USB: isp1362: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53417
In the Linux kernel, the following vulnerability has been resolved: USB: sl811: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53418
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: lpc32xx_udc: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
Modified: 2026-01-14
CVE-2023-53419
In the Linux kernel, the following vulnerability has been resolved: rcu: Protect rcu_print_task_exp_stall() ->exp_tasks access For kernels built with CONFIG_PREEMPT_RCU=y, the following scenario can result in a NULL-pointer dereference: CPU1 CPU2 rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall if (special.b.blocked) READ_ONCE(rnp->exp_tasks) != NULL raw_spin_lock_rcu_node np = rcu_next_node_entry(t, rnp) if (&t->rcu_node_entry == rnp->exp_tasks) WRITE_ONCE(rnp->exp_tasks, np) .... raw_spin_unlock_irqrestore_rcu_node raw_spin_lock_irqsave_rcu_node t = list_entry(rnp->exp_tasks->prev, struct task_struct, rcu_node_entry) (if rnp->exp_tasks is NULL, this will dereference a NULL pointer) The problem is that CPU2 accesses the rcu_node structure's->exp_tasks field without holding the rcu_node structure's ->lock and CPU2 did not observe CPU1's change to rcu_node structure's ->exp_tasks in time. Therefore, if CPU1 sets rcu_node structure's->exp_tasks pointer to NULL, then CPU2 might dereference that NULL pointer. This commit therefore holds the rcu_node structure's ->lock while accessing that structure's->exp_tasks field. [ paulmck: Apply Frederic Weisbecker feedback. ]
- https://git.kernel.org/stable/c/2bc0ae94ef1f9ed322d8ee439de3239ea3632ab2
- https://git.kernel.org/stable/c/3c1566bca3f8349f12b75d0a2d5e4a20ad6262ec
- https://git.kernel.org/stable/c/a7d21b8585894e6fff973f6ddae42f02b13f600f
- https://git.kernel.org/stable/c/d0a8c0e31a09ec1efd53079083e2a677956b4d91
- https://git.kernel.org/stable/c/e30a55e98ae6c44253d8b129efefd5da5bc6e3bc
Modified: 2026-01-14
CVE-2023-53420
In the Linux kernel, the following vulnerability has been resolved: ntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr() Here is a BUG report from syzbot: BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline] BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710 Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632 Call Trace: ntfs_list_ea fs/ntfs3/xattr.c:191 [inline] ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710 vfs_listxattr fs/xattr.c:457 [inline] listxattr+0x293/0x2d0 fs/xattr.c:804 Fix the logic of ea_all iteration. When the ea->name_len is 0, return immediately, or Add2Ptr() would visit invalid memory in the next loop. [almaz.alexandrovich@paragon-software.com: lines of the patch have changed]
Modified: 2026-01-14
CVE-2023-53422
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fw: fix memory leak in debugfs Fix a memory leak that occurs when reading the fw_info file all the way, since we return NULL indicating no more data, but don't free the status tracking object.
- https://git.kernel.org/stable/c/37f64bc8e001f216566d17ef9fd5608c762ebcd4
- https://git.kernel.org/stable/c/3d90d2f4a018fe8cfd65068bc6350b6222be4852
- https://git.kernel.org/stable/c/89496d6cff297c88fe0286a440c380ceb172da2b
- https://git.kernel.org/stable/c/b830ba20b43be52eae7d4087b61a0079dec56820
- https://git.kernel.org/stable/c/e302e9ca14a86a80eadfb24a34d8675aadaf3ef3
- https://git.kernel.org/stable/c/fe17124282da055cb2e53f0131521459b5c7866c
Modified: 2026-01-14
CVE-2023-53423
In the Linux kernel, the following vulnerability has been resolved: objtool: Fix memory leak in create_static_call_sections() strdup() allocates memory for key_name. We need to release the memory in the following error paths. Add free() to avoid memory leak.
- https://git.kernel.org/stable/c/3a75866a5ceff5d4fdd5471e06c4c4d03e0298b3
- https://git.kernel.org/stable/c/3da73f102309fe29150e5c35acd20dd82063ff67
- https://git.kernel.org/stable/c/a1368eaea058e451d20ea99ca27e72d9df0d16dd
- https://git.kernel.org/stable/c/a8f63d747bf7c983882a5ea7456a5f84ad3acad5
- https://git.kernel.org/stable/c/d131718d9c45d559951f57c4b88209ca407433c4
Modified: 2026-01-14
CVE-2023-53425
In the Linux kernel, the following vulnerability has been resolved: media: platform: mediatek: vpu: fix NULL ptr dereference If pdev is NULL, then it is still dereferenced. This fixes this smatch warning: drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev'
- https://git.kernel.org/stable/c/099e929e7477f37ca16738fc158d7101c0189ca1
- https://git.kernel.org/stable/c/1b3f25d3894a091abc247eadab266a2c9be64389
- https://git.kernel.org/stable/c/2caeb722f0ea5d2d24af30bb1753a89d449b6aa0
- https://git.kernel.org/stable/c/3df55cd773e8603b623425cc97b05e542854ad27
- https://git.kernel.org/stable/c/4d299e6e0ac3cf8ab4517dc29c9294bc4bf72398
- https://git.kernel.org/stable/c/776b34615a29551d69d82a0082e7319d5ea284bd
- https://git.kernel.org/stable/c/b7bd48f0be84e24d21aa3a8f59a8a9cb8633a1c4
- https://git.kernel.org/stable/c/c1c5826223ae05a48d21f6708c6f34ee9006238c
Modified: 2026-01-14
CVE-2023-53426
In the Linux kernel, the following vulnerability has been resolved: xsk: Fix xsk_diag use-after-free error during socket cleanup Fix a use-after-free error that is possible if the xsk_diag interface is used after the socket has been unbound from the device. This can happen either due to the socket being closed or the device disappearing. In the early days of AF_XDP, the way we tested that a socket was not bound to a device was to simply check if the netdevice pointer in the xsk socket structure was NULL. Later, a better system was introduced by having an explicit state variable in the xsk socket struct. For example, the state of a socket that is on the way to being closed and has been unbound from the device is XSK_UNBOUND. The commit in the Fixes tag below deleted the old way of signalling that a socket is unbound, setting dev to NULL. This in the belief that all code using the old way had been exterminated. That was unfortunately not true as the xsk diagnostics code was still using the old way and thus does not work as intended when a socket is going down. Fix this by introducing a test against the state variable. If the socket is in the state XSK_UNBOUND, simply abort the diagnostic's netlink operation.
Modified: 2026-01-14
CVE-2023-53427
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix warning and UAF when destroy the MR list
If the MR allocate failed, the MR recovery work not initialized
and list not cleared. Then will be warning and UAF when release
the MR:
WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110
CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82
RIP: 0010:__flush_work.isra.0+0xf7/0x110
Call Trace:
- https://git.kernel.org/stable/c/275a3d2b9408fc4895e342f772cab9a89960546e
- https://git.kernel.org/stable/c/2d0c4f5f618f58eba03385363717703bee873c64
- https://git.kernel.org/stable/c/3524d6da0fe88aee79f06be6572955d16ad76b39
- https://git.kernel.org/stable/c/3e161c2791f8e661eed24a2c624087084d910215
- https://git.kernel.org/stable/c/41832c62a75dad530dc5a2856c92ae5459d497e5
- https://git.kernel.org/stable/c/7cbd5bdb5bd4404a5da4309521134b42c65846c0
- https://git.kernel.org/stable/c/cfd85a0922c4696d768965e686ad805a58d9d834
Modified: 2026-01-14
CVE-2023-53431
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Handle enclosure with just a primary component gracefully
This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure
has no components") and introduces proper handling of case where there are
no detected secondary components, but primary component (enumerated in
num_enclosures) does exist. That fix was originally proposed by Ding Hui
- https://git.kernel.org/stable/c/05143d90ac90b7abc6692285895a1ef460e008ee
- https://git.kernel.org/stable/c/110d425cdfb15006f3c4fde5264e786a247b6b36
- https://git.kernel.org/stable/c/176d7345b89ced72020a313bfa4e7f345d1c3aed
- https://git.kernel.org/stable/c/4e7c498c3713b09bef20c76c7319555637e8bbd5
- https://git.kernel.org/stable/c/c8e22b7a1694bb8d025ea636816472739d859145
- https://git.kernel.org/stable/c/eabc4872f172ecb8dd8536bc366a51868154a450
- https://git.kernel.org/stable/c/f8e702c54413eee2d8f94f61d18adadac7c87e87
Modified: 2026-01-14
CVE-2023-53432
In the Linux kernel, the following vulnerability has been resolved: firewire: net: fix use after free in fwnet_finish_incoming_packet() The netif_rx() function frees the skb so we can't dereference it to save the skb->len.
Modified: 2026-01-14
CVE-2023-53433
In the Linux kernel, the following vulnerability has been resolved:
net: add vlan_get_protocol_and_depth() helper
Before blamed commit, pskb_may_pull() was used instead
of skb_header_pointer() in __vlan_get_protocol() and friends.
Few callers depended on skb->head being populated with MAC header,
syzbot caught one of them (skb_mac_gso_segment())
Add vlan_get_protocol_and_depth() to make the intent clearer
and use it where sensible.
This is a more generic fix than commit e9d3f80935b6
("net/af_packet: make sure to pull mac header") which was
dealing with a similar issue.
kernel BUG at include/linux/skbuff.h:2655 !
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]
RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136
Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286
RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9
R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012
R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7
FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/15eaeb8941f12fcc2713c4bf6eb8f76a37854b4d
- https://git.kernel.org/stable/c/34a5ee69ec6273f0aee79e7ce4d14afc83ca8122
- https://git.kernel.org/stable/c/4063384ef762cc5946fc7a3f89879e76c6ec51e2
- https://git.kernel.org/stable/c/4188c5269475ac59d467b5814c5df02756f6d907
- https://git.kernel.org/stable/c/55caf900e13cd04466def08173a14b41d18c19c3
- https://git.kernel.org/stable/c/9dd9ffe118415b4ac1cebac43443000072bc8f46
Modified: 2026-01-14
CVE-2023-53434
In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores The IRAM is part of the HiFi DSP. According to hardware specification only 32-bits write are allowed otherwise we get a Kernel panic. Therefore add a custom memory copy and memset functions to deal with the above restriction.
Modified: 2026-01-14
CVE-2023-53435
In the Linux kernel, the following vulnerability has been resolved: cassini: Fix a memory leak in the error handling path of cas_init_one() cas_saturn_firmware_init() allocates some memory using vmalloc(). This memory is freed in the .remove() function but not it the error handling path of the probe. Add the missing vfree() to avoid a memory leak, should an error occur.
- https://git.kernel.org/stable/c/11c0ed097a874156957b515d0ba7e356142eab87
- https://git.kernel.org/stable/c/172146c26f0c1b86ab4e9ebffc7e06f04229fa17
- https://git.kernel.org/stable/c/234e744d86bd95b381d24546df2dba72804e0219
- https://git.kernel.org/stable/c/412cd77a2c24b191c65ea53025222418db09817c
- https://git.kernel.org/stable/c/60d8e8b88087d68e10c8991a0f6733fa2f963ff0
- https://git.kernel.org/stable/c/b8b1a667744741fa7807b09a12797a27f14f3fac
- https://git.kernel.org/stable/c/dc61f7582cc92d547d02e141cd66f5d1f4ed8012
- https://git.kernel.org/stable/c/e20105d967ab5b53ff50a0e5991fe37324d2ba20
Modified: 2026-01-14
CVE-2023-53436
In the Linux kernel, the following vulnerability has been resolved: scsi: snic: Fix possible memory leak if device_add() fails If device_add() returns error, the name allocated by dev_set_name() needs be freed. As the comment of device_add() says, put_device() should be used to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanp().
- https://git.kernel.org/stable/c/41320b18a0e0dfb236dba4edb9be12dba1878156
- https://git.kernel.org/stable/c/461f8ac666fa232afee5ed6420099913ec4e4ba2
- https://git.kernel.org/stable/c/58889d5ad74cbc1c9595db74e13522b58b69b0ec
- https://git.kernel.org/stable/c/7723a5d5d187626c4c640842e522cf4e9e39492e
- https://git.kernel.org/stable/c/789275f7c0544374d40bc8d9c81f96751a41df45
- https://git.kernel.org/stable/c/cea09922f5f75652d55b481ee34011fc7f19868b
- https://git.kernel.org/stable/c/ed0acb1ee2e9322b96611635a9ca9303d15ac76c
- https://git.kernel.org/stable/c/f830968d464f55e11bc9260a132fc77daa266aa3
Modified: 2026-01-14
CVE-2023-53437
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Handle cameras with invalid descriptors If the source entity does not contain any pads, do not create a link.
- https://git.kernel.org/stable/c/11196ee3916e50a5da3c1e6ecda19a02dca14ba3
- https://git.kernel.org/stable/c/1a76cfc388cf105d3e04ac592670a52a3864b1ba
- https://git.kernel.org/stable/c/2914259fcea23971c6fed8b2618d3a729a78c365
- https://git.kernel.org/stable/c/31a8d11d28b57656cebfbd4c0b8b76f6ad5b017d
- https://git.kernel.org/stable/c/41ddb251c68ac75c101d3a50a68c4629c9055e4c
- https://git.kernel.org/stable/c/4e4e6ca62e77539d4df8d13137e2683b10baddd9
- https://git.kernel.org/stable/c/c8f4a424af5879baefb0fb8a8a09b09ea1779483
- https://git.kernel.org/stable/c/d8aa2e1ae6426d7cbddf1735aed1a63ddf0e6909
Modified: 2026-01-14
CVE-2023-53438
In the Linux kernel, the following vulnerability has been resolved: x86/MCE: Always save CS register on AMD Zen IF Poison errors The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed. There is no architecturally-defined method to determine this behavior. The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV]. Add a quirk to save the CS register for poison consumption from the IF unit banks. This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context.
Modified: 2026-01-14
CVE-2023-53439
In the Linux kernel, the following vulnerability has been resolved:
net: skb_partial_csum_set() fix against transport header magic value
skb->transport_header uses the special 0xFFFF value
to mark if the transport header was set or not.
We must prevent callers to accidentaly set skb->transport_header
to 0xFFFF. Note that only fuzzers can possibly do this today.
syzbot reported:
WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 skb_transport_offset include/linux/skbuff.h:2956 [inline]
WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103
Modules linked in:
CPU: 0 PID: 2340 Comm: syz-executor.0 Not tainted 6.3.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
RIP: 0010:skb_transport_header include/linux/skbuff.h:2847 [inline]
RIP: 0010:skb_transport_offset include/linux/skbuff.h:2956 [inline]
RIP: 0010:virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103
Code: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 ff ff e8 c4 36 7e fc <0f> 0b e9 93 f8 ff ff 44 89 f7 44 89 e6 e8 32 38 7e fc 45 39 e6 0f
RSP: 0018:ffffc90004497880 EFLAGS: 00010293
RAX: ffffffff84fea55c RBX: 000000000000ffff RCX: ffff888120be2100
RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff
RBP: ffffc90004497990 R08: ffffffff84fe9de5 R09: 0000000000000034
R10: ffffea00048ebd80 R11: 0000000000000034 R12: ffff88811dc2d9c8
R13: dffffc0000000000 R14: ffff88811dc2d9ae R15: 1ffff11023b85b35
FS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200002c0 CR3: 00000001215a5000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2026-01-14
CVE-2023-53440
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix sysfs interface lifetime The current nilfs2 sysfs support has issues with the timing of creation and deletion of sysfs entries, potentially leading to null pointer dereferences, use-after-free, and lockdep warnings. Some of the sysfs attributes for nilfs2 per-filesystem instance refer to metadata file "cpfile", "sufile", or "dat", but nilfs_sysfs_create_device_group that creates those attributes is executed before the inodes for these metadata files are loaded, and nilfs_sysfs_delete_device_group which deletes these sysfs entries is called after releasing their metadata file inodes. Therefore, access to some of these sysfs attributes may occur outside of the lifetime of these metadata files, resulting in inode NULL pointer dereferences or use-after-free. In addition, the call to nilfs_sysfs_create_device_group() is made during the locking period of the semaphore "ns_sem" of nilfs object, so the shrinker call caused by the memory allocation for the sysfs entries, may derive lock dependencies "ns_sem" -> (shrinker) -> "locks acquired in nilfs_evict_inode()". Since nilfs2 may acquire "ns_sem" deep in the call stack holding other locks via its error handler __nilfs_error(), this causes lockdep to report circular locking. This is a false positive and no circular locking actually occurs as no inodes exist yet when nilfs_sysfs_create_device_group() is called. Fortunately, the lockdep warnings can be resolved by simply moving the call to nilfs_sysfs_create_device_group() out of "ns_sem". This fixes these sysfs issues by revising where the device's sysfs interface is created/deleted and keeping its lifetime within the lifetime of the metadata files above.
- https://git.kernel.org/stable/c/1942ccb7d95f287a312fcbabfa8bc9ba501b1953
- https://git.kernel.org/stable/c/3dbee84bf9e3273c4bb9ca6fc18ff22fba23dd24
- https://git.kernel.org/stable/c/42560f9c92cc43dce75dbf06cc0d840dced39b12
- https://git.kernel.org/stable/c/5fe0ea141fbb887d407f1bf572ebf24427480d5c
- https://git.kernel.org/stable/c/83b16a60e413148685739635901937e2f16a7873
- https://git.kernel.org/stable/c/d20dcec8f326deb77b6688f8441e014045dac457
- https://git.kernel.org/stable/c/d540aea451ab5489777a8156560f1388449b3109
- https://git.kernel.org/stable/c/daf4eb3a908b108279b60172d2f176e70d2df875
Modified: 2026-01-14
CVE-2023-53441
In the Linux kernel, the following vulnerability has been resolved:
bpf: cpumap: Fix memory leak in cpu_map_update_elem
Syzkaller reported a memory leak as follows:
BUG: memory leak
unreferenced object 0xff110001198ef748 (size 192):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 32 bytes):
00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J...........
00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(.......
backtrace:
[
Modified: 2026-01-14
CVE-2023-53442
In the Linux kernel, the following vulnerability has been resolved: ice: Block switchdev mode when ADQ is active and vice versa ADQ and switchdev are not supported simultaneously. Enabling both at the same time can result in nullptr dereference. To prevent this, check if ADQ is active when changing devlink mode to switchdev mode, and check if switchdev is active when enabling ADQ.
Modified: 2026-01-14
CVE-2023-53443
In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get() as pm_runtime_get_sync() will increase the refcnt even when it returns an error.
- https://git.kernel.org/stable/c/4414a7ab80cebf715045e3c4d465feefbad21139
- https://git.kernel.org/stable/c/5a47bb71b1a94a279144fc3031d3c4591b38dd16
- https://git.kernel.org/stable/c/7195e642b49af60d4120fa1b45bd812ba528174f
- https://git.kernel.org/stable/c/754e81ff44061dda68da0fd4ef51bd1aa9fbf2cf
- https://git.kernel.org/stable/c/9893771097b22a8743a446e45994a177795ca4da
- https://git.kernel.org/stable/c/dc9437e9889c3dacf1f320e3cf08da74127573fe
Modified: 2026-01-14
CVE-2023-53444
In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix bulk_move corruption when adding a entry When the resource is the first in the bulk_move range, adding it again (thus moving it to the tail) will corrupt the list since the first pointer is not moved. This eventually lead to null pointer deref in ttm_lru_bulk_move_del()
Modified: 2026-01-14
CVE-2023-53445
In the Linux kernel, the following vulnerability has been resolved:
net: qrtr: Fix a refcount bug in qrtr_recvmsg()
Syzbot reported a bug as following:
refcount_t: addition on 0; use-after-free.
...
RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25
...
Call Trace:
- https://git.kernel.org/stable/c/44d807320000db0d0013372ad39b53e12d52f758
- https://git.kernel.org/stable/c/48a07f6e00d305597396da4d7494b81cec05b9d3
- https://git.kernel.org/stable/c/98a9cd82c541ef6cbdb829cd6c05cbbb471e373c
- https://git.kernel.org/stable/c/aa95efa187b4114075f312b3c4680d050b56fdec
- https://git.kernel.org/stable/c/b9ba5906c42089f8e1d0001b7b50a7940f086cbb
Modified: 2026-01-14
CVE-2023-53446
In the Linux kernel, the following vulnerability has been resolved: PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free Struct pcie_link_state->downstream is a pointer to the pci_dev of function 0. Previously we retained that pointer when removing function 0, and subsequent ASPM policy changes dereferenced it, resulting in a use-after-free warning from KASAN, e.g.: # echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove # echo powersave > /sys/module/pcie_aspm/parameters/policy BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500 Call Trace: kasan_report+0xae/0xe0 pcie_config_aspm_link+0x42d/0x500 pcie_aspm_set_policy+0x8e/0x1a0 param_attr_store+0x162/0x2c0 module_attr_store+0x3e/0x80 PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM Control value in all functions of multi-function devices. Disable ASPM and free the pcie_link_state when any child function is removed so we can discard the dangling pcie_link_state->downstream pointer and maintain the same ASPM Control configuration for all functions. [bhelgaas: commit log and comment]
- https://git.kernel.org/stable/c/4203722d51afe3d239e03f15cc73efdf023a7103
- https://git.kernel.org/stable/c/456d8aa37d0f56fc9e985e812496e861dcd6f2f2
- https://git.kernel.org/stable/c/666e7f9d60cee23077ea3e6331f6f8a19f7ea03f
- https://git.kernel.org/stable/c/7aecdd47910c51707696e8b0e045b9f88bd4230f
- https://git.kernel.org/stable/c/7badf4d6f49a358a01ab072bbff88d3ee886c33b
- https://git.kernel.org/stable/c/9856c0de49052174ab474113f4ba40c02aaee086
- https://git.kernel.org/stable/c/d51d2eeae4ce54d542909c4d9d07bf371a78592c
Modified: 2026-01-16
CVE-2023-53448
In the Linux kernel, the following vulnerability has been resolved: fbdev: imxfb: Removed unneeded release_mem_region Remove unnecessary release_mem_region from the error path to prevent mem region from being released twice, which could avoid resource leak or other unexpected issues.
Modified: 2026-01-16
CVE-2023-53449
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential memleak in dasd_eckd_init() `dasd_reserve_req` is allocated before `dasd_vol_info_req`, and it also needs to be freed before the error returns, just like the other cases in this function.
- https://git.kernel.org/stable/c/460e9bed82e49db1b823dcb4e421783854d86c40
- https://git.kernel.org/stable/c/544a552be0869231799784279d52704c4d314d33
- https://git.kernel.org/stable/c/a50e28d433acf22258f9f34831057387f04ef074
- https://git.kernel.org/stable/c/aede5230d154b6b237985ec9df7ebbd1dce96810
- https://git.kernel.org/stable/c/ee986d80acdef710a886be404308188ea11000c8
- https://git.kernel.org/stable/c/ef3a7ffc0a6f833578bc8d1dcb79d0633c7e4ec3
Modified: 2025-03-20
CVE-2023-5345
A use-after-free vulnerability in the Linux kernel's fs/smb/client component can be exploited to achieve local privilege escalation. In case of an error in smb3_fs_context_parse_param, ctx->password was freed but the field was not set to NULL which could lead to double free. We recommend upgrading past commit e6e43b8aa7cd3c3af686caf0c2e11819a886d705.
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6e43b8aa7cd3c3af686caf0c2e11819a886d705
- https://kernel.dance/e6e43b8aa7cd3c3af686caf0c2e11819a886d705
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GISYSL3F6WIEVGHJGLC2MFNTUXHPTKQH/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GPMICQ2HVZO5UAM5KPXHAZKA2U3ZDOO6/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V5PDNWPKAP3WL5RQZ4RIDS6MG32OHH5R/
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6e43b8aa7cd3c3af686caf0c2e11819a886d705
- https://kernel.dance/e6e43b8aa7cd3c3af686caf0c2e11819a886d705
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GISYSL3F6WIEVGHJGLC2MFNTUXHPTKQH/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GPMICQ2HVZO5UAM5KPXHAZKA2U3ZDOO6/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V5PDNWPKAP3WL5RQZ4RIDS6MG32OHH5R/
Modified: 2026-01-23
CVE-2023-53450
In the Linux kernel, the following vulnerability has been resolved: ext4: remove a BUG_ON in ext4_mb_release_group_pa() If a malicious fuzzer overwrites the ext4 superblock while it is mounted such that the s_first_data_block is set to a very large number, the calculation of the block group can underflow, and trigger a BUG_ON check. Change this to be an ext4_warning so that we don't crash the kernel.
- https://git.kernel.org/stable/c/185062a21976fbc38f2efd296951b02c4500cf65
- https://git.kernel.org/stable/c/463808f237cf73e98a1a45ff7460c2406a150a0b
- https://git.kernel.org/stable/c/53c14e7cc2257191ba15425c15638fc4f8abb92b
- https://git.kernel.org/stable/c/978e5e9111af18741449b81fefd531a622dd969a
- https://git.kernel.org/stable/c/b0fc279de4bf17e1710bb7e83906538ff8f11111
- https://git.kernel.org/stable/c/bf2a16eb4e6d06124bd8436d4546f61539a65f29
- https://git.kernel.org/stable/c/d5bf8f7fb3ee3d99d1303ceb54599ea0599a4a5b
- https://git.kernel.org/stable/c/d87a4e4094c9879fc8acdff8ce59fdffa979c8e0
- https://git.kernel.org/stable/c/ef16d8a1798db1a1604ac44ca1bd73ec6bebf483
Modified: 2026-01-16
CVE-2023-53451
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix potential NULL pointer dereference Klocwork tool reported 'cur_dsd' may be dereferenced. Add fix to validate pointer before dereferencing the pointer.
- https://git.kernel.org/stable/c/02405f4023866ae91a611b5b85cb2e074ec2de5a
- https://git.kernel.org/stable/c/2bea9c1c983152c5411f5a2f1113cb790ce1389d
- https://git.kernel.org/stable/c/464ea494a40c6e3e0e8f91dd325408aaf21515ba
- https://git.kernel.org/stable/c/4f90a8b0481615622bd0558aa8cf361bea872045
- https://git.kernel.org/stable/c/5a52a2e14fe866541bbc0033058e44bf0bf0c580
- https://git.kernel.org/stable/c/af7affc0f6b82a5bde430fc4f0dcf70963442fbc
- https://git.kernel.org/stable/c/ce2cdbe530b0066bae1f98dbab590a232d507eaa
- https://git.kernel.org/stable/c/ee4c9a93238b9ce3703942500cb1aeacf77090d2
Modified: 2026-01-16
CVE-2023-53452
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: fix potential race condition between napi_init and napi_enable
A race condition can happen if netdev is registered, but NAPI isn't
initialized yet, and meanwhile user space starts the netdev that will
enable NAPI. Then, it hits BUG_ON():
kernel BUG at net/core/dev.c:6423!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91
Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022
RIP: 0010:napi_enable+0x3f/0x50
Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ...
RSP: 0018:ffffada1414f3548 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000
RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58
R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001
FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
Modified: 2026-01-16
CVE-2023-53453
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: free iio for atombios when driver shutdown Fix below kmemleak when unload radeon driver: unreferenced object 0xffff9f8608ede200 (size 512): comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s) hex dump (first 32 bytes): 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500 [<00000000b6883cea>] atom_parse+0x117/0x230 [radeon] [<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon] [<00000000683f672e>] si_init+0x57/0x750 [radeon] [<00000000566cc31f>] radeon_device_init+0x559/0x9c0 [radeon] [<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon] [<00000000b5155064>] drm_dev_register+0xdd/0x1d0 [<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon] [<00000000e69ecca3>] pci_device_probe+0xe1/0x160 [<0000000019484b76>] really_probe.part.0+0xc1/0x2c0 [<000000003f2649da>] __driver_probe_device+0x96/0x130 [<00000000231c5bb1>] driver_probe_device+0x24/0xf0 [<0000000000a42377>] __driver_attach+0x77/0x190 [<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0 [<00000000633166d2>] driver_attach+0x1e/0x30 [<00000000313b05b8>] bus_add_driver+0x12c/0x1e0 iio was allocated in atom_index_iio() called by atom_parse(), but it doesn't got released when the dirver is shutdown. Fix this kmemleak by free it in radeon_atombios_fini().
- https://git.kernel.org/stable/c/107b8b542bb9dab4cbdc3276c85fbdd7f6782313
- https://git.kernel.org/stable/c/4773fadedca918faec443daaca5e4ea1c0ced144
- https://git.kernel.org/stable/c/9cdb96b55651c92fc949cfd54124406c3c912b6b
- https://git.kernel.org/stable/c/cb109cedbba11c33473e6780c256d8442a9e4460
- https://git.kernel.org/stable/c/cda2f7efbc2d857220dad32e315a54565b285c1c
- https://git.kernel.org/stable/c/ce9e9d3dcbb0d1551ffd1a7f16e7c051f3ba4140
- https://git.kernel.org/stable/c/e2791f2f4d1d804e45fa91b14295c326b64c65f1
- https://git.kernel.org/stable/c/f9f55fc64928b5e30d78f861c5fc76db9e769ebb
Modified: 2026-01-16
CVE-2023-53454
In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.
- https://git.kernel.org/stable/c/15ec7cb55e7d88755aa01d44a7a1015a42bfce86
- https://git.kernel.org/stable/c/1d7833db9fd118415dace2ca157bfa603dec9c8c
- https://git.kernel.org/stable/c/2763732ec1e68910719c75b6b896e11b6d3d622b
- https://git.kernel.org/stable/c/39c70c19456e50dcb3abfe53539220dff0490f1d
- https://git.kernel.org/stable/c/4794394635293a3e74591351fff469cea7ad15a2
- https://git.kernel.org/stable/c/ac0d389402a6ff9ad92cea02c2d8c711483b91ab
- https://git.kernel.org/stable/c/b70ac7849248ec8128fa12f86e3655ba38838f29
- https://git.kernel.org/stable/c/dde88ab4e45beb60b217026207aa9c14c88d71ab
- https://git.kernel.org/stable/c/df7ca43fe090e1a56c216c8ebc106ef5fd49afc6
Modified: 2026-01-16
CVE-2023-53455
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: drop all currently held locks if deadlock happens
If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock
happened in the locking context. This situation should be addressed by
dropping all currently held locks and block until the contended lock
becomes available. Currently, vc4 is not dealing with the deadlock
properly, producing the following output when PROVE_LOCKING is enabled:
[ 825.612809] ------------[ cut here ]------------
[ 825.612852] WARNING: CPU: 1 PID: 116 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm]
[ 825.613458] Modules linked in: 8021q mrp garp stp llc
raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211
btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec
clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill
drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng
rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6
[ 825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G W 6.1.0-rc6-01399-g941aae326315 #3
[ 825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[ 825.613777] Workqueue: events output_poll_execute [drm_kms_helper]
[ 825.614038] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm]
[ 825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]
[ 825.614829] sp : ffff800008313bf0
[ 825.614844] x29: ffff800008313bf0 x28: ffffcd7778b8b000 x27: 0000000000000000
[ 825.614883] x26: 0000000000000001 x25: 0000000000000001 x24: ffff677cc35c2758
[ 825.614920] x23: ffffcd7707d01430 x22: ffffcd7707c3edc7 x21: 0000000000000001
[ 825.614958] x20: 0000000000000000 x19: ffff800008313c10 x18: 000000000000b6d3
[ 825.614995] x17: ffffcd777835e214 x16: ffffcd7777cef870 x15: fffff81000000000
[ 825.615033] x14: 0000000000000000 x13: 0000000000000099 x12: 0000000000000002
[ 825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800
[ 825.615108] x8 : ffff677cc665e0a8 x7 : d00a8c180000110c x6 : ffffcd77774c0054
[ 825.615145] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
[ 825.615181] x2 : ffff677cc55e1880 x1 : ffffcd7777cef8ec x0 : ffff800008313c10
[ 825.615219] Call trace:
[ 825.615232] drm_modeset_drop_locks+0x60/0x68 [drm]
[ 825.615773] drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]
[ 825.616003] output_poll_execute+0xe4/0x224 [drm_kms_helper]
[ 825.616233] process_one_work+0x2b4/0x618
[ 825.616264] worker_thread+0x24c/0x464
[ 825.616288] kthread+0xec/0x110
[ 825.616310] ret_from_fork+0x10/0x20
[ 825.616335] irq event stamp: 7634
[ 825.616349] hardirqs last enabled at (7633): [
Modified: 2026-01-16
CVE-2023-53456
In the Linux kernel, the following vulnerability has been resolved: scsi: qla4xxx: Add length check when parsing nlattrs There are three places that qla4xxx parses nlattrs: - qla4xxx_set_chap_entry() - qla4xxx_iface_set_param() - qla4xxx_sysfs_ddb_set_param() and each of them directly converts the nlattr to specific pointer of structure without length checking. This could be dangerous as those attributes are not validated and a malformed nlattr (e.g., length 0) could result in an OOB read that leaks heap dirty data. Add the nla_len check before accessing the nlattr data and return EINVAL if the length check fails.
- https://git.kernel.org/stable/c/25feffb3fbd51ae81d92c65cebc0e932663828b3
- https://git.kernel.org/stable/c/47cd3770e31df942e2bb925a9a855c79ed0662eb
- https://git.kernel.org/stable/c/47f3be62eab50b8cd7e1ae5fc2c4dae687497c34
- https://git.kernel.org/stable/c/4ed21975311247bb84e82298eeb359ec0a0fa84d
- https://git.kernel.org/stable/c/5925e224cc6edfef57b20447f18323208461309b
- https://git.kernel.org/stable/c/6d65079c69dc1feb817ed71f5bd15e83a7d6832d
- https://git.kernel.org/stable/c/b018c0440b871d8b001c996e95fa4538bd292de6
- https://git.kernel.org/stable/c/cfa6a1a79ed6d336fac7a5d87eb5471e4401829f
- https://git.kernel.org/stable/c/f61fc650c47849637fa1771a31a11674c824138a
Modified: 2026-01-16
CVE-2023-53457
In the Linux kernel, the following vulnerability has been resolved: FS: JFS: Fix null-ptr-deref Read in txBegin Syzkaller reported an issue where txBegin may be called on a superblock in a read-only mounted filesystem which leads to NULL pointer deref. This could be solved by checking if the filesystem is read-only before calling txBegin, and returning with appropiate error code.
- https://git.kernel.org/stable/c/1b4c144767736221cad92c132f72b3c6ed06a0ea
- https://git.kernel.org/stable/c/2a3f20efe6c901d4c0871cfd1d8c65e2ade71fc1
- https://git.kernel.org/stable/c/3e5eb6c5ecd8ddb9cfea751cf30f9e23eac97ca3
- https://git.kernel.org/stable/c/3e94d0d378d2754b26fc54b429582553f7b53e15
- https://git.kernel.org/stable/c/47cfdc338d674d38f4b2f22b7612cc6a2763ba27
- https://git.kernel.org/stable/c/a7225e9e09519deb7e0c42eb6070029cc456e84d
- https://git.kernel.org/stable/c/a7d17d6bd7cd4f6940b335ea7a6fce5b6d22adc2
- https://git.kernel.org/stable/c/fd2db13fb72ff18c633a48229589d42ceb89d1f8
Modified: 2026-01-16
CVE-2023-53458
In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Fix a null-ptr-deref bug in buffer_prepare() and buffer_finish() When the driver calls cx23885_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer risc->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of cx23885_risc_buffer() and the value of risc->cpu before buffer free.
Modified: 2026-01-16
CVE-2023-53461
In the Linux kernel, the following vulnerability has been resolved: io_uring: wait interruptibly for request completions on exit WHen the ring exits, cleanup is done and the final cancelation and waiting on completions is done by io_ring_exit_work. That function is invoked by kworker, which doesn't take any signals. Because of that, it doesn't really matter if we wait for completions in TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state. However, it does matter to the hung task detection checker! Normally we expect cancelations and completions to happen rather quickly. Some test cases, however, will exit the ring and park the owning task stopped (eg via SIGSTOP). If the owning task needs to run task_work to complete requests, then io_ring_exit_work won't make any progress until the task is runnable again. Hence io_ring_exit_work can trigger the hung task detection, which is particularly problematic if panic-on-hung-task is enabled. As the ring exit doesn't take signals to begin with, have it wait interruptibly rather than uninterruptibly. io_uring has a separate stuck-exit warning that triggers independently anyway, so we're not really missing anything by making this switch.
- https://git.kernel.org/stable/c/28e649dc9947e6525c95e32aa9a8e147925e3f56
- https://git.kernel.org/stable/c/4826c59453b3b4677d6bf72814e7ababdea86949
- https://git.kernel.org/stable/c/58e80cb68b057e974768792c34708c6957810486
- https://git.kernel.org/stable/c/8e29835366138389bfad3b31ea06960d0a77bf77
- https://git.kernel.org/stable/c/b50d6e06cca7b67a3d73ca660dda27662b76e6ea
Modified: 2026-01-16
CVE-2023-53462
In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in fill_frame_info() Syzbot reports the following uninit-value access problem. ===================================================== BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 It is because VLAN not yet supported in hsr driver. Return error when protocol is ETH_P_8021Q in fill_frame_info() now to fix it.
- https://git.kernel.org/stable/c/1e90a93ac4845c31724ec5dc96fb51e608435a9d
- https://git.kernel.org/stable/c/484b4833c604c0adcf19eac1ca14b60b757355b5
- https://git.kernel.org/stable/c/61866f7d814e5792bf47410d7d3ff32e49bd292a
- https://git.kernel.org/stable/c/6a4480c5e6ebaf9f797ac300e2a97a02d4e70cfd
- https://git.kernel.org/stable/c/ed7a0ba7e840dc5d54cdbd8466be27e6aedce1e5
Modified: 2026-01-16
CVE-2023-53463
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Do not reset dql stats on NON_FATAL err All ibmvnic resets, make a call to netdev_tx_reset_queue() when re-opening the device. netdev_tx_reset_queue() resets the num_queued and num_completed byte counters. These stats are used in Byte Queue Limit (BQL) algorithms. The difference between these two stats tracks the number of bytes currently sitting on the physical NIC. ibmvnic increases the number of queued bytes though calls to netdev_tx_sent_queue() in the drivers xmit function. When, VIOS reports that it is done transmitting bytes, the ibmvnic device increases the number of completed bytes through calls to netdev_tx_completed_queue(). It is important to note that the driver batches its transmit calls and num_queued is increased every time that an skb is added to the next batch, not necessarily when the batch is sent to VIOS for transmission. Unlike other reset types, a NON FATAL reset will not flush the sub crq tx buffers. Therefore, it is possible for the batched skb array to be partially full. So if there is call to netdev_tx_reset_queue() when re-opening the device, the value of num_queued (0) would not account for the skb's that are currently batched. Eventually, when the batch is sent to VIOS, the call to netdev_tx_completed_queue() would increase num_completed to a value greater than the num_queued. This causes a BUG_ON crash: ibmvnic 30000002: Firmware reports error, cause: adapter problem. Starting recovery... ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ------------[ cut here ]------------ kernel BUG at lib/dynamic_queue_limits.c:27! Oops: Exception in kernel mode, sig: 5 [....] NIP dql_completed+0x28/0x1c0 LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic] Call Trace: ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable) ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic] __handle_irq_event_percpu+0x98/0x270 ---[ end trace ]--- Therefore, do not reset the dql stats when performing a NON_FATAL reset.
Modified: 2026-01-20
CVE-2023-53464
In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param() The validity of sock should be checked before assignment to avoid incorrect values. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()") introduced this change which may lead to inconsistent values of tcp_sw_conn->sendpage and conn->datadgst_en. Fix the issue by moving the position of the assignment.
- https://git.kernel.org/stable/c/48b19b79cfa37b1e50da3b5a8af529f994c08901
- https://git.kernel.org/stable/c/499757ad3332e2527254f9ab68dec1da087b1d96
- https://git.kernel.org/stable/c/5e5c5f472972c4bc9430adc08b36763a0fa5b9f7
- https://git.kernel.org/stable/c/6e06a68fbbfcd8576eee8f7139fa2b13c9b72e91
- https://git.kernel.org/stable/c/b287e21e73ec23f3788fbe40037c42dbe6e9a9a9
Modified: 2026-01-20
CVE-2023-53465
In the Linux kernel, the following vulnerability has been resolved: soundwire: qcom: fix storing port config out-of-bounds The 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14), however we index it starting from 1, not 0, to match real port numbers. This can lead to writing port config past 'pconfig' bounds and overwriting next member of 'qcom_swrm_ctrl' struct. Reported also by smatch: drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14
Modified: 2026-01-20
CVE-2023-53466
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit Always purge mcu skb queues in mt7915_mcu_exit routine even if mt7915_firmware_state fails.
Modified: 2026-01-20
CVE-2023-53467
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix potential leak in rtw89_append_probe_req_ie() Do `kfree_skb(new)` before `goto out` to prevent potential leak.
Modified: 2026-01-20
CVE-2023-53468
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix memory leak in alloc_wbufs()
kmemleak reported a sequence of memory leaks, and show them as following:
unreferenced object 0xffff8881575f8400 (size 1024):
comm "mount", pid 19625, jiffies 4297119604 (age 20.383s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/1f206002c6bc302bface871ef3f72c0bbcaa931c
- https://git.kernel.org/stable/c/26ec45f1c504e15268383019df139d7983f1e67f
- https://git.kernel.org/stable/c/3e29634eb56e6547272fe4e568f63421f8b3b9fa
- https://git.kernel.org/stable/c/4a1ff3c5d04b9079b4f768d9a71b51c4af578dd2
- https://git.kernel.org/stable/c/bf50229494f0443b3f08427d7df63e5a7e2a796a
- https://git.kernel.org/stable/c/e11f36d3bc4d23f620754a948fe7b82b63dcb185
Modified: 2026-01-20
CVE-2023-53470
In the Linux kernel, the following vulnerability has been resolved: ionic: catch failure from devlink_alloc Add a check for NULL on the alloc return. If devlink_alloc() fails and we try to use devlink_priv() on the NULL return, the kernel gets very unhappy and panics. With this fix, the driver load will still fail, but at least it won't panic the kernel.
- https://git.kernel.org/stable/c/0020c16c8af7f4bc9503a2088fb30793b6771fac
- https://git.kernel.org/stable/c/0d02efe7f25158c93146e3bb827bc7bb3cd5e71a
- https://git.kernel.org/stable/c/4a54903ff68ddb33b6463c94b4eb37fc584ef760
- https://git.kernel.org/stable/c/5325f50de5b1433b27dda7ccff5cb7283722a3f1
- https://git.kernel.org/stable/c/c177dd465f5c1e5f242cdb9258826c591c257e9a
Modified: 2026-01-20
CVE-2023-53471
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras
gfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert.
So in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq
should be executed under such condition, otherwise, an amdgpu_irq_put
calltrace will occur.
[ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
[ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246
[ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: 0000000000000000
[ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000
[ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: 0000000000000006
[ 7283.170973] R10: ffffd5764243c008 R11: 0000000000000000 R12: 0000000000001050
[ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
[ 7283.170978] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
[ 7283.170981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
[ 7283.170986] Call Trace:
[ 7283.170988]
- https://git.kernel.org/stable/c/20ca90ceda71ed90a4d6960acbe7d5e120b40c0d
- https://git.kernel.org/stable/c/3d28af21a874c5123d1681c2d686627f7ff7e488
- https://git.kernel.org/stable/c/4a76680311330aefe5074bed8f06afa354b85c48
- https://git.kernel.org/stable/c/625d4112ea25dbad7ddf749fd5c1287ceffb2339
- https://git.kernel.org/stable/c/cd3c0f7013c37cd24fc40b601319007f136c1201
- https://git.kernel.org/stable/c/efce310db74fdc6d2acd959f3582972ae4a8d7d5
- https://git.kernel.org/stable/c/f661ad53658a1ea35c004af1f5fbe25c4d1cdb08
Modified: 2026-01-20
CVE-2023-53472
In the Linux kernel, the following vulnerability has been resolved: pwm: lpc32xx: Remove handling of PWM channels Because LPC32xx PWM controllers have only a single output which is registered as the only PWM device/channel per controller, it is known in advance that pwm->hwpwm value is always 0. On basis of this fact simplify the code by removing operations with pwm->hwpwm, there is no controls which require channel number as input. Even though I wasn't aware at the time when I forward ported that patch, this fixes a null pointer dereference as lpc32xx->chip.pwms is NULL before devm_pwmchip_add() is called.
- https://git.kernel.org/stable/c/04301da4d87067a989f70ee56942bf9d97cd2a45
- https://git.kernel.org/stable/c/4aae44f65827f0213a7361cf9c32cfe06114473f
- https://git.kernel.org/stable/c/523f6268e86552a048975749251184c4e9a4b38f
- https://git.kernel.org/stable/c/5e22217c11424ef958ba28d03ff7167b4d7a8914
- https://git.kernel.org/stable/c/a2d9d884e84bfd37892219b1f55847f36d8e9901
- https://git.kernel.org/stable/c/a9a505f5b39d8fff1a55963a5e524c84639e98b2
- https://git.kernel.org/stable/c/abd9b2ee4047ccd980decbf26d61f9637604b1d5
- https://git.kernel.org/stable/c/e3a0ddbaf7f1f9ffc070718b417461ced3268758
Modified: 2026-01-20
CVE-2023-53473
In the Linux kernel, the following vulnerability has been resolved: ext4: improve error handling from ext4_dirhash() The ext4_dirhash() will *almost* never fail, especially when the hash tree feature was first introduced. However, with the addition of support of encrypted, casefolded file names, that function can most certainly fail today. So make sure the callers of ext4_dirhash() properly check for failures, and reflect the errors back up to their callers.
- https://git.kernel.org/stable/c/4b3cb1d108bfc2aebb0d7c8a52261a53cf7f5786
- https://git.kernel.org/stable/c/70d579aefa652a06af97e013e3fbbabbe5a43553
- https://git.kernel.org/stable/c/b2531936118deb3f479c4fa1bcd787b74b8faa6a
- https://git.kernel.org/stable/c/c1fae027da61fe8e7eb99f7244297e81bc0f1e43
- https://git.kernel.org/stable/c/f68876aeef96ef8b708ab10b9cb47ce0a5adb424
Modified: 2026-01-20
CVE-2023-53474
In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Use an u64 for bank_map Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64"). However, the bank_map which contains a bitfield of which banks to initialize is of type unsigned int and that overflows when those bit numbers are >= 32, leading to UBSAN complaining correctly: UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38 shift exponent 32 is too large for 32-bit type 'int' Change the bank_map to a u64 and use the proper BIT_ULL() macro when modifying bits in there. [ bp: Rewrite commit message. ]
- https://git.kernel.org/stable/c/11c58a0c1937c157dbdf82d5ab634d68c99f3098
- https://git.kernel.org/stable/c/4c1cdec319b9aadb65737c3eb1f5cb74bd6aa156
- https://git.kernel.org/stable/c/67bb7521b6420d81dab7538c0686f18f7d6d09f4
- https://git.kernel.org/stable/c/9669fa17287c3af2bbd4868d4c8fdd9e57f8332e
- https://git.kernel.org/stable/c/a9b9ea0e63a0ec5e97bf1219ab6dcbd55e362f83
- https://git.kernel.org/stable/c/ba8ffb1251eb629c2ec35220e3896cf4f7b888a7
Modified: 2026-01-20
CVE-2023-53475
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: tegra: fix sleep in atomic call When we set the dual-role port to Host mode, we observed the following splat: [ 167.057718] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:229 [ 167.057872] Workqueue: events tegra_xusb_usb_phy_work [ 167.057954] Call trace: [ 167.057962] dump_backtrace+0x0/0x210 [ 167.057996] show_stack+0x30/0x50 [ 167.058020] dump_stack_lvl+0x64/0x84 [ 167.058065] dump_stack+0x14/0x34 [ 167.058100] __might_resched+0x144/0x180 [ 167.058140] __might_sleep+0x64/0xd0 [ 167.058171] slab_pre_alloc_hook.constprop.0+0xa8/0x110 [ 167.058202] __kmalloc_track_caller+0x74/0x2b0 [ 167.058233] kvasprintf+0xa4/0x190 [ 167.058261] kasprintf+0x58/0x90 [ 167.058285] tegra_xusb_find_port_node.isra.0+0x58/0xd0 [ 167.058334] tegra_xusb_find_port+0x38/0xa0 [ 167.058380] tegra_xusb_padctl_get_usb3_companion+0x38/0xd0 [ 167.058430] tegra_xhci_id_notify+0x8c/0x1e0 [ 167.058473] notifier_call_chain+0x88/0x100 [ 167.058506] atomic_notifier_call_chain+0x44/0x70 [ 167.058537] tegra_xusb_usb_phy_work+0x60/0xd0 [ 167.058581] process_one_work+0x1dc/0x4c0 [ 167.058618] worker_thread+0x54/0x410 [ 167.058650] kthread+0x188/0x1b0 [ 167.058672] ret_from_fork+0x10/0x20 The function tegra_xusb_padctl_get_usb3_companion eventually calls tegra_xusb_find_port and this in turn calls kasprintf which might sleep and so cannot be called from an atomic context. Fix this by moving the call to tegra_xusb_padctl_get_usb3_companion to the tegra_xhci_id_work function where it is really needed.
- https://git.kernel.org/stable/c/1122474b757a5dd8b2b50008a97f33cdb10dff6e
- https://git.kernel.org/stable/c/130c61c516cd0684282a8f6ab163281d60642fc5
- https://git.kernel.org/stable/c/1fe6015aa92cc0dfd875c1d3c7c1750a1b0767d9
- https://git.kernel.org/stable/c/4c7f9d2e413dc06a157c4e5dccde84aaf4655eb3
- https://git.kernel.org/stable/c/b4b4f17aa46c025da77aed5133b08971959c9684
Modified: 2026-01-20
CVE-2023-53476
In the Linux kernel, the following vulnerability has been resolved: iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry() This condition needs to match the previous "if (epcp->state == LISTEN) {" exactly to avoid a NULL dereference of either "listen_ep" or "ep". The problem is that "epcp" has been re-assigned so just testing "if (epcp->state == LISTEN) {" a second time is not sufficient.
Modified: 2026-01-20
CVE-2023-53477
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Add lwtunnel encap size of all siblings in nexthop calculation
In function rt6_nlmsg_size(), the length of nexthop is calculated
by multipling the nexthop length of fib6_info and the number of
siblings. However if the fib6_info has no lwtunnel but the siblings
have lwtunnels, the nexthop length is less than it should be, and
it will trigger a warning in inet6_rt_notify() as follows:
WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130
......
Call Trace:
- https://git.kernel.org/stable/c/4cc59f386991ec9374cb4bc83dbe1c0b5a95033f
- https://git.kernel.org/stable/c/aa75d826c221e8d48607aef33836cf872a159cf1
- https://git.kernel.org/stable/c/aba298b35619213ca787d08d472049627d8cd012
- https://git.kernel.org/stable/c/da26369377f0b671c14692e2d65ceb38131053e1
- https://git.kernel.org/stable/c/dcdddb5f490890d058ea1f194d661219e92fe88d
- https://git.kernel.org/stable/c/e11e4d524eba2d3c8fdf897d7ce3853f7573bae9
Modified: 2026-01-20
CVE-2023-53478
In the Linux kernel, the following vulnerability has been resolved: tracing/synthetic: Fix races on freeing last_cmd Currently, the "last_cmd" variable can be accessed by multiple processes asynchronously when multiple users manipulate synthetic_events node at the same time, it could lead to use-after-free or double-free. This patch add "lastcmd_mutex" to prevent "last_cmd" from being accessed asynchronously. ================================================================ It's easy to reproduce in the KASAN environment by running the two scripts below in different shells. script 1: while : do echo -n -e '\x88' > /sys/kernel/tracing/synthetic_events done script 2: while : do echo -n -e '\xb0' > /sys/kernel/tracing/synthetic_events done ================================================================ double-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.free last_cmd 3.free last_cmd(double-free) ================================================================ use-after-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.free last_cmd 3.tracing_log_err(use-after-free) ================================================================ Appendix 1. KASAN report double-free: BUG: KASAN: double-free in kfree+0xdc/0x1d4 Free of addr ***** by task sh/4879 Call trace: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x60/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Allocated by task 4879: ... kstrdup+0x5c/0x98 create_or_delete_synth_event+0x6c/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by task 5464: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x60/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... ================================================================ Appendix 2. KASAN report use-after-free: BUG: KASAN: use-after-free in strlen+0x5c/0x7c Read of size 1 at addr ***** by task sh/5483 sh: CPU: 7 PID: 5483 Comm: sh ... __asan_report_load1_noabort+0x34/0x44 strlen+0x5c/0x7c tracing_log_err+0x60/0x444 create_or_delete_synth_event+0xc4/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Allocated by task 5483: ... kstrdup+0x5c/0x98 create_or_delete_synth_event+0x80/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by task 5480: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x74/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ...
Modified: 2026-01-20
CVE-2023-53479
In the Linux kernel, the following vulnerability has been resolved: cxl/acpi: Fix a use-after-free in cxl_parse_cfmws() KASAN and KFENCE detected an user-after-free in the CXL driver. This happens in the cxl_decoder_add() fail path. KASAN prints the following error: BUG: KASAN: slab-use-after-free in cxl_parse_cfmws (drivers/cxl/acpi.c:299) This happens in cxl_parse_cfmws(), where put_device() is called, releasing cxld, which is accessed later. Use the local variables in the dev_err() instead of pointing to the released memory. Since the dev_err() is printing a resource, change the open coded print format to use the %pr format specifier.
Modified: 2026-01-23
CVE-2023-53480
In the Linux kernel, the following vulnerability has been resolved: kobject: Add sanity check for kset->kobj.ktype in kset_register() When I register a kset in the following way: static struct kset my_kset; kobject_set_name(&my_kset.kobj, "my_kset"); ret = kset_register(&my_kset); A null pointer dereference exception is occurred: [ 4453.568337] Unable to handle kernel NULL pointer dereference at \ virtual address 0000000000000028 ... ... [ 4453.810361] Call trace: [ 4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add_internal+0x98/0x274 [ 4453.822005] kset_register+0x5c/0xb4 [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset] ... ... Because I didn't initialize my_kset.kobj.ktype. According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype. So add sanity check to make sure kset->kobj.ktype is not NULL.
- https://git.kernel.org/stable/c/039ec9db2d30032eafa365f5f89b30eca5322b05
- https://git.kernel.org/stable/c/1a772881bc059c596d8ca587cbd2a233edce3d3b
- https://git.kernel.org/stable/c/48aebbe801e78a8932404c122ed0e880ccedc220
- https://git.kernel.org/stable/c/4d0fe8c52bb3029d83e323c961221156ab98680b
- https://git.kernel.org/stable/c/5df5829158513134ddcaf2184d9286eda7b0bb18
- https://git.kernel.org/stable/c/964e025ceefdf75da46b0133d0c2790de451aeec
- https://git.kernel.org/stable/c/f3f6bf22a4f5ba649cf26ae4670de5c7f861bdef
Modified: 2026-01-20
CVE-2023-53481
In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed Following process will trigger an infinite loop in ubi_wl_put_peb(): ubifs_bgt ubi_bgt ubifs_leb_unmap ubi_leb_unmap ubi_eba_unmap_leb ubi_wl_put_peb wear_leveling_worker e1 = rb_entry(rb_first(&ubi->used) e2 = get_peb_for_wl(ubi) ubi_io_read_vid_hdr // return err (flash fault) out_error: ubi->move_from = ubi->move_to = NULL wl_entry_destroy(ubi, e1) ubi->lookuptbl[e->pnum] = NULL retry: e = ubi->lookuptbl[pnum]; // return NULL if (e == ubi->move_from) { // NULL == NULL gets true goto retry; // infinite loop !!! $ top PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND 7676 root 20 0 0 0 0 R 100.0 0.0 ubifs_bgt0_0 Fix it by: 1) Letting ubi_wl_put_peb() returns directly if wearl leveling entry has been removed from 'ubi->lookuptbl'. 2) Using 'ubi->wl_lock' protecting wl entry deletion to preventing an use-after-free problem for wl entry in ubi_wl_put_peb(). Fetch a reproducer in [Link].
- https://git.kernel.org/stable/c/3afaaf6f5867dc4ad383808d4053f428ec7b867d
- https://git.kernel.org/stable/c/4d57a7333e26040f2b583983e1970d9d460e56b0
- https://git.kernel.org/stable/c/5af1c643184a5d09ff5b3f334077a4d0a163c677
- https://git.kernel.org/stable/c/8a18856e074479bd050b01e688c58defadce7ab0
- https://git.kernel.org/stable/c/b40d2fbf47af58377e898b5062077a47bb28a132
- https://git.kernel.org/stable/c/b5be23f6ae610bdb262160a1f294afee6d0e6a69
- https://git.kernel.org/stable/c/cc4bc532acda66189bddc03b3fe1ad689d9a48a2
- https://git.kernel.org/stable/c/f006f596fe851c3b6aae60b79f89f89f0e515d2f
Modified: 2026-01-20
CVE-2023-53482
In the Linux kernel, the following vulnerability has been resolved: iommu: Fix error unwind in iommu_group_alloc() If either iommu_group_grate_file() fails then the iommu_group is leaked. Destroy it on these error paths. Found by kselftest/iommu/iommufd_fail_nth
Modified: 2026-01-23
CVE-2023-53483
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Check for null return of devm_kzalloc() in fch_misc_setup() devm_kzalloc() may fail, clk_data->name might be NULL and will cause a NULL pointer dereference later. [ rjw: Subject and changelog edits ]
Modified: 2026-01-20
CVE-2023-53484
In the Linux kernel, the following vulnerability has been resolved: lib: cpu_rmap: Avoid use after free on rmap->obj array entries When calling irq_set_affinity_notifier() with NULL at the notify argument, it will cause freeing of the glue pointer in the corresponding array entry but will leave the pointer in the array. A subsequent call to free_irq_cpu_rmap() will try to free this entry again leading to possible use after free. Fix that by setting NULL to the array entry and checking that we have non-zero at the array entry when iterating over the array in free_irq_cpu_rmap(). The current code does not suffer from this since there are no cases where irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the notify arg) is called, followed by a call to free_irq_cpu_rmap() so we don't hit and issue. Subsequent patches in this series excersize this flow, hence the required fix.
- https://git.kernel.org/stable/c/4e0473f1060aa49621d40a113afde24818101d37
- https://git.kernel.org/stable/c/67bca5f1d644f4e79b694abd8052a177de81c37f
- https://git.kernel.org/stable/c/981f339d2905b6a92ef59358158b326493aecac5
- https://git.kernel.org/stable/c/c6ed54dd90698dc0744d669524cc1c122ded8a16
- https://git.kernel.org/stable/c/c9115f49cf260d24d8b5f2d9a4b63cb31a627bb4
- https://git.kernel.org/stable/c/cc2d2b3dbfb0ba57bc027fb7e1121250c50e4000
- https://git.kernel.org/stable/c/d1308bd0b24cb1d78fa2747d5fa3e055cc628a48
- https://git.kernel.org/stable/c/f748e15253833b771acbede14ea98f50831ac289
Modified: 2026-01-23
CVE-2023-53485
In the Linux kernel, the following vulnerability has been resolved:
fs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:1965:6
index -84 is out of range for type 's8[341]' (aka 'signed char[341]')
CPU: 1 PID: 4995 Comm: syz-executor146 Not tainted 6.4.0-rc6-syzkaller-00037-gb6dad5178cea #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
- https://git.kernel.org/stable/c/0d9e678a82915633b99603f744e7735d1a673d72
- https://git.kernel.org/stable/c/39f6292d75959e8accac0b3e24090094ba0824e9
- https://git.kernel.org/stable/c/4e302336d5ca1767a06beee7596a72d3bdc8d983
- https://git.kernel.org/stable/c/53b0a362aca2583729e8ca2936ca657ff3247d88
- https://git.kernel.org/stable/c/6e7d9d76e5654bcdd3cdb7c9441a8113428ecebb
- https://git.kernel.org/stable/c/911b48eec45152822bccf45cd3563b48256b1520
- https://git.kernel.org/stable/c/bdf07ab1595b613b03f32dbb5cb379edfa1a7334
- https://git.kernel.org/stable/c/f2af019091f904ca08b3572ab0111238ad6d17b3
Modified: 2026-01-20
CVE-2023-53487
In the Linux kernel, the following vulnerability has been resolved:
powerpc/rtas_flash: allow user copy to flash block cache objects
With hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the
/proc/powerpc/rtas/firmware_update interface to prepare a system
firmware update yields a BUG():
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 2232 Comm: dd Not tainted 6.5.0-rc3+ #2
Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 of:IBM,FW860.50 (SV860_146) hv:phyp pSeries
NIP: c0000000005991d0 LR: c0000000005991cc CTR: 0000000000000000
REGS: c0000000148c76a0 TRAP: 0700 Not tainted (6.5.0-rc3+)
MSR: 8000000000029033
- https://git.kernel.org/stable/c/0ba7f969be599e21d4b1f1e947593de6515f4996
- https://git.kernel.org/stable/c/1d29e21ed09fa668416fa7721e08d451b9903485
- https://git.kernel.org/stable/c/4f3175979e62de3b929bfa54a0db4b87d36257a7
- https://git.kernel.org/stable/c/6acb8a453388374fafb3c3b37534b675b2aa0ae1
- https://git.kernel.org/stable/c/8ef25fb13494e35c6dbe15445c7875fa92bc3e8b
- https://git.kernel.org/stable/c/8f09cc15dcd91d16562400c51d24c7be0d5796fa
- https://git.kernel.org/stable/c/b8fee83aa4ed3846c7f50a0b364bc699f48d96e5
Modified: 2026-01-21
CVE-2023-53488
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix possible panic during hotplug remove During hotplug remove it is possible that the update counters work might be pending, and may run after memory has been freed. Cancel the update counters work before freeing memory.
- https://git.kernel.org/stable/c/33c677d1e087e437c7dcaad8d73402cf6add282e
- https://git.kernel.org/stable/c/4fdfaef71fced490835145631a795497646f4555
- https://git.kernel.org/stable/c/5e72f33ddfdb69cb21c1b59d31bbd3498d31b14a
- https://git.kernel.org/stable/c/918c1e6843b7e81d0e5cf7994f41f28dc34c98b0
- https://git.kernel.org/stable/c/ac6640f4193d0f5b44269a7f08372909f9a18e5c
- https://git.kernel.org/stable/c/bfd727ad8411995218f336ead9f2becfde7f3a89
- https://git.kernel.org/stable/c/c2145b18740c7e697748e4005ce93a5c683c86a8
- https://git.kernel.org/stable/c/d32a5e9b825d40c08a43dfbcba007159fed41a5d
Modified: 2026-01-21
CVE-2023-53489
In the Linux kernel, the following vulnerability has been resolved: tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp. syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY skbs. We can reproduce the problem with these sequences: sk = socket(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53)) sk.close() sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets skb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, struct ubuf_info_msgzc indirectly holds a refcnt of the socket. When the skb is sent, __skb_tstamp_tx() clones it and puts the clone into the socket's error queue with the TX timestamp. When the original skb is received locally, skb_copy_ubufs() calls skb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt. This additional count is decremented while freeing the skb, but struct ubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is not called. The last refcnt is not released unless we retrieve the TX timestamped skb by recvmsg(). Since we clear the error queue in inet_sock_destruct() after the socket's refcnt reaches 0, there is a circular dependency. If we close() the socket holding such skbs, we never call sock_put() and leak the count, sk, and skb. TCP has the same problem, and commit e0c8bccd40fc ("net: stream: purge sk_error_queue in sk_stream_kill_queues()") tried to fix it by calling skb_queue_purge() during close(). However, there is a small chance that skb queued in a qdisc or device could be put into the error queue after the skb_queue_purge() call. In __skb_tstamp_tx(), the cloned skb should not have a reference to the ubuf to remove the circular dependency, but skb_clone() does not call skb_copy_ubufs() for zerocopy skb. So, we need to call skb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs(). [0]: BUG: memory leak unreferenced object 0xffff88800c6d2d00 (size 1152): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................ 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline] [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd BUG: memory leak unreferenced object 0xffff888017633a00 (size 240): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m..... backtrace: [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>] ---truncated---
- https://git.kernel.org/stable/c/1f69c086b20e27763af28145981435423f088268
- https://git.kernel.org/stable/c/230a5ed7d813fb516de81d23f09d7506753e41e9
- https://git.kernel.org/stable/c/281072fb2a7294cde7acbf5375b879f40a8001b7
- https://git.kernel.org/stable/c/30290f210ba7426ff7592fe2eb4114b1b5bad219
- https://git.kernel.org/stable/c/426384dd4980040651536fef5feac4dcc4d7ee4e
- https://git.kernel.org/stable/c/43e4197dd5f6b474a8b16f8b6a42cd45cf4f9d1a
- https://git.kernel.org/stable/c/50749f2dd6854a41830996ad302aef2ffaf011d8
- https://git.kernel.org/stable/c/602fa8af44fd55a58f9e94eb673e8adad2c6cc46
- https://git.kernel.org/stable/c/cb52e7f24c1d01a536a847dff0d1d95889cc3b5c
Modified: 2026-01-16
CVE-2023-53492
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: do not ignore genmask when looking up chain by id
When adding a rule to a chain referring to its ID, if that chain had been
deleted on the same batch, the rule might end up referring to a deleted
chain.
This will lead to a WARNING like following:
[ 33.098431] ------------[ cut here ]------------
[ 33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260
[ 33.099217] Modules linked in:
[ 33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409
[ 33.099726] Workqueue: events nf_tables_trans_destroy_work
[ 33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260
[ 33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7
[ 33.101271] RSP: 0018:ffffc900004ffc48 EFLAGS: 00010202
[ 33.101546] RAX: 0000000000000001 RBX: ffff888006fc0a28 RCX: 0000000000000000
[ 33.101920] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 33.102649] RBP: ffffc900004ffc78 R08: 0000000000000000 R09: 0000000000000000
[ 33.103018] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880135ef500
[ 33.103385] R13: 0000000000000000 R14: dead000000000122 R15: ffff888006fc0a10
[ 33.103762] FS: 0000000000000000(0000) GS:ffff888024c80000(0000) knlGS:0000000000000000
[ 33.104184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 33.104493] CR2: 00007fe863b56a50 CR3: 00000000124b0001 CR4: 0000000000770ee0
[ 33.104872] PKRU: 55555554
[ 33.104999] Call Trace:
[ 33.105113]
- https://git.kernel.org/stable/c/041e2ac88caef286b39064e83e825e3f53113d36
- https://git.kernel.org/stable/c/4ae2e501331aaa506eaf760339bb2f43e5769395
- https://git.kernel.org/stable/c/515ad530795c118f012539ed76d02bacfd426d89
- https://git.kernel.org/stable/c/5e5e967e8505fbdabfb6497367ec1b808cadc356
- https://git.kernel.org/stable/c/fc95c8b02c6160936f1f3d8d9d7f4f66f3c84b49
Modified: 2026-01-16
CVE-2023-53494
In the Linux kernel, the following vulnerability has been resolved: crypto: xts - Handle EBUSY correctly As it is xts only handles the special return value of EINPROGRESS, which means that in all other cases it will free data related to the request. However, as the caller of xts may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.
- https://git.kernel.org/stable/c/51c082514c2dedf2711c99d93c196cc4eedceb40
- https://git.kernel.org/stable/c/57c3e1d63b63dc0841d41df729297cd7c1c35808
- https://git.kernel.org/stable/c/912eb10b65646ffd222256c78a1c566a3dac177d
- https://git.kernel.org/stable/c/92a07ba4f0af2cccdc2aa5ee32679c9c9714db90
- https://git.kernel.org/stable/c/d5870848879291700fe6c5257dcb48aadd10425c
Modified: 2026-01-16
CVE-2023-53495
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc() rules is allocated in ethtool_get_rxnfc and the size is determined by rule_cnt from user space. So rule_cnt needs to be check before using rules to avoid OOB writing or NULL pointer dereference.
- https://git.kernel.org/stable/c/349638f7e5d3c7d328565587bb7b0454bbee02e2
- https://git.kernel.org/stable/c/51fe0a470543f345e3c62b6798929de3ddcedc1d
- https://git.kernel.org/stable/c/5bb09dddc724c5f7c4dc6dd3bfebd685eecd93e8
- https://git.kernel.org/stable/c/61054a8ddb176b155a8f2bacdfefb3727187f5d9
- https://git.kernel.org/stable/c/625b70d31dd4df4b96b3ddcbe251debb33bd67f5
- https://git.kernel.org/stable/c/ba6673824efa3dc198b04a54e69dce480066d7d9
Modified: 2026-01-16
CVE-2023-53498
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential null dereference The adev->dm.dc pointer can be NULL and dereferenced in amdgpu_dm_fini() without checking. Add a NULL pointer check before calling dc_dmub_srv_destroy(). Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/281933f36a53fed1c2993a92cf1edfb424595474
- https://git.kernel.org/stable/c/4b1afffdd94093118b3cc235ef2b4d2520fb4950
- https://git.kernel.org/stable/c/52f1783ff4146344342422c1cd94fcb4ce39b6fe
- https://git.kernel.org/stable/c/624a60911b71af08a912ee8a296b271b3e7b34ab
- https://git.kernel.org/stable/c/b75aaebac265e3f29863699d9a929fdfba13d0a4
- https://git.kernel.org/stable/c/d4b749771fed3f99bbe8880eaab32a05ede0e5fa
Modified: 2026-01-16
CVE-2023-53499
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix error unwinding of XDP initialization When initializing XDP in virtnet_open(), some rq xdp initialization may hit an error causing net device open failed. However, previous rqs have already initialized XDP and enabled NAPI, which is not the expected behavior. Need to roll back the previous rq initialization to avoid leaks in error unwinding of init code. Also extract helper functions of disable and enable queue pairs. Use newly introduced disable helper function in error unwinding and virtnet_close. Use enable helper function in virtnet_open.
Modified: 2026-01-23
CVE-2023-53500
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix slab-use-after-free in decode_session6
When the xfrm device is set to the qdisc of the sfb type, the cb field
of the sent skb may be modified during enqueuing. Then,
slab-use-after-free may occur when the xfrm device sends IPv6 packets.
The stack information is as follows:
BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890
Read of size 1 at addr ffff8881111458ef by task swapper/3/0
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/0d27567fde5be5f0edc2db5c110142b7915b8fa8
- https://git.kernel.org/stable/c/44b3d40967009304617a7a6486490c1d6c12f899
- https://git.kernel.org/stable/c/53223f2ed1ef5c90dad814daaaefea4e68a933c8
- https://git.kernel.org/stable/c/86f15300a22656db3fa8c8967defbcd24fac4d37
- https://git.kernel.org/stable/c/bafa236380816b41b2c4c6970d9067fefa4a6c9e
- https://git.kernel.org/stable/c/da4cbaa75ed088b6d70db77b9103a27e2359e243
- https://git.kernel.org/stable/c/db0e50741f0387f388e9ec824ea7ae8456554d5b
Modified: 2026-01-23
CVE-2023-53501
In the Linux kernel, the following vulnerability has been resolved: iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind When unbinding pasid - a race condition exists vs outstanding page faults. To prevent this, the pasid_state object contains a refcount. * set to 1 on pasid bind * incremented on each ppr notification start * decremented on each ppr notification done * decremented on pasid unbind Since refcount_dec assumes that refcount will never reach 0: the current implementation causes the following to be invoked on pasid unbind: REFCOUNT_WARN("decrement hit 0; leaking memory") Fix this issue by changing refcount_dec to refcount_dec_and_test to explicitly handle refcount=1.
- https://git.kernel.org/stable/c/13ed255248dfbbb7f23f9170c7a537fb9ca22c73
- https://git.kernel.org/stable/c/534103bcd52ca9c1fecbc70e717b4a538dc4ded8
- https://git.kernel.org/stable/c/98d86bf32187db27946ca817c2467a5f2f7aa02f
- https://git.kernel.org/stable/c/9ccc51be3126b25cfe9351dbffde946c925cc28a
- https://git.kernel.org/stable/c/a50d60b8f2aff46dd7c7edb4a5835cdc4d432c22
Modified: 2026-04-06
CVE-2023-53503
In the Linux kernel, the following vulnerability has been resolved: ext4: allow ext4_get_group_info() to fail Previously, ext4_get_group_info() would treat an invalid group number as BUG(), since in theory it should never happen. However, if a malicious attaker (or fuzzer) modifies the superblock via the block device while it is the file system is mounted, it is possible for s_first_data_block to get set to a very large number. In that case, when calculating the block group of some block number (such as the starting block of a preallocation region), could result in an underflow and very large block group number. Then the BUG_ON check in ext4_get_group_info() would fire, resutling in a denial of service attack that can be triggered by root or someone with write access to the block device. For a quality of implementation perspective, it's best that even if the system administrator does something that they shouldn't, that it will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info() will call ext4_error and return NULL. We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it. The results in a next reduction of the compiled text size of ext4 by roughly 2k.
- https://git.kernel.org/stable/c/100c0ad6c04597fefeaaba2bb1827cc015d95067
- https://git.kernel.org/stable/c/31668cebf45adfb6283e465e641c4f5a21b07afa
- https://git.kernel.org/stable/c/5354b2af34064a4579be8bc0e2f15a7b70f14b5f
- https://git.kernel.org/stable/c/620a3c28221bb219b81bc0bffd065cc187494302
- https://git.kernel.org/stable/c/b4319e457d6e3fb33e443efeaf4634fc36e8a9ed
Modified: 2026-01-23
CVE-2023-53505
In the Linux kernel, the following vulnerability has been resolved: clk: tegra: tegra124-emc: Fix potential memory leak The tegra and tegra needs to be freed in the error handling path, otherwise it will be leaked.
- https://git.kernel.org/stable/c/404e9f741acfb188212f7142d91e247630dd77cc
- https://git.kernel.org/stable/c/4e59e355f9fcccd9edf65d09f769bb4c163a1c36
- https://git.kernel.org/stable/c/53a06e5924c0d43c11379a08c5a78529c3e61595
- https://git.kernel.org/stable/c/801c8341f7aff07c494b53e627970b72635af5d3
- https://git.kernel.org/stable/c/96bafece6ff380138896f009141fd7337070e680
- https://git.kernel.org/stable/c/e969c144d908ea9387442659f103d374c8ff682d
- https://git.kernel.org/stable/c/fd1c117bb5d7e033bf1aa25ac97ff421f81a1199
Modified: 2026-01-23
CVE-2023-53506
In the Linux kernel, the following vulnerability has been resolved: udf: Do not bother merging very long extents When merging very long extents we try to push as much length as possible to the first extent. However this is unnecessarily complicated and not really worth the trouble. Furthermore there was a bug in the logic resulting in corrupting extents in the file as syzbot reproducer shows. So just don't bother with the merging of extents that are too long together.
- https://git.kernel.org/stable/c/3d20e3b768aff32112bdce8d3219d923ae75f9f1
- https://git.kernel.org/stable/c/53cafe1d6d8ef9f93318e5bfccc0d24f27d41ced
- https://git.kernel.org/stable/c/5d029799d381a9ee06209a222cae75f04c5d5304
- https://git.kernel.org/stable/c/7a965da79f2d22601f329cbfce588386b0847544
- https://git.kernel.org/stable/c/965982feb333aefa9256c0fe188b5f1b958aef63
- https://git.kernel.org/stable/c/9a8d602f0723586e668bae7e65c832ceb9bcc8bc
- https://git.kernel.org/stable/c/adac9ac6d2e04ea0782b91a00ba10706002f3ec4
- https://git.kernel.org/stable/c/d52252a1de4cf96a34f722b0cd8902d8ff78eb57
Modified: 2026-01-23
CVE-2023-53508
In the Linux kernel, the following vulnerability has been resolved: ublk: fail to start device if queue setup is interrupted In ublk_ctrl_start_dev(), if wait_for_completion_interruptible() is interrupted by signal, queues aren't setup successfully yet, so we have to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered. Reported by German when working on qemu-storage-deamon which requires single thread ublk daemon.
Modified: 2026-01-23
CVE-2023-53509
In the Linux kernel, the following vulnerability has been resolved:
qed: allow sleep in qed_mcp_trace_dump()
By default, qed_mcp_cmd_and_union() delays 10us at a time in a loop
that can run 500K times, so calls to qed_mcp_nvm_rd_cmd()
may block the current thread for over 5s.
We observed thread scheduling delays over 700ms in production,
with stacktraces pointing to this code as the culprit.
qed_mcp_trace_dump() is called from ethtool, so sleeping is permitted.
It already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd().
Add a "can sleep" parameter to qed_find_nvram_image() and
qed_nvram_read() so they can sleep during qed_mcp_trace_dump().
qed_mcp_trace_get_meta_info() and qed_mcp_trace_read_meta(),
called only by qed_mcp_trace_dump(), allow these functions to sleep.
I can't tell if the other caller (qed_grc_dump_mcp_hw_dump()) can sleep,
so keep b_can_sleep set to false when it calls these functions.
An example stacktrace from a custom warning we added to the kernel
showing a thread that has not scheduled despite long needing resched:
[ 2745.362925,17] ------------[ cut here ]------------
[ 2745.362941,17] WARNING: CPU: 23 PID: 5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0()
[ 2745.362946,17] Thread not rescheduled for 744 ms after irq 99
[ 2745.362956,17] Modules linked in: ...
[ 2745.363339,17] CPU: 23 PID: 5640 Comm: lldpd Tainted: P O 4.4.182+ #202104120910+6d1da174272d.61x
[ 2745.363343,17] Hardware name: FOXCONN MercuryB/Quicksilver Controller, BIOS H11P1N09 07/08/2020
[ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20
[ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000
[ 2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000
[ 2745.363379,17] Call Trace:
[ 2745.363382,17]
Modified: 2026-04-06
CVE-2023-53511
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix fget leak when fs don't support nowait buffered read Heming reported a BUG when using io_uring doing link-cp on ocfs2. [1] Do the following steps can reproduce this BUG: mount -t ocfs2 /dev/vdc /mnt/ocfs2 cp testfile /mnt/ocfs2/ ./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1 umount /mnt/ocfs2 Then umount will fail, and it outputs: umount: /mnt/ocfs2: target is busy. While tracing umount, it blames mnt_get_count() not return as expected. Do a deep investigation for fget()/fput() on related code flow, I've finally found that fget() leaks since ocfs2 doesn't support nowait buffered read. io_issue_sqe |-io_assign_file // do fget() first |-io_read |-io_iter_do_read |-ocfs2_file_read_iter // return -EOPNOTSUPP |-kiocb_done |-io_rw_done |-__io_complete_rw_common // set REQ_F_REISSUE |-io_resubmit_prep |-io_req_prep_async // override req->file, leak happens This was introduced by commit a196c78b5443 in v5.18. Fix it by don't re-assign req->file if it has already been assigned. [1] https://lore.kernel.org/ocfs2-devel/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/T/#t
Modified: 2026-01-23
CVE-2023-53512
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix a memory leak Add a forgotten kfree().
- https://git.kernel.org/stable/c/28137ea3eb05a87329a7154a8ff410d9e8bcc0a5
- https://git.kernel.org/stable/c/30c7c72b6cf9d8c95f9b219c9d2e4e31b15bebe5
- https://git.kernel.org/stable/c/378cc0eec4aa546ce1ae17515e2dfab719d4fb1e
- https://git.kernel.org/stable/c/54dd96015e8d7a2a07359e2dfebf05b529d1780c
- https://git.kernel.org/stable/c/847cdbdcd5a24c1eec9595161a23b88fef91ff42
Modified: 2026-04-06
CVE-2023-53513
In the Linux kernel, the following vulnerability has been resolved: nbd: fix incomplete validation of ioctl arg We tested and found an alarm caused by nbd_ioctl arg without verification. The UBSAN warning calltrace like below: UBSAN: Undefined behaviour in fs/buffer.c:1709:35 signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long long int' CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x170/0x1dc lib/dump_stack.c:118 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161 handle_overflow+0x188/0x1dc lib/ubsan.c:192 __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934 blkdev_writepage+0x34/0x40 fs/block_dev.c:607 __writepage+0x68/0xe8 mm/page-writeback.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114 do_writepages+0xd4/0x250 mm/page-writeback.c:2344 The reason for triggering this warning is __block_write_full_page() -> i_size_read(inode) - 1 overflow. inode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize. We think it is necessary to limit the size of arg to prevent errors. Moreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int. Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine), it will become 1 after the coercion, which will return unexpected results. Fix it by adding checks to prevent passing in too large numbers.
Modified: 2026-01-23
CVE-2023-53514
In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix memory leak of device names The device names allocated by dev_set_name() need be freed before module unloading, but they can not be freed because the kobject's refcount which was set in device_initialize() has not be decreased to 0. As comment of device_add() says, if it fails, use only put_device() drop the refcount, then the name will be freed in kobejct_cleanup(). device_del() and put_device() can be replaced with device_unregister(), so call it to unregister the added successfully devices, and just call put_device() to the not added device. Add a release() function to device to avoid null release() function WARNING in device_release(), it's empty, because the context devices are freed together in host1x_memory_context_list_free().
Modified: 2026-04-06
CVE-2023-53515
In the Linux kernel, the following vulnerability has been resolved: virtio-mmio: don't break lifecycle of vm_dev vm_dev has a separate lifecycle because it has a 'struct device' embedded. Thus, having a release callback for it is correct. Allocating the vm_dev struct with devres totally breaks this protection, though. Instead of waiting for the vm_dev release callback, the memory is freed when the platform_device is removed. Resulting in a use-after-free when finally the callback is to be called. To easily see the problem, compile the kernel with CONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs. The fix is easy, don't use devres in this case. Found during my research about object lifetime problems.
- https://git.kernel.org/stable/c/2dcb368fe5a8eee498ca75c93a18ce2f3b0d6a8e
- https://git.kernel.org/stable/c/3ff54d904fafabd0912796785e53cce4e69ca123
- https://git.kernel.org/stable/c/55c91fedd03d7b9cf0c5199b2eb12b9b8e95281a
- https://git.kernel.org/stable/c/5b7d5c2dd664eb8b9a06ecbc06e28d39359c422e
- https://git.kernel.org/stable/c/97a2d55ead76358245b446efd87818e919196d7a
- https://git.kernel.org/stable/c/af5818c35173e096085c6ae2e3aac605d3d15e41
- https://git.kernel.org/stable/c/b788ad3b2468512339c05f23692e36860264e674
Modified: 2026-04-06
CVE-2023-53517
In the Linux kernel, the following vulnerability has been resolved:
tipc: do not update mtu if msg_max is too small in mtu negotiation
When doing link mtu negotiation, a malicious peer may send Activate msg
with a very small mtu, e.g. 4 in Shuang's testing, without checking for
the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then
n->links[bearer_id].mtu is set to 4294967228, which is a overflow of
'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().
With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:
tipc: Too large msg, purging xmit list 1 5 0 40 4!
tipc: Too large msg, purging xmit list 1 15 0 60 4!
And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in
named_distribute(), and when purging it in tipc_link_xmit(), a crash
was even caused:
general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19
RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0
Call Trace:
- https://git.kernel.org/stable/c/1dd7ae5e0cf5a56e513f7ab7ab9570b7496281d2
- https://git.kernel.org/stable/c/259683001d7e879fea4b42084fb6560dd9408a7e
- https://git.kernel.org/stable/c/2bd4ff4ffb92113f8acd04dbaed83269172c24b4
- https://git.kernel.org/stable/c/56077b56cd3fb78e1c8619e29581ba25a5c55e86
- https://git.kernel.org/stable/c/575e84d90a74c0b091b3417ba763ebb237aa0a8c
Modified: 2026-01-23
CVE-2023-53518
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix leak in devfreq_dev_release() srcu_init_notifier_head() allocates resources that need to be released with a srcu_cleanup_notifier_head() call. Reported by kmemleak.
- https://git.kernel.org/stable/c/111bafa210ae546bee7644be730c42df9c35b66e
- https://git.kernel.org/stable/c/1640e9c72173911ad0fddb05012c01eafe082c4e
- https://git.kernel.org/stable/c/29811f4b8255d4238cf326f3bb7129784766beab
- https://git.kernel.org/stable/c/3354c401c68d70567d1ef25d12f4e22a7813a3c6
- https://git.kernel.org/stable/c/5693d077595de721f9ddbf9d37f40e5409707dfe
- https://git.kernel.org/stable/c/64e6e0dc2d578c0a9e31cb4edd719f0a3ed98f6d
- https://git.kernel.org/stable/c/7462483446cb9986568ad7adae746ce5f18d2968
- https://git.kernel.org/stable/c/8918025feb2f5f7c73f2495c158f22997e25cb02
- https://git.kernel.org/stable/c/ab192e5e5d3b48415909a8408acfd007a607bcc0
Modified: 2026-04-06
CVE-2023-53519
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: add lock to protect parameter num_rdy Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready. kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&] kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c
- https://git.kernel.org/stable/c/1676748aa29099fc0abd71e0fb092e76e835f25c
- https://git.kernel.org/stable/c/56b5c3e67b0f9af3f45cf393be048ee8d8a92694
- https://git.kernel.org/stable/c/690dd4780b3f4d755e4e7883e8c3d1b5052f6bf2
- https://git.kernel.org/stable/c/7fc7f87725805197388ba749a1801df33000fa50
- https://git.kernel.org/stable/c/c71aa5f1cf961264690f2560503ea396b6e3c680
- https://git.kernel.org/stable/c/e01ea1c4191ee08440b5f86db98dff695e9cedf9
- https://git.kernel.org/stable/c/e52de26cb37459b16213438a2c82feb155dd3bbd
- https://git.kernel.org/stable/c/ef009fe2010ea2a3a7045ecb72729cf366e0967b
Modified: 2026-04-06
CVE-2023-53520
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.
Modified: 2026-04-06
CVE-2023-53521
In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Fix slab-out-of-bounds in ses_intf_remove() A fix for: BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses] Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013 When edev->components is zero, accessing edev->component[0] members is wrong.
- https://git.kernel.org/stable/c/0595cdb587726b4f0fa780eb7462e3679d141e82
- https://git.kernel.org/stable/c/2fb1fa8425cce2dc4dce298275d22d7077694b73
- https://git.kernel.org/stable/c/40af9a6deed723485e05b7d3255a28750692e8db
- https://git.kernel.org/stable/c/578797f0c8cbc2e3ec5fc0dab87087b4c7073686
- https://git.kernel.org/stable/c/76f7050537476ac062ec23a544fbca8270f2d08b
- https://git.kernel.org/stable/c/82143faf01dda831b89eccef60c39ef8575ab08a
- https://git.kernel.org/stable/c/87e47be38d205df338c52ead43f23b2864567423
- https://git.kernel.org/stable/c/8f9542cad6c27297c8391de3a659f0b7948495d0
Modified: 2026-04-06
CVE-2023-53522
In the Linux kernel, the following vulnerability has been resolved: cgroup,freezer: hold cpu_hotplug_lock before freezer_mutex syzbot is reporting circular locking dependency between cpu_hotplug_lock and freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic") replaced atomic_inc() in freezer_apply_state() with static_branch_inc() which holds cpu_hotplug_lock. cpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex cgroup_file_write() { cgroup_procs_write() { __cgroup_procs_write() { cgroup_procs_write_start() { cgroup_attach_lock() { cpus_read_lock() { percpu_down_read(&cpu_hotplug_lock); } percpu_down_write(&cgroup_threadgroup_rwsem); } } cgroup_attach_task() { cgroup_migrate() { cgroup_migrate_execute() { freezer_attach() { mutex_lock(&freezer_mutex); (...snipped...) } } } } (...snipped...) } } } freezer_mutex => cpu_hotplug_lock cgroup_file_write() { freezer_write() { freezer_change_state() { mutex_lock(&freezer_mutex); freezer_apply_state() { static_branch_inc(&freezer_active) { static_key_slow_inc() { cpus_read_lock(); static_key_slow_inc_cpuslocked(); cpus_read_unlock(); } } } mutex_unlock(&freezer_mutex); } } } Swap locking order by moving cpus_read_lock() in freezer_apply_state() to before mutex_lock(&freezer_mutex) in freezer_change_state().
Modified: 2026-04-06
CVE-2023-53524
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf An integer overflow occurs in the iwl_write_to_user_buf() function, which is called by the iwl_dbgfs_monitor_data_read() function. static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count, void *buf, ssize_t *size, ssize_t *bytes_copied) { int buf_size_left = count - *bytes_copied; buf_size_left = buf_size_left - (buf_size_left % sizeof(u32)); if (*size > buf_size_left) *size = buf_size_left; If the user passes a SIZE_MAX value to the "ssize_t count" parameter, the ssize_t count parameter is assigned to "int buf_size_left". Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a negative number, so "*size" is assigned "buf_size_left" and goes into the third argument of the copy_to_user function, causing a heap overflow. This is not a security vulnerability because iwl_dbgfs_monitor_data_read() is a debugfs operation with 0400 privileges.
- https://git.kernel.org/stable/c/059e426d666a41e26b184c177c1ca3ee2d6fa1b6
- https://git.kernel.org/stable/c/0ad8dd870aa187d0c21d032bb2c6433559075eec
- https://git.kernel.org/stable/c/58d1b717879bfeabe09b35e41ad667c79933eb2e
- https://git.kernel.org/stable/c/82f877ec9b041edc4c7c509c605cc3393d837bf0
- https://git.kernel.org/stable/c/de78456976026102babe66258c228691ca5677c0
- https://git.kernel.org/stable/c/eb1ef44efac797b384d361a76e33f77027c29a14
Modified: 2026-04-06
CVE-2023-53525
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Allow UD qp_type to join multicast only As for multicast: - The SIDR is the only mode that makes sense; - Besides PS_UDP, other port spaces like PS_IB is also allowed, as it is UD compatible. In this case qkey also needs to be set [1]. This patch allows only UD qp_type to join multicast, and set qkey to default if it's not set, to fix an uninit-value error: the ib->rec.qkey field is accessed without being initialized. ===================================================== BUG: KMSAN: uninit-value in cma_set_qkey drivers/infiniband/core/cma.c:510 [inline] BUG: KMSAN: uninit-value in cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570 cma_set_qkey drivers/infiniband/core/cma.c:510 [inline] cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570 cma_iboe_join_multicast drivers/infiniband/core/cma.c:4782 [inline] rdma_join_multicast+0x2b83/0x30a0 drivers/infiniband/core/cma.c:4814 ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 ucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:1546 ucma_write+0x639/0x6d0 drivers/infiniband/core/ucma.c:1732 vfs_write+0x8ce/0x2030 fs/read_write.c:588 ksys_write+0x28c/0x520 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __ia32_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline] __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180 do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Local variable ib.i created at: cma_iboe_join_multicast drivers/infiniband/core/cma.c:4737 [inline] rdma_join_multicast+0x586/0x30a0 drivers/infiniband/core/cma.c:4814 ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 CPU: 0 PID: 29874 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ===================================================== [1] https://lore.kernel.org/linux-rdma/20220117183832.GD84788@nvidia.com/
- https://git.kernel.org/stable/c/02eabb635bc64bd1e3a7cf887d6d182bffb64b99
- https://git.kernel.org/stable/c/48e8e7851dc0b1584d83817a78fc7108c8904b54
- https://git.kernel.org/stable/c/58e84f6b3e84e46524b7e5a916b53c1ad798bc8f
- https://git.kernel.org/stable/c/ae11498851423d6de27aebfe12a5ee85060ab1d5
- https://git.kernel.org/stable/c/bb18b9dbac2bbdf7695e0bfaac4bf944ff7b207d
Modified: 2026-01-23
CVE-2023-53531
In the Linux kernel, the following vulnerability has been resolved: null_blk: fix poll request timeout handling When doing io_uring benchmark on /dev/nullb0, it's easy to crash the kernel if poll requests timeout triggered, as reported by David. [1] BUG: kernel NULL pointer dereference, address: 0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace: ? null_timeout_rq+0x4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81 __sbitmap_for_each_set.constprop.0+0xb0/0xf2 ? __blk_mq_complete_request_remote+0xf/0xf bt_for_each+0x46/0x64 ? __blk_mq_complete_request_remote+0xf/0xf ? percpu_ref_get_many+0xc/0x2a blk_mq_queue_tag_busy_iter+0x14d/0x18e blk_mq_timeout_work+0x95/0x127 process_one_work+0x185/0x263 worker_thread+0x1b5/0x227 This is indeed a race problem between null_timeout_rq() and null_poll(). null_poll() null_timeout_rq() spin_lock(&nq->poll_lock) list_splice_init(&nq->poll_list, &list) spin_unlock(&nq->poll_lock) while (!list_empty(&list)) req = list_first_entry() list_del_init() ... blk_mq_add_to_batch() // req->rq_next = NULL spin_lock(&nq->poll_lock) // rq->queuelist->next == NULL list_del_init(&rq->queuelist) spin_unlock(&nq->poll_lock) Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq->poll_lock protection, in which null_timeout_rq() can safely detect this race and early return. Note this patch just fix the kernel panic when request timeout happen. [1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/
Modified: 2026-03-25
CVE-2023-53532
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix deinitialization of firmware resources Currently, in ath11k_ahb_fw_resources_init(), iommu domain mapping is done only for the chipsets having fixed firmware memory. Also, for such chipsets, mapping is done only if it does not have TrustZone support. During deinitialization, only if TrustZone support is not there, iommu is unmapped back. However, for non fixed firmware memory chipsets, TrustZone support is not there and this makes the condition check to true and it tries to unmap the memory which was not mapped during initialization. This leads to the following trace - [ 83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 83.259537] Modules linked in: ath11k_ahb ath11k qmi_helpers .. snip .. [ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 83.287228] pc : __iommu_unmap+0x30/0x140 [ 83.293907] lr : iommu_unmap+0x5c/0xa4 [ 83.298072] sp : ffff80000b3abad0 .. snip .. [ 83.369175] Call trace: [ 83.376282] __iommu_unmap+0x30/0x140 [ 83.378541] iommu_unmap+0x5c/0xa4 [ 83.382360] ath11k_ahb_fw_resource_deinit.part.12+0x2c/0xac [ath11k_ahb] [ 83.385666] ath11k_ahb_free_resources+0x140/0x17c [ath11k_ahb] [ 83.392521] ath11k_ahb_shutdown+0x34/0x40 [ath11k_ahb] [ 83.398248] platform_shutdown+0x20/0x2c [ 83.403455] device_shutdown+0x16c/0x1c4 [ 83.407621] kernel_restart_prepare+0x34/0x3c [ 83.411529] kernel_restart+0x14/0x74 [ 83.415781] __do_sys_reboot+0x1c4/0x22c [ 83.419427] __arm64_sys_reboot+0x1c/0x24 [ 83.423420] invoke_syscall+0x44/0xfc [ 83.427326] el0_svc_common.constprop.3+0xac/0xe8 [ 83.430974] do_el0_svc+0xa0/0xa8 [ 83.435659] el0_svc+0x1c/0x44 [ 83.438957] el0t_64_sync_handler+0x60/0x144 [ 83.441910] el0t_64_sync+0x15c/0x160 [ 83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0) [ 83.449903] ---[ end trace 0000000000000000 ]--- This can be reproduced by probing an AHB chipset which is not having a fixed memory region. During reboot (or rmmod) trace can be seen. Fix this issue by adding a condition check on firmware fixed memory hw_param as done in the counter initialization function. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Modified: 2026-03-25
CVE-2023-53533
In the Linux kernel, the following vulnerability has been resolved: Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe rpi_firmware_get() take reference, we need to release it in error paths as well. Use devm_rpi_firmware_get() helper to handling the resources. Also remove the existing rpi_firmware_put().
- https://git.kernel.org/stable/c/0d6a5c9489c8a3d434e685066119c4333476dccd
- https://git.kernel.org/stable/c/1dfa3c9dd27bdc347733d06e980395768520bc3e
- https://git.kernel.org/stable/c/36d087e49dabd28d2c13a7532dac72d625ce69fb
- https://git.kernel.org/stable/c/5bca3688bdbc3b58a2894b8671a8e2378efe28bd
- https://git.kernel.org/stable/c/7acad58049acc6ac148e8b613a6eceeca4bcb4a7
- https://git.kernel.org/stable/c/9216aa5cfd86809a2681be3683cd9ac30432de0c
- https://git.kernel.org/stable/c/9dbbe9db224c23a60dc7b1e00c701be93328c873
Modified: 2026-03-25
CVE-2023-53534
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: mtk_drm_crtc: 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/5bf1e3bd7da625ccf9a22c8cb7d65271e6e47f4c
- https://git.kernel.org/stable/c/62952905e195f7350bc230cf0960a74ddbceed5d
- https://git.kernel.org/stable/c/67ea657c7891c2f86a7750395640d9bdf2555926
- https://git.kernel.org/stable/c/7d569ae98ee5490585929be69fea68047679b7b2
- https://git.kernel.org/stable/c/b64b6dff15a38468b8cd33fc7864fa4e02b0933a
Modified: 2026-03-23
CVE-2023-53535
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Add a check for oversized packets Occasionnaly we may get oversized packets from the hardware which exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early check which drops the packet to avoid invoking skb_over_panic() and move on to processing the next packet.
- https://git.kernel.org/stable/c/124ca24e0de958d2e20e0aa1e2434af7b72f8887
- https://git.kernel.org/stable/c/411317d2a4a7d6049d8efeef0d32ae43f8baefce
- https://git.kernel.org/stable/c/5c0862c2c962052ed5055220a00ac1cefb92fbcd
- https://git.kernel.org/stable/c/5f56767fb5f2df875b6553e08dbec6a45431c988
- https://git.kernel.org/stable/c/7cdb07e10c1258c08f31b24898930e4ece88d163
- https://git.kernel.org/stable/c/841881320562cbeac7046b537b91cd000480cea2
- https://git.kernel.org/stable/c/87363d1ab55e497702a9506ff423c422639c8a25
- https://git.kernel.org/stable/c/c34b1c0870323649d45c5074828d7f754dea2673
Modified: 2026-03-25
CVE-2023-53536
In the Linux kernel, the following vulnerability has been resolved: blk-crypto: make blk_crypto_evict_key() more robust If blk_crypto_evict_key() sees that the key is still in-use (due to a bug) or that ->keyslot_evict failed, it currently just returns while leaving the key linked into the keyslot management structures. However, blk_crypto_evict_key() is only called in contexts such as inode eviction where failure is not an option. So actually the caller proceeds with freeing the blk_crypto_key regardless of the return value of blk_crypto_evict_key(). These two assumptions don't match, and the result is that there can be a use-after-free in blk_crypto_reprogram_all_keys() after one of these errors occurs. (Note, these errors *shouldn't* happen; we're just talking about what happens if they do anyway.) Fix this by making blk_crypto_evict_key() unlink the key from the keyslot management structures even on failure. Also improve some comments.
- https://git.kernel.org/stable/c/5bb4005fb667c6e2188fa87950f8d5faf2994410
- https://git.kernel.org/stable/c/5c62852942667c613de0458fc797c5b8c36112b5
- https://git.kernel.org/stable/c/5c7cb94452901a93e90c2230632e2c12a681bc92
- https://git.kernel.org/stable/c/64ef787bb1588475163069c2e62fdd8f6c27b1f6
- https://git.kernel.org/stable/c/701a8220762ff90615dc91d3543f789391b63298
- https://git.kernel.org/stable/c/809a5be62e92a444a3c3d7b9f438019d0b322f55
Modified: 2026-03-23
CVE-2023-53537
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free for cached IPU bio xfstest generic/019 reports a bug: kernel BUG at mm/filemap.c:1619! RIP: 0010:folio_end_writeback+0x8a/0x90 Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0 __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50 The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write() in f2fs_write_single_data_page() tries to flush IPU bio in cache, however f2fs_submit_merged_ipu_write() missed to check validity of @bio parameter, result in submitting random cached bio which belong to other IO context, then it will cause use-after-free issue, fix it by adding additional validity check.
- https://git.kernel.org/stable/c/5cdb422c839134273866208dad5360835ddb9794
- https://git.kernel.org/stable/c/7d058f0ab161437369ad6e45a4b67c2886e71373
- https://git.kernel.org/stable/c/97ec6f1788cc6bee3f8c89cb908e1a2a1cd859bb
- https://git.kernel.org/stable/c/9a7f63283af6befc0f91d549f4f6917dff7479a9
- https://git.kernel.org/stable/c/af4ce124d7bd74cb839bbdaccffbb416771a56b5
- https://git.kernel.org/stable/c/b2f423fda64fb49213aa0ed5056079cf295a5df2
Modified: 2026-03-21
CVE-2023-53539
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix incomplete state save in rxe_requester If a send packet is dropped by the IP layer in rxe_requester() the call to rxe_xmit_packet() can fail with err == -EAGAIN. To recover, the state of the wqe is restored to the state before the packet was sent so it can be resent. However, the routines that save and restore the state miss a significnt part of the variable state in the wqe, the dma struct which is used to process through the sge table. And, the state is not saved before the packet is built which modifies the dma struct. Under heavy stress testing with many QPs on a fast node sending large messages to a slow node dropped packets are observed and the resent packets are corrupted because the dma struct was not restored. This patch fixes this behavior and allows the test cases to succeed.
Modified: 2026-04-06
CVE-2023-53540
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: reject auth/assoc to AP with our address If the AP uses our own address as its MLD address or BSSID, then clearly something's wrong. Reject such connections so we don't try and fail later.
Modified: 2026-03-25
CVE-2023-53541
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write When the oob buffer length is not in multiple of words, the oob write function does out-of-bounds read on the oob source buffer at the last iteration. Fix that by always checking length limit on the oob buffer read and fill with 0xff when reaching the end of the buffer to the oob registers.
- https://git.kernel.org/stable/c/14b1d00520b4d6a4818364334ce472b79cfc8976
- https://git.kernel.org/stable/c/2353b7bb61e45e7cfd21505d0c6747ac8c9496a1
- https://git.kernel.org/stable/c/2bc3d6ac704ea7263175ea3da663fdbbb7f3dd8b
- https://git.kernel.org/stable/c/45fe4ad7f439799ee1b7b5f80bf82e8b34a98d25
- https://git.kernel.org/stable/c/5d53244186c9ac58cb88d76a0958ca55b83a15cd
- https://git.kernel.org/stable/c/648d1150a688698e37f7aaf302860180901cb30e
- https://git.kernel.org/stable/c/aae45746f4aee9818296e0500e0703e9d8caa5b8
- https://git.kernel.org/stable/c/d00b031266514a9395124704630b056a5185ec17
Modified: 2026-03-21
CVE-2023-53542
In the Linux kernel, the following vulnerability has been resolved: ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy For some reason, the driver adding support for Exynos5420 MIPI phy back in 2016 wasn't used on Exynos5420, which caused a kernel panic. Add the proper compatible for it.
- https://git.kernel.org/stable/c/199624f3144d79fab1cff533ce6a4b82390520a3
- https://git.kernel.org/stable/c/29961ee63dd676cc67f7c00f76faa21e11f0d7c6
- https://git.kernel.org/stable/c/2e68a0f7bc576318a58335c31c542b358bc63f83
- https://git.kernel.org/stable/c/537bdfc1a67836fbd68bbe4210bc380f72cca47f
- https://git.kernel.org/stable/c/5d5aa219a790d61cad2c38e1aa32058f16ad2f0b
- https://git.kernel.org/stable/c/c075aa3467a799855a92289a3c619afc0a2ad193
- https://git.kernel.org/stable/c/f10001af0f7246cf3e43530d25f8d59a8db10df6
- https://git.kernel.org/stable/c/f2a6198f5ed7d6e4e06d87a4de007f2e45cc9583
Modified: 2026-03-21
CVE-2023-53543
In the Linux kernel, the following vulnerability has been resolved: vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa max vqp attr to avoid such bugs.
Modified: 2026-03-21
CVE-2023-53544
In the Linux kernel, the following vulnerability has been resolved: cpufreq: davinci: Fix clk use after free The remove function first frees the clks and only then calls cpufreq_unregister_driver(). If one of the cpufreq callbacks is called just before cpufreq_unregister_driver() is run, the freed clks might be used.
Modified: 2026-03-21
CVE-2023-53546
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx when mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memory pointed by 'in' is not released, which will cause memory leak. Move memory release after mlx5_cmd_exec.
- https://git.kernel.org/stable/c/00cecb0a8f9e7a21754d5ad85813ab6b47b3308f
- https://git.kernel.org/stable/c/165159854757dbae0dfd1812b27051da35aa6223
- https://git.kernel.org/stable/c/3169c3854397f3070a63b1b772db16dcb8cba7b4
- https://git.kernel.org/stable/c/5dd77585dd9d0e03dd1bceb95f0269a7eaf6b936
- https://git.kernel.org/stable/c/622d71d99124e69f7bf2e2b7a89f5f444a24d235
- https://git.kernel.org/stable/c/800d8c96bf997da5eb76ccf8d88795c4231c83fb
Modified: 2026-03-21
CVE-2023-53547
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix sdma v4 sw fini error
Fix sdma v4 sw fini error for sdma 4.2.2 to
solve the following general protection fault
[ +0.108196] general protection fault, probably for non-canonical
address 0xd5e5a4ae79d24a32: 0000 [#1] PREEMPT SMP PTI
[ +0.000018] RIP: 0010:free_fw_priv+0xd/0x70
[ +0.000022] Call Trace:
[ +0.000012]
Modified: 2026-03-21
CVE-2023-53548
In the Linux kernel, the following vulnerability has been resolved:
net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb
The syzbot fuzzer identified a problem in the usbnet driver:
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Workqueue: mld mld_ifc_work
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7
RSP: 0018:ffffc9000463f568 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001
RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003
R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0
Call Trace:
- https://git.kernel.org/stable/c/0dd3e0c31bf3e933fb85faf1443833aef90b8e46
- https://git.kernel.org/stable/c/1bebbd9b8037a9cc75984317cb495dec4824c399
- https://git.kernel.org/stable/c/27d0f755d649d388fcd12f01436c9a33289e14e3
- https://git.kernel.org/stable/c/53c250ea57cf03af41339234b9855ae284f9db91
- https://git.kernel.org/stable/c/5e1627cb43ddf1b24b92eb26f8d958a3f5676ccb
- https://git.kernel.org/stable/c/a05ac5d00eb7fcb2fda806caa4f56e88df6bc6bb
- https://git.kernel.org/stable/c/a0715d04cf687a7e21f0d6ac8c1d479294a3f6f8
- https://git.kernel.org/stable/c/ec0d0be41721aca683c5606354a58ee2c687e3f8
Modified: 2026-03-23
CVE-2023-53549
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Rework long task execution when adding/deleting entries When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step. The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel.
- https://git.kernel.org/stable/c/24a828f5a54bdeca0846526860d72b3766c5fe95
- https://git.kernel.org/stable/c/5e29dc36bd5e2166b834ceb19990d9e68a734d7d
- https://git.kernel.org/stable/c/8964cc36ba011dc0e1041131fa2e91fb4c2a811b
- https://git.kernel.org/stable/c/a1e1521b463968b4eca7163f61fb6cc54d008061
- https://git.kernel.org/stable/c/ee756980e491c829ba0495bb420b7224a9ee26b2
Modified: 2026-03-21
CVE-2023-53551
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Add null pointer check in gserial_resume Consider a case where gserial_disconnect has already cleared gser->ioport. And if a wakeup interrupt triggers afterwards, gserial_resume gets called, which will lead to accessing of gser->ioport and thus causing null pointer dereference.Add a null pointer check to prevent this. Added a static spinlock to prevent gser->ioport from becoming null after the newly added check.
- https://git.kernel.org/stable/c/3b24c980dc07be4550a9d1450ed7057f882530e5
- https://git.kernel.org/stable/c/44e004f757a7ae13dfebaadbcfdb1a6f98c10377
- https://git.kernel.org/stable/c/5ec63fdbca604568890c577753c6f66c5b3ef0b5
- https://git.kernel.org/stable/c/c5360eec648bd506afa304ae4a71f82e13d41897
- https://git.kernel.org/stable/c/ec357cd3e8af614855d286dd378725cdc7264df6
Modified: 2026-03-23
CVE-2023-53552
In the Linux kernel, the following vulnerability has been resolved: drm/i915: mark requests for GuC virtual engines to avoid use-after-free References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible extra bit has been added to rq->execution_mask, for marking virtual engines. (cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)
Modified: 2026-03-23
CVE-2023-53554
In the Linux kernel, the following vulnerability has been resolved: staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext() The "exc->key_len" is a u16 that comes from the user. If it's over IW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.
- https://git.kernel.org/stable/c/5373a1aa91b2298f9305794b8270cf9896be96b6
- https://git.kernel.org/stable/c/5f1c7031e044cb2fba82836d55cc235e2ad619dc
- https://git.kernel.org/stable/c/663fff29fd613e2b0d30c4138157312ba93c4939
- https://git.kernel.org/stable/c/7ae9f55a495077f838bab466411ee6f38574df9b
- https://git.kernel.org/stable/c/9496fb96ddeb740dc6b966f4a7d8dfb8b93921c6
- https://git.kernel.org/stable/c/b1b04b56745bc79286c80aa876fabfab1e08ebf1
- https://git.kernel.org/stable/c/baf420e30364ef9efe3e29a5c0e01e612aebf3fe
- https://git.kernel.org/stable/c/caac4b6c15b66feae4d83f602e1e46f124540202
Modified: 2026-03-21
CVE-2023-53556
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix use-after-free in free_netdev We do netif_napi_add() for all allocated q_vectors[], but potentially do netif_napi_del() for part of them, then kfree q_vectors and leave invalid pointers at dev->napi_list. Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) wait Result: [ 4093.900222] ================================================================== [ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390 [ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699 [ 4093.900233] [ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1 [ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021 [ 4093.900239] Call Trace: [ 4093.900244] dump_stack+0x71/0xab [ 4093.900249] print_address_description+0x6b/0x290 [ 4093.900251] ? free_netdev+0x308/0x390 [ 4093.900252] kasan_report+0x14a/0x2b0 [ 4093.900254] free_netdev+0x308/0x390 [ 4093.900261] iavf_remove+0x825/0xd20 [iavf] [ 4093.900265] pci_device_remove+0xa8/0x1f0 [ 4093.900268] device_release_driver_internal+0x1c6/0x460 [ 4093.900271] pci_stop_bus_device+0x101/0x150 [ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20 [ 4093.900275] pci_iov_remove_virtfn+0x187/0x420 [ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10 [ 4093.900278] ? pci_get_subsys+0x90/0x90 [ 4093.900280] sriov_disable+0xed/0x3e0 [ 4093.900282] ? bus_find_device+0x12d/0x1a0 [ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e] [ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e] [ 4093.900299] ? pci_get_device+0x7c/0x90 [ 4093.900300] ? pci_get_subsys+0x90/0x90 [ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210 [ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10 [ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e] [ 4093.900318] sriov_numvfs_store+0x214/0x290 [ 4093.900320] ? sriov_totalvfs_show+0x30/0x30 [ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10 [ 4093.900323] ? __check_object_size+0x15a/0x350 [ 4093.900326] kernfs_fop_write+0x280/0x3f0 [ 4093.900329] vfs_write+0x145/0x440 [ 4093.900330] ksys_write+0xab/0x160 [ 4093.900332] ? __ia32_sys_read+0xb0/0xb0 [ 4093.900334] ? fput_many+0x1a/0x120 [ 4093.900335] ? filp_close+0xf0/0x130 [ 4093.900338] do_syscall_64+0xa0/0x370 [ 4093.900339] ? page_fault+0x8/0x30 [ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 4093.900357] RIP: 0033:0x7f16ad4d22c0 [ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24 [ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0 [ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001 [ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700 [ 4093.9003 ---truncated---
- https://git.kernel.org/stable/c/17046107ca15d7571551539d94e76aba2bf71fd3
- https://git.kernel.org/stable/c/345c44e18cc10cded85cb9134830e1684495c866
- https://git.kernel.org/stable/c/5f4fa1672d98fe99d2297b03add35346f1685d6b
- https://git.kernel.org/stable/c/8d781a9c53034813c3194b7d94409c7d24ac73eb
- https://git.kernel.org/stable/c/a4635f190f332304db4a49e827ece790b804b5db
- https://git.kernel.org/stable/c/ca12b98e04b5d1902ac08fe826d3500cb4b6e891
Modified: 2026-03-21
CVE-2023-53557
In the Linux kernel, the following vulnerability has been resolved:
fprobe: Release rethook after the ftrace_ops is unregistered
While running bpf selftests it's possible to get following fault:
general protection fault, probably for non-canonical address \
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI
...
Call Trace:
Modified: 2026-03-21
CVE-2023-53558
In the Linux kernel, the following vulnerability has been resolved:
rcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()
pr_info() is called with rtp->cbs_gbl_lock spin lock locked. Because
pr_info() calls printk() that might sleep, this will result in BUG
like below:
[ 0.206455] cblist_init_generic: Setting adjustable number of callback queues.
[ 0.206463]
[ 0.206464] =============================
[ 0.206464] [ BUG: Invalid wait context ]
[ 0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted
[ 0.206466] -----------------------------
[ 0.206466] swapper/0/1 is trying to lock:
[ 0.206467] ffffffffa0167a58 (&port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0
[ 0.206473] other info that might help us debug this:
[ 0.206473] context-{5:5}
[ 0.206474] 3 locks held by swapper/0/1:
[ 0.206474] #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0
[ 0.206478] #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e
[ 0.206482] #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330
[ 0.206485] stack backtrace:
[ 0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5
[ 0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
[ 0.206489] Call Trace:
[ 0.206490]
Modified: 2026-03-21
CVE-2023-53559
In the Linux kernel, the following vulnerability has been resolved: ip_vti: fix potential slab-use-after-free in decode_session6 When ip_vti device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when ip_vti device sends IPv6 packets. As commit f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") showed, xfrm_decode_session was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets.
- https://git.kernel.org/stable/c/0b4d69539fdea138af2befe08893850c89248068
- https://git.kernel.org/stable/c/2b05bf5dc437f7891dd409a3eaf5058459391c7a
- https://git.kernel.org/stable/c/6018a266279b1a75143c7c0804dd08a5fc4c3e0b
- https://git.kernel.org/stable/c/78e397a43e1c47321a4679cc49a6c4530bf820b9
- https://git.kernel.org/stable/c/7dfe23659f3677c08a60a0056cda2d91a79c15ca
- https://git.kernel.org/stable/c/82fb41c5de243e7dfa90f32ca58e35adaff56c1d
- https://git.kernel.org/stable/c/d34c30442d5e53a33cde79ca163320dbe2432cbd
- https://git.kernel.org/stable/c/e1e04cc2ef2c0c0866c19f5627149a76c2baae32
Modified: 2026-03-21
CVE-2023-53560
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Add histograms to hist_vars if they have referenced variables
Hist triggers can have referenced variables without having direct
variables fields. This can be the case if referenced variables are added
for trigger actions. In this case the newly added references will not
have field variables. Not taking such referenced variables into
consideration can result in a bug where it would be possible to remove
hist trigger with variables being refenced. This will result in a bug
that is easily reproducable like so
$ cd /sys/kernel/tracing
$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events
$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger
$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger
$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger
[ 100.263533] ==================================================================
[ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180
[ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439
[ 100.266320]
[ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4
[ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
[ 100.268561] Call Trace:
[ 100.268902]
- https://git.kernel.org/stable/c/1576f0df7b4d1f82db588d6654b89d796fa06929
- https://git.kernel.org/stable/c/4815359056083c555f97a5ee3af86519be5166de
- https://git.kernel.org/stable/c/4a540f63618e525e433b37d2b5522cda08e321d7
- https://git.kernel.org/stable/c/4ffad1528e81c91769d9da1f8436080861c8ec67
- https://git.kernel.org/stable/c/5fd32eb6fa0ac795aa5a64bc004ab68d7b44196a
- https://git.kernel.org/stable/c/6018b585e8c6fa7d85d4b38d9ce49a5b67be7078
- https://git.kernel.org/stable/c/97f54b330c797ed27fba8791baeaa38ace886cbd
Modified: 2026-03-21
CVE-2023-53561
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix NULL pointer dereference when removing device In suspend and resume cycle, the removal and rescan of device ends up in NULL pointer dereference. During driver initialization, if the ipc_imem_wwan_channel_init() fails to get the valid device capabilities it returns an error and further no resource (wwan struct) will be allocated. Now in this situation if driver removal procedure is initiated it would result in NULL pointer exception since unallocated wwan struct is dereferenced inside ipc_wwan_deinit(). ipc_imem_run_state_worker() to handle the called functions return value and to release the resource in failure case. It also reports the link down event in failure cases. The user space application can handle this event to do a device reset for restoring the device communication.
Modified: 2026-03-21
CVE-2023-53562
In the Linux kernel, the following vulnerability has been resolved: drm/msm: fix vram leak on bind errors Make sure to release the VRAM buffer also in a case a subcomponent fails to bind. Patchwork: https://patchwork.freedesktop.org/patch/525094/
Modified: 2026-03-21
CVE-2023-53563
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: amd-pstate-ut: Fix kernel panic when loading the driver
After loading the amd-pstate-ut driver, amd_pstate_ut_check_perf()
and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy
of the CPU and mark it as busy.
In these functions, cpufreq_cpu_put() should be used to release the
policy, but it is not, so any other entity trying to access the policy
is blocked indefinitely.
One such scenario is when amd_pstate mode is changed, leading to the
following splat:
[ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds.
[ 1332.110001] Not tainted 6.5.0-rc2-amd-pstate-ut #5
[ 1332.115315] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1332.123140] task:bash state:D stack:0 pid:2929 ppid:2873 flags:0x00004006
[ 1332.123143] Call Trace:
[ 1332.123145]
Modified: 2026-03-21
CVE-2023-53564
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix defrag path triggering jbd2 ASSERT code path: ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERT crash stacks: PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2] Analysis This bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: call ocfs2_journal_access_di() before ocfs2_journal_dirty() in ocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is called by ocfs2_split_extent() during defragmenting. How to fix For ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller only needs to call journal start/stop pair. The fix method is to remove journal access/dirty from __ocfs2_move_extent(). The discussion for this patch: https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
- https://git.kernel.org/stable/c/2c559b3ba8e0b9e3c4bb08159a28ccadc698410f
- https://git.kernel.org/stable/c/33665d1042666f2e5c736a3df1f453e31f030663
- https://git.kernel.org/stable/c/590507ebabd33cd93324c04f9a5538309a5ba934
- https://git.kernel.org/stable/c/5f43d34a51ed30e6a60f7e59d224a63014fe2cd5
- https://git.kernel.org/stable/c/60eed1e3d45045623e46944ebc7c42c30a4350f0
- https://git.kernel.org/stable/c/669134a66d37258e1c4a5cfbd5b82f547ae30fca
- https://git.kernel.org/stable/c/7f3b1c28e2908755fb248d3ee8ff56826f2387db
- https://git.kernel.org/stable/c/8163ea90d89b7012dd1fa4b28edf5db0c641eca7
Modified: 2026-03-21
CVE-2023-53567
In the Linux kernel, the following vulnerability has been resolved: spi: qup: Don't skip cleanup in remove's error path Returning early in a platform driver's remove callback is wrong. In this case the dma resources are not released in the error path. this is never retried later and so this is a permanent leak. To fix this, only skip hardware disabling if waking the device fails.
- https://git.kernel.org/stable/c/2d0f63077f481f11a07f20eab1c1f4367dfaef32
- https://git.kernel.org/stable/c/49c17fccae36505550c9121891722fff337f148a
- https://git.kernel.org/stable/c/55ecdcd12bc176b86fecbcb125ac814ac8fe857a
- https://git.kernel.org/stable/c/61f49171a43ab1f80c73c5c88c508770c461e0f2
- https://git.kernel.org/stable/c/8632384337038b97910c2f7bb5a3f377aa68d001
- https://git.kernel.org/stable/c/bc88243bbe6140d289bb32b4ee4607ba5ce1124a
- https://git.kernel.org/stable/c/f345d4d71e87d878437417ffbb9a7d4e16d235eb
- https://git.kernel.org/stable/c/fd53f41bd86daa39b454fd4637a908ff2123547f
Modified: 2026-03-21
CVE-2023-53568
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: don't leak memory if dev_set_name() fails When dev_set_name() fails, zcdn_create() doesn't free the newly allocated resources. Do it.
- https://git.kernel.org/stable/c/0878052579cb2773caee64812a811edcab6b5a55
- https://git.kernel.org/stable/c/131cd74a8e38d75239f2c81dfee53d6554eb8bf8
- https://git.kernel.org/stable/c/147d8da33a2c2195ec63acd56cd7d80a3458c253
- https://git.kernel.org/stable/c/174f11ef1615ec3ab1e2189685864433c0d855a2
- https://git.kernel.org/stable/c/6252f47b78031979ad919f971dc8468b893488bd
- https://git.kernel.org/stable/c/6b0cb9c055843777b374309503d89eabeb769355
Modified: 2026-03-21
CVE-2023-53569
In the Linux kernel, the following vulnerability has been resolved: ext2: Check block size validity during mount Check that log of block size stored in the superblock has sensible value. Otherwise the shift computing the block size can overflow leading to undefined behavior.
- https://git.kernel.org/stable/c/0ebfaf14150f55550cffb1148ed3920143c7a69c
- https://git.kernel.org/stable/c/22ab5fed07ad4b206ea910fd0132d1a0d4831584
- https://git.kernel.org/stable/c/451b98155be5dfee05bc6e7c8b30c0be4add3f71
- https://git.kernel.org/stable/c/62aeb94433fcec80241754b70d0d1836d5926b0a
- https://git.kernel.org/stable/c/99f8a15af6c9f0653193104a9e70891f950c6001
- https://git.kernel.org/stable/c/c2e7776843a953fd7e48895c3880c277f996193e
- https://git.kernel.org/stable/c/c4813f858e5c3e4c4659ce95385c1c400c593e1e
- https://git.kernel.org/stable/c/e6f4fb28890c1361e0db9eb1adee3fc04e7fe7f5
Modified: 2026-03-21
CVE-2023-53570
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems() nl80211_parse_mbssid_elems() uses a u8 variable num_elems to count the number of MBSSID elements in the nested netlink attribute attrs, which can lead to an integer overflow if a user of the nl80211 interface specifies 256 or more elements in the corresponding attribute in userspace. The integer overflow can lead to a heap buffer overflow as num_elems determines the size of the trailing array in elems, and this array is thereafter written to for each element in attrs. Note that this vulnerability only affects devices with the wiphy->mbssid_max_interfaces member set for the wireless physical device struct in the device driver, and can only be triggered by a process with CAP_NET_ADMIN capabilities. Fix this by checking for a maximum of 255 elements in attrs.
Modified: 2026-03-21
CVE-2023-53571
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Make intel_get_crtc_new_encoder() less oopsy The point of the WARN was to print something, not oops straight up. Currently that is precisely what happens if we can't find the connector for the crtc in the atomic state. Get the dev pointer from the atomic state instead of the potentially NULL encoder to avoid that. (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)
- https://git.kernel.org/stable/c/0fe6ef82e4f4764e8f556632e4cd93d78d448e99
- https://git.kernel.org/stable/c/54202488c835dab8c648acd107f0bb8eaa699894
- https://git.kernel.org/stable/c/631420b06597a33c72b6dcef78d1c2dea17f452d
- https://git.kernel.org/stable/c/780f303233c35eeb5132e3ee1cbc8f4cebe86dd2
- https://git.kernel.org/stable/c/8cd725315c559a8a4d18ac1d7fce1d6b9a667529
- https://git.kernel.org/stable/c/fd8b0abecdf66379e9d25d7448b942b5be379cb2
Modified: 2026-03-21
CVE-2023-53572
In the Linux kernel, the following vulnerability has been resolved: clk: imx: scu: use _safe list iterator to avoid a use after free This loop is freeing "clk" so it needs to use list_for_each_entry_safe(). Otherwise it dereferences a freed variable to get the next item on the loop.
- https://git.kernel.org/stable/c/08cc7cd2c2a29a2abf5bceb8f048c0734d3694ba
- https://git.kernel.org/stable/c/0a719f0e4b6f233979e219baff73923e76a96e09
- https://git.kernel.org/stable/c/3d90921f91fc6a8c801d527bb5848c99e335c1cf
- https://git.kernel.org/stable/c/632c60ecd25dbacee54d5581fe3aeb834b57010a
- https://git.kernel.org/stable/c/f95ff838ac39f861d1f95a0f3bbb1e01c2517d79
Modified: 2026-03-23
CVE-2023-53576
In the Linux kernel, the following vulnerability has been resolved:
null_blk: Always check queue mode setting from configfs
Make sure to check device queue mode in the null_validate_conf() and
return error for NULL_Q_RQ as we don't allow legacy I/O path, without
this patch we get OOPs when queue mode is set to 1 from configfs,
following are repro steps :-
modprobe null_blk nr_devices=0
mkdir config/nullb/nullb0
echo 1 > config/nullb/nullb0/memory_backed
echo 4096 > config/nullb/nullb0/blocksize
echo 20480 > config/nullb/nullb0/size
echo 1 > config/nullb/nullb0/queue_mode
echo 1 > config/nullb/nullb0/power
Entering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)
due to oops @ 0xffffffffc041c329
CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]
Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20
RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246
RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00
RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002
R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740
FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0
DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a
DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/35e304dbcefa95237a3d6f94c007bfb10f012b17
- https://git.kernel.org/stable/c/63f8793ee60513a09f110ea460a6ff2c33811cdb
- https://git.kernel.org/stable/c/651260e563d9f50827dac496dc8a0b9b23d5db1a
- https://git.kernel.org/stable/c/e732a266b973cd4e115e2cc2ea5007119e8a7fbc
- https://git.kernel.org/stable/c/fd35b7bb6d5a329c427924886949ab51f210200a
Modified: 2026-03-23
CVE-2023-53577
In the Linux kernel, the following vulnerability has been resolved:
bpf, cpumap: Make sure kthread is running before map update returns
The following warning was reported when running stress-mode enabled
xdp_redirect_cpu with some RT threads:
------------[ cut here ]------------
WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135
CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: events cpu_map_kthread_stop
RIP: 0010:put_cpu_map_entry+0xda/0x220
......
Call Trace:
Modified: 2026-03-23
CVE-2023-53578
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume() Syzbot reported a bug as following: ===================================================== BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 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 Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 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 It is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt) in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post(). But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot scenario. This triggers the uninit variable access bug. Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() to fix the bug.
- https://git.kernel.org/stable/c/3814d211ff13ee35f2d9437439a6c7df58524137
- https://git.kernel.org/stable/c/6417070918de3bcdbe0646e7256dae58fd8083ba
- https://git.kernel.org/stable/c/8c9ce34a6ff2c544f96ce0b088e8fd3c1b9698c4
- https://git.kernel.org/stable/c/bef57c227b52c2bde00fad33556175d36d12cfa0
- https://git.kernel.org/stable/c/c6a796ee5a639ffb83c6e5469408cc2ec16cac6a
Modified: 2026-03-23
CVE-2023-53579
In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix irq domain leak Uwe Kleine-König pointed out we still have one resource leak in the mvebu driver triggered on driver detach. Let's address it with a custom devm action.
Modified: 2026-03-23
CVE-2023-53581
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Check for NOT_READY flag state after locking
Currently the check for NOT_READY flag is performed before obtaining the
necessary lock. This opens a possibility for race condition when the flow
is concurrently removed from unready_flows list by the workqueue task,
which causes a double-removal from the list and a crash[0]. Fix the issue
by moving the flag check inside the section protected by
uplink_priv->unready_flows_lock mutex.
[0]:
[44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP
[44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1
[44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]
[44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06
[44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246
[44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00
[44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0
[44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001
[44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000
[44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000
[44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000
[44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0
[44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[44376.406339] Call Trace:
[44376.406651]
- https://git.kernel.org/stable/c/30c281a77fb1b2d362030ea243dd663201d62a21
- https://git.kernel.org/stable/c/65e64640e97c0f223e77f9ea69b5a46186b93470
- https://git.kernel.org/stable/c/82ac62d76a000871004f534ad294e763e966d3b0
- https://git.kernel.org/stable/c/e962fd5933ebc767ce2a1cf7b7c85035b5a5d04c
- https://git.kernel.org/stable/c/f7ceedd1d124217a67ed1a67bbd7a7b1288705e3
Modified: 2026-03-23
CVE-2023-53582
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds Fix a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with a CLM version string by memcpy() in brcmf_fil_iovar_data_get(). Ensure buf is null-terminated. Found by a modified version of syzkaller. [ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22 [ 33.021554][ T1896] ================================================================== [ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110 [ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896 [ 33.023852][ T1896] [ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 [ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event [ 33.026581][ T1896] Call Trace: [ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d [ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334 [ 33.028037][ T1896] ? strreplace+0xf2/0x110 [ 33.028403][ T1896] ? strreplace+0xf2/0x110 [ 33.028807][ T1896] kasan_report.cold+0x83/0xdf [ 33.029283][ T1896] ? strreplace+0xf2/0x110 [ 33.029666][ T1896] strreplace+0xf2/0x110 [ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40 [ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0 [ 33.032091][ T1896] ? find_held_lock+0x2d/0x110 [ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260 [ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 33.033582][ T1896] brcmf_attach+0x246/0xd40 [ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50 [ 33.034383][ T1896] ? kmemdup+0x30/0x40 [ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690 [ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 33.035833][ T1896] usb_probe_interface+0x25f/0x710 [ 33.036315][ T1896] really_probe+0x1be/0xa90 [ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460 [ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0 [ 33.037383][ T1896] driver_probe_device+0x49/0x120 [ 33.037790][ T1896] __device_attach_driver+0x18a/0x250 [ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120 [ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0 [ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20 [ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120 [ 33.042330][ T1896] __device_attach+0x207/0x330 [ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0 [ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0 [ 33.043515][ T1896] bus_probe_device+0x1a2/0x260 [ 33.043914][ T1896] device_add+0xa61/0x1ce0 [ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660 [ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550 [ 33.045531][ T1896] usb_set_configuration+0x984/0x1770 [ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230 [ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90 [ 33.046931][ T1896] usb_probe_device+0x9c/0x220 [ 33.047434][ T1896] really_probe+0x1be/0xa90 [ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460 [ 33.048134][ T1896] driver_probe_device+0x49/0x120 [ 33.048516][ T1896] __device_attach_driver+0x18a/0x250 [ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120 ---truncated---
- https://git.kernel.org/stable/c/0ca2efea4f11c6255061e852ac188264c469c197
- https://git.kernel.org/stable/c/3b173b4ad9c001a555f44adc7836d6fe3afbe9ec
- https://git.kernel.org/stable/c/423a1297ea72bbddf64dbb0957f2879c0f2aa5d0
- https://git.kernel.org/stable/c/660145d708be52f946a82e5b633c020f58f996de
- https://git.kernel.org/stable/c/a0f0ce1c8ab9fe90618dc394e3d1568b5a9ac154
- https://git.kernel.org/stable/c/c02f733024d70105f22de8dd0a1252a0350cd516
- https://git.kernel.org/stable/c/ecb980dc79709c02f579a9c03cb92ccec189ab38
Modified: 2026-03-23
CVE-2023-53583
In the Linux kernel, the following vulnerability has been resolved:
perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()
Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the
perf_sample_event_took() function was added to report time spent in
overflow interrupts. If the interrupt takes too long, the perf framework
will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.
When hwc->interrupts is larger than max_samples_per_tick, the
hwc->interrupts will be set to MAX_INTERRUPTS, and events will be
throttled within the __perf_event_account_interrupt() function.
However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the
PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()
function to avoid throttling. When the perf framework unthrottled the event
in the timer interrupt handler, it triggers riscv_pmu_start() function
and causes a WARN_ON_ONCE() warning, as shown below:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e
Modules linked in:
CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1
Hardware name: SiFive (DT)
epc : riscv_pmu_start+0x7c/0x8e
ra : riscv_pmu_start+0x28/0x8e
epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0
gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0
t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720
s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000
a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000
a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030
s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00
s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000
s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340
s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796
t5 : 0000000700000000 t6 : ffffaf8005269870
status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
[
Modified: 2026-03-23
CVE-2023-53584
In the Linux kernel, the following vulnerability has been resolved: ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process There are two states for ubifs writing pages: 1. Dirty, Private 2. Not Dirty, Not Private The normal process cannot go to ubifs_releasepage() which means there exists pages being private but not dirty. Reproducer[1] shows that it could occur (which maybe related to [2]) with following process: PA PB PC lock(page)[PA] ubifs_write_end attach_page_private // set Private __set_page_dirty_nobuffers // set Dirty unlock(page) write_cache_pages[PA] lock(page) clear_page_dirty_for_io(page) // clear Dirty ubifs_writepage do_truncation[PB] truncate_setsize i_size_write(inode, newsize) // newsize = 0 i_size = i_size_read(inode) // i_size = 0 end_index = i_size >> PAGE_SHIFT if (page->index > end_index) goto out // jump out: unlock(page) // Private, Not Dirty generic_fadvise[PC] lock(page) invalidate_inode_page try_to_release_page ubifs_releasepage ubifs_assert(c, 0) // bad assertion! unlock(page) truncate_pagecache[PB] Then we may get following assertion failed: UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]: UBIFS assert failed: 0, in fs/ubifs/file.c:1513 UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]: switched to read-only mode, error -22 CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308 Call Trace: dump_stack+0x13/0x1b ubifs_ro_mode+0x54/0x60 [ubifs] ubifs_assert_failed+0x4b/0x80 [ubifs] ubifs_releasepage+0x67/0x1d0 [ubifs] try_to_release_page+0x57/0xe0 invalidate_inode_page+0xfb/0x130 __invalidate_mapping_pages+0xb9/0x280 invalidate_mapping_pagevec+0x12/0x20 generic_fadvise+0x303/0x3c0 ksys_fadvise64_64+0x4c/0xb0 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215373 [2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty
Modified: 2026-03-23
CVE-2023-53585
In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sock The existing helper takes advantage of the fact that everything happens in the same RCU critical section: for sockets with SOCK_RCU_FREE set bpf_sk_assign never takes a reference. skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put if necessary. This approach assumes that SOCK_RCU_FREE is never set on a sk between bpf_sk_assign and skb_steal_sock, but this invariant is violated by unhashed UDP sockets. A new UDP socket is created in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only added in udp_lib_get_port() which happens when a socket is bound. When bpf_sk_assign was added it wasn't possible to access unhashed UDP sockets from BPF, so this wasn't a problem. This changed in commit 0c48eefae712 ("sock_map: Lift socket state restriction for datagram sockets"), but the helper wasn't adjusted accordingly. The following sequence of events will therefore lead to a refcount leak: 1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap. 2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount. 3. bind() or connect() the socket, setting SOCK_RCU_FREE. 4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE. 5. tcp_v4_rcv() skips sock_put(). Fix the problem by rejecting unhashed sockets in bpf_sk_assign(). This matches the behaviour of __inet_lookup_skb which is ultimately the goal of bpf_sk_assign().
- https://git.kernel.org/stable/c/3d4522f59fb748a54446846522941a4f09da63e9
- https://git.kernel.org/stable/c/67312adc96b5a585970d03b62412847afe2c6b01
- https://git.kernel.org/stable/c/791a12102e5191dcb6ce0b3a99d71b5a2802d12a
- https://git.kernel.org/stable/c/7dcbc0bb0e5cc1823923744befce59ac353135e6
- https://git.kernel.org/stable/c/8aa43cfbb68b25119d2ced14ec717173e2901fa2
- https://git.kernel.org/stable/c/c0ce0fb76610d5fad31f56f2ca8241a2a6717a1b
Modified: 2026-03-23
CVE-2023-53586
In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix multiple LUN_RESET handling This fixes a bug where an initiator thinks a LUN_RESET has cleaned up running commands when it hasn't. The bug was added in commit 51ec502a3266 ("target: Delete tmr from list before processing"). The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUN_RESET for each session. 3. session1's LUN_RESET loops over all the running commands from both sessions and moves them to its local drain_task_list. 4. session2's LUN_RESET does not see the LUN_RESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists. 5. sessions2's LUN_RESET will then complete with a successful response. 6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them. 7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already. Fix the bug by reverting the patch, and serialize the execution of LUN_RESETs and Preempt and Aborts. Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list, because it turns out the original patch fixed a bug that was not mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second LUN_RESET and wait on it. Then the second reset will run core_tmr_drain_tmr_list and see the first reset and wait on it resulting in a deadlock.
- https://git.kernel.org/stable/c/2c43de56f9220dca3e28c774d1c5e2cab574223a
- https://git.kernel.org/stable/c/673db054d7a2b5a470d7a25baf65956d005ad729
- https://git.kernel.org/stable/c/9158c86fd3237acaea8f0181c7836d90fd6eea10
- https://git.kernel.org/stable/c/e1f59cd18a10969d08a082264b557876ca38766e
- https://git.kernel.org/stable/c/eacfe32c3650bfd0e54224d160c431013d7f6998
- https://git.kernel.org/stable/c/ed18526289b5603bf2253dee50f1d7ec245cf397
Modified: 2026-03-23
CVE-2023-53587
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Sync IRQ works before buffer destruction If something was written to the buffer just before destruction, it may be possible (maybe not in a real system, but it did happen in ARCH=um with time-travel) to destroy the ringbuffer before the IRQ work ran, leading this KASAN report (or a crash without KASAN): BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96/0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>] __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>] tick_sched_timer+0x79/0x10c [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] Allocated by task 411: save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x2d/0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28 ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00) Add the appropriate irq_work_sync() so the work finishes before the buffers are destroyed. Prior to the commit in the Fixes tag below, there was only a single global IRQ work, so this issue didn't exist.
- https://git.kernel.org/stable/c/0a65165bd24ee9231191597b7c232376fcd70cdb
- https://git.kernel.org/stable/c/1c99f65d6af2a454bfd5207b4f6a97c8474a1191
- https://git.kernel.org/stable/c/2399b1fda025e939b6fb1ac94505bcf718534e65
- https://git.kernel.org/stable/c/2702b67f59d455072a08dc40312f9b090d4dec04
- https://git.kernel.org/stable/c/372c5ee537b8366b64b691ba29e9335525e1655e
- https://git.kernel.org/stable/c/675751bb20634f981498c7d66161584080cc061e
- https://git.kernel.org/stable/c/c63741e872fcfb10e153517750f7908f0c00f60d
- https://git.kernel.org/stable/c/d9834abd8b24d1fe8092859e436fe1e0fd467c61
- https://git.kernel.org/stable/c/fc6858b7f8e1221f62ce8c6ff8a13a349c32cd76
Modified: 2026-03-23
CVE-2023-53588
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check for station first in client probe When probing a client, first check if we have it, and then check for the channel context, otherwise you can trigger the warning there easily by probing when the AP isn't even started yet. Since a client existing means the AP is also operating, we can then keep the warning. Also simplify the moved code a bit.
Modified: 2026-03-21
CVE-2023-53589
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response. Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictly.
- https://git.kernel.org/stable/c/05ad5a4d421ce65652fcb24d46b7e273130240d6
- https://git.kernel.org/stable/c/557ba100d8cf3661ff8d71c0b4a2cba8db555ec2
- https://git.kernel.org/stable/c/682b6dc29d98e857e6ca4bbc077c7dc2899b7473
- https://git.kernel.org/stable/c/c176f03350954b795322de0bfe1d7b514db41f45
- https://git.kernel.org/stable/c/d0d39bed9e95f27a246be91c5929254ac043ed30
- https://git.kernel.org/stable/c/e519a404a5bbba37693cb10fa61794a5fce4fd9b
Modified: 2026-03-21
CVE-2023-53591
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix deadlock in tc route query code Cited commit causes ABBA deadlock[0] when peer flows are created while holding the devcom rw semaphore. Due to peer flows offload implementation the lock is taken much higher up the call chain and there is no obvious way to easily fix the deadlock. Instead, since tc route query code needs the peer eswitch structure only to perform a lookup in xarray and doesn't perform any sleeping operations with it, refactor the code for lockless execution in following ways: - RCUify the devcom 'data' pointer. When resetting the pointer synchronously wait for RCU grace period before returning. This is fine since devcom is currently only used for synchronization of pairing/unpairing of eswitches which is rare and already expensive as-is. - Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has already been used in some unlocked contexts without proper annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't an issue since all relevant code paths checked it again after obtaining the devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as "best effort" check to return NULL when devcom is being unpaired. Note that while RCU read lock doesn't prevent the unpaired flag from being changed concurrently it still guarantees that reader can continue to use 'data'. - Refactor mlx5e_tc_query_route_vport() function to use new mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock. [0]: [ 164.599612] ====================================================== [ 164.600142] WARNING: possible circular locking dependency detected [ 164.600667] 6.3.0-rc3+ #1 Not tainted [ 164.601021] ------------------------------------------------------ [ 164.601557] handler1/3456 is trying to acquire lock: [ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.603078] but task is already holding lock: [ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.604459] which lock already depends on the new lock. [ 164.605190] the existing dependency chain (in reverse order) is: [ 164.605848] -> #1 (&comp->sem){++++}-{3:3}: [ 164.606380] down_read+0x39/0x50 [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core] [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core] [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core] [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core] [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core] [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core] [ 164.610741] tc_setup_cb_add+0xd4/0x200 [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower] [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower] [ 164.612116] tc_new_tfilter+0x3fc/0xd20 [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0 [ 164.612936] netlink_rcv_skb+0x54/0x100 [ 164.613339] netlink_unicast+0x190/0x250 [ 164.613746] netlink_sendmsg+0x245/0x4a0 [ 164.614150] sock_sendmsg+0x38/0x60 [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0 [ 164.614934] ___sys_sendmsg+0x80/0xc0 [ 164.615320] __sys_sendmsg+0x51/0x90 [ 164.615701] do_syscall_64+0x3d/0x90 [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}: [ 164.617210] __lock_acquire+0x159e/0x26e0 [ 164.617638] lock_acquire+0xc2/0x2a0 [ 164.618018] __mutex_lock+0x92/0xcd0 [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.618943] post_process_attr+0x153/0x2d0 [ ---truncated---
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-03-21
CVE-2023-53593
In the Linux kernel, the following vulnerability has been resolved: cifs: Release folio lock on fscache read hit. Under the current code, when cifs_readpage_worker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as: > The filesystem should unlock the folio once the read has completed, > whether it was successful or not. Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page: $ cat /proc/3890/task/12864/stack [<0>] folio_wait_bit_common+0x124/0x350 [<0>] filemap_read_folio+0xad/0xf0 [<0>] filemap_fault+0x8b1/0xab0 [<0>] __do_fault+0x39/0x150 [<0>] do_fault+0x25c/0x3e0 [<0>] __handle_mm_fault+0x6ca/0xc70 [<0>] handle_mm_fault+0xe9/0x350 [<0>] do_user_addr_fault+0x225/0x6c0 [<0>] exc_page_fault+0x84/0x1b0 [<0>] asm_exc_page_fault+0x27/0x30 This requires a reboot to resolve; it is a deadlock. Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does not free the folio lock. This happens in __cifs_readpage_from_fscache on success. Releasing the lock at that point however is not appropriate as cifs_readahead also calls cifs_readpage_from_fscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifs_readpage_worker work like cifs_readahead.
Modified: 2026-03-21
CVE-2023-53594
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix resource leak in device_add()
When calling kobject_add() failed in device_add(), it will call
cleanup_glue_dir() to free resource. But in kobject_add(),
dev->kobj.parent has been set to NULL. This will cause resource leak.
The process is as follows:
device_add()
get_device_parent()
class_dir_create_and_add()
kobject_add() //kobject_get()
...
dev->kobj.parent = kobj;
...
kobject_add() //failed, but set dev->kobj.parent = NULL
...
glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto
//"Error" label
...
cleanup_glue_dir() //becaues glue_dir is NULL, not call
//kobject_put()
The preceding problem may cause insmod mac80211_hwsim.ko to failed.
sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'
Call Trace:
Modified: 2026-03-21
CVE-2023-53595
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: mcs: Fix NULL pointer dereferences When system is rebooted after creating macsec interface below NULL pointer dereference crashes occurred. This patch fixes those crashes by using correct order of teardown [ 3324.406942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 3324.415726] Mem abort info: [ 3324.418510] ESR = 0x96000006 [ 3324.421557] EC = 0x25: DABT (current EL), IL = 32 bits [ 3324.426865] SET = 0, FnV = 0 [ 3324.429913] EA = 0, S1PTW = 0 [ 3324.433047] Data abort info: [ 3324.435921] ISV = 0, ISS = 0x00000006 [ 3324.439748] CM = 0, WnR = 0 .... [ 3324.575915] Call trace: [ 3324.578353] cn10k_mdo_del_secy+0x24/0x180 [ 3324.582440] macsec_common_dellink+0xec/0x120 [ 3324.586788] macsec_notify+0x17c/0x1c0 [ 3324.590529] raw_notifier_call_chain+0x50/0x70 [ 3324.594965] call_netdevice_notifiers_info+0x34/0x7c [ 3324.599921] rollback_registered_many+0x354/0x5bc [ 3324.604616] unregister_netdevice_queue+0x88/0x10c [ 3324.609399] unregister_netdev+0x20/0x30 [ 3324.613313] otx2_remove+0x8c/0x310 [ 3324.616794] pci_device_shutdown+0x30/0x70 [ 3324.620882] device_shutdown+0x11c/0x204 [ 966.664930] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 966.673712] Mem abort info: [ 966.676497] ESR = 0x96000006 [ 966.679543] EC = 0x25: DABT (current EL), IL = 32 bits [ 966.684848] SET = 0, FnV = 0 [ 966.687895] EA = 0, S1PTW = 0 [ 966.691028] Data abort info: [ 966.693900] ISV = 0, ISS = 0x00000006 [ 966.697729] CM = 0, WnR = 0 [ 966.833467] Call trace: [ 966.835904] cn10k_mdo_stop+0x20/0xa0 [ 966.839557] macsec_dev_stop+0xe8/0x11c [ 966.843384] __dev_close_many+0xbc/0x140 [ 966.847298] dev_close_many+0x84/0x120 [ 966.851039] rollback_registered_many+0x114/0x5bc [ 966.855735] unregister_netdevice_many.part.0+0x14/0xa0 [ 966.860952] unregister_netdevice_many+0x18/0x24 [ 966.865560] macsec_notify+0x1ac/0x1c0 [ 966.869303] raw_notifier_call_chain+0x50/0x70 [ 966.873738] call_netdevice_notifiers_info+0x34/0x7c [ 966.878694] rollback_registered_many+0x354/0x5bc [ 966.883390] unregister_netdevice_queue+0x88/0x10c [ 966.888173] unregister_netdev+0x20/0x30 [ 966.892090] otx2_remove+0x8c/0x310 [ 966.895571] pci_device_shutdown+0x30/0x70 [ 966.899660] device_shutdown+0x11c/0x204 [ 966.903574] __do_sys_reboot+0x208/0x290 [ 966.907487] __arm64_sys_reboot+0x20/0x30 [ 966.911489] el0_svc_handler+0x80/0x1c0 [ 966.915316] el0_svc+0x8/0x180 [ 966.918362] Code: f9400000 f9400a64 91220014 f94b3403 (f9400060) [ 966.924448] ---[ end trace 341778e799c3d8d7 ]---
Modified: 2026-03-21
CVE-2023-53596
In the Linux kernel, the following vulnerability has been resolved: drivers: base: Free devm resources when unregistering a device In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da ("devres: release resources on device_del()") that got reverted by commit a525a3ddeaca ("driver core: free devres in device_release") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds.
Modified: 2026-03-23
CVE-2023-53597
In the Linux kernel, the following vulnerability has been resolved: cifs: fix mid leak during reconnection after timeout threshold When the number of responses with status of STATUS_IO_TIMEOUT exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect the connection. But we do not return the mid, or the credits returned for the mid, or reduce the number of in-flight requests. This bug could result in the server->in_flight count to go bad, and also cause a leak in the mids. This change moves the check to a few lines below where the response is decrypted, even of the response is read from the transform header. This way, the code for returning the mids can be reused. Also, the cifs_reconnect was reconnecting just the transport connection before. In case of multi-channel, this may not be what we want to do after several timeouts. Changed that to reconnect the session and the tree too. Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name MAX_STATUS_IO_TIMEOUT.
Modified: 2026-03-21
CVE-2023-53598
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Range check CHDBOFF and ERDBOFF If the value read from the CHDBOFF and ERDBOFF registers is outside the range of the MHI register space then an invalid address might be computed which later causes a kernel panic. Range check the read value to prevent a crash due to bad data from the device.
- https://git.kernel.org/stable/c/2343385fe6eed11d0432ab42a97b3ca4aef06a99
- https://git.kernel.org/stable/c/372f1752b74572b0a9d2288841eab7db17daccae
- https://git.kernel.org/stable/c/4e584127ec2bd42a37c88badb49df409f21fa40a
- https://git.kernel.org/stable/c/6a0c637bfee69a74c104468544d9f2a6579626d0
- https://git.kernel.org/stable/c/83bf6b87e2dd053d95d89eb2f01ae885f9e568db
- https://git.kernel.org/stable/c/a2cbb1a45a0c86ce77839c0875414efe1a89315e
Modified: 2026-03-23
CVE-2023-53600
In the Linux kernel, the following vulnerability has been resolved: tunnels: fix kasan splat when generating ipv4 pmtu error If we try to emit an icmp error in response to a nonliner skb, we get BUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220 Read of size 4 at addr ffff88811c50db00 by task iperf3/1691 CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309 [..] kasan_report+0x105/0x140 ip_compute_csum+0x134/0x220 iptunnel_pmtud_build_icmp+0x554/0x1020 skb_tunnel_check_pmtu+0x513/0xb80 vxlan_xmit_one+0x139e/0x2ef0 vxlan_xmit+0x1867/0x2760 dev_hard_start_xmit+0x1ee/0x4f0 br_dev_queue_push_xmit+0x4d1/0x660 [..] ip_compute_csum() cannot deal with nonlinear skbs, so avoid it. After this change, splat is gone and iperf3 is no longer stuck.
- https://git.kernel.org/stable/c/5850c391fd7e25662334cb3cbf29a62bcbff1084
- https://git.kernel.org/stable/c/6a7ac3d20593865209dceb554d8b3f094c6bd940
- https://git.kernel.org/stable/c/da5f42a6e7485fbb7a6dbd6a2b3045e19e4df5cc
- https://git.kernel.org/stable/c/e95808121953410db8c59f0abfde70ac0d34222c
- https://git.kernel.org/stable/c/fe6a9f7516735be9fdabab00e47ef7a3403a174d
Modified: 2026-03-23
CVE-2023-53601
In the Linux kernel, the following vulnerability has been resolved:
bonding: do not assume skb mac_header is set
Drivers must not assume in their ndo_start_xmit() that
skbs have their mac_header set. skb->data is all what is needed.
bonding seems to be one of the last offender as caught by syzbot:
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470
Modules linked in:
CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]
RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]
RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]
RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]
RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]
RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]
RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470
Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe <0f> 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe
RSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283
RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000
RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6
RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584
R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e
R13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76
FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/029d892b05fc5e42a1b1c0665f62cb3e4b23e6dc
- https://git.kernel.org/stable/c/37b6143376a578265add04f35161b257eeb84a5e
- https://git.kernel.org/stable/c/6a940abdef3162e5723f1495b8a49859d1708f79
- https://git.kernel.org/stable/c/bc16fc63592c419357dd4c4d82d50762102a60ef
- https://git.kernel.org/stable/c/c96cc3d9acaca53d9a81c884c23f1224b61c829b
Modified: 2026-03-23
CVE-2023-53602
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix memory leak in WMI firmware stats Memory allocated for firmware pdev, vdev and beacon statistics are not released during rmmod. Fix it by calling ath11k_fw_stats_free() function before hardware unregister. While at it, avoid calling ath11k_fw_stats_free() while processing the firmware stats received in the WMI event because the local list is getting spliced and reinitialised and hence there are no elements in the list after splicing. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Modified: 2026-03-23
CVE-2023-53603
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid fcport pointer dereference Klocwork reported warning of NULL pointer may be dereferenced. The routine exits when sa_ctl is NULL and fcport is allocated after the exit call thus causing NULL fcport pointer to dereference at the time of exit. To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.
Modified: 2026-03-23
CVE-2023-53604
In the Linux kernel, the following vulnerability has been resolved: dm integrity: call kmem_cache_destroy() in dm_integrity_init() error path Otherwise the journal_io_cache will leak if dm_register_target() fails.
- https://git.kernel.org/stable/c/3877b5c1509b16eeb1f275228fd91789cd88cf17
- https://git.kernel.org/stable/c/44f29e93a55b544dc961b6f8b4e93abaeaafb9ee
- https://git.kernel.org/stable/c/6b79a428c02769f2a11f8ae76bf866226d134887
- https://git.kernel.org/stable/c/6d126899b0747305c9d39a0bcf87e0df9c3f555b
- https://git.kernel.org/stable/c/a5d8c6bf58e5b2e70fbc15f3b08dfc1ba6f269ac
- https://git.kernel.org/stable/c/c8c9c50268729bf35f6c9bb1205f490db920454e
- https://git.kernel.org/stable/c/ca8b634fdf07dee3f6dfde57079c4511480b525e
- https://git.kernel.org/stable/c/e09a592fdd6c716506774bdbebb5f6c537b47767
- https://git.kernel.org/stable/c/ff4d6b5b38429a7731e5593680d2138bf74dd546
Modified: 2026-03-23
CVE-2023-53605
In the Linux kernel, the following vulnerability has been resolved: drm: amd: display: Fix memory leakage This commit fixes memory leakage in dc_construct_ctx() function.
- https://git.kernel.org/stable/c/1bdea8ee92a6abc650b2189fd5c53f36859baecb
- https://git.kernel.org/stable/c/6b8701be1f66064ca72733c5f6e13748cdbf8397
- https://git.kernel.org/stable/c/83ace0dd67ee386be1ddcf59dab49d6d9a54e62e
- https://git.kernel.org/stable/c/9ae15ebaefc4878d614f10cc56ea672f88cea582
- https://git.kernel.org/stable/c/d473c55ce1975c9e601c25293328a5039225d2b2
Modified: 2026-03-23
CVE-2023-53606
In the Linux kernel, the following vulnerability has been resolved: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath There are two different flavors of the nfsd4_copy struct. One is embedded in the compound and is used directly in synchronous copies. The other is dynamically allocated, refcounted and tracked in the client struture. For the embedded one, the cleanup just involves releasing any nfsd_files held on its behalf. For the async one, the cleanup is a bit more involved, and we need to dequeue it from lists, unhash it, etc. There is at least one potential refcount leak in this code now. If the kthread_create call fails, then both the src and dst nfsd_files in the original nfsd4_copy object are leaked. The cleanup in this codepath is also sort of weird. In the async copy case, we'll have up to four nfsd_file references (src and dst for both flavors of copy structure). They are both put at the end of nfsd4_do_async_copy, even though the ones held on behalf of the embedded one outlive that structure. Change it so that we always clean up the nfsd_file refs held by the embedded copy structure before nfsd4_copy returns. Rework cleanup_async_copy to handle both inter and intra copies. Eliminate nfsd4_cleanup_intra_ssc since it now becomes a no-op.
- https://git.kernel.org/stable/c/6ba434cb1a8d403ea9aad1b667c3ea3ad8b3191f
- https://git.kernel.org/stable/c/75b8c681c563ef7e85da6862354efc18d2a08b1b
- https://git.kernel.org/stable/c/8f565846fbe8182961498d4cbe618b15076a683b
- https://git.kernel.org/stable/c/b3169b6ffe036b549c296a9e71591d29a1fb3209
- https://git.kernel.org/stable/c/fd63299db8090307eae66f2aef17c8f00aafa0a9
Modified: 2026-03-23
CVE-2023-53607
In the Linux kernel, the following vulnerability has been resolved:
ALSA: ymfpci: Fix BUG_ON in probe function
The snd_dma_buffer.bytes field now contains the aligned size, which this
snd_BUG_ON() did not account for, resulting in the following:
[ 9.625915] ------------[ cut here ]------------
[ 9.633440] WARNING: CPU: 0 PID: 126 at sound/pci/ymfpci/ymfpci_main.c:2168 snd_ymfpci_create+0x681/0x698 [snd_ymfpci]
[ 9.648926] Modules linked in: snd_ymfpci(+) snd_intel_dspcfg kvm(+) snd_intel_sdw_acpi snd_ac97_codec snd_mpu401_uart snd_opl3_lib irqbypass snd_hda_codec gameport snd_rawmidi crct10dif_pclmul crc32_pclmul cfg80211 snd_hda_core polyval_clmulni polyval_generic gf128mul snd_seq_device ghash_clmulni_intel snd_hwdep ac97_bus sha512_ssse3 rfkill snd_pcm aesni_intel tg3 snd_timer crypto_simd snd mxm_wmi libphy cryptd k10temp fam15h_power pcspkr soundcore sp5100_tco wmi acpi_cpufreq mac_hid dm_multipath sg loop fuse dm_mod bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi firewire_ohci crc32c_intel firewire_core xhci_pci crc_itu_t pata_via xhci_pci_renesas floppy
[ 9.711849] CPU: 0 PID: 126 Comm: kworker/0:2 Not tainted 6.1.21-1-lts #1 08d2e5ece03136efa7c6aeea9a9c40916b1bd8da
[ 9.722200] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./990FX Extreme4, BIOS P2.70 06/05/2014
[ 9.732204] Workqueue: events work_for_cpu_fn
[ 9.736580] RIP: 0010:snd_ymfpci_create+0x681/0x698 [snd_ymfpci]
[ 9.742594] Code: 8c c0 4c 89 e2 48 89 df 48 c7 c6 92 c6 8c c0 e8 15 d0 e9 ff 48 83 c4 08 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d3 7a 33 e3 <0f> 0b e9 cb fd ff ff 41 bd fb ff ff ff eb db 41 bd f4 ff ff ff eb
[ 9.761358] RSP: 0018:ffffab64804e7da0 EFLAGS: 00010287
[ 9.766594] RAX: ffff8fa2df06c400 RBX: ffff8fa3073a8000 RCX: ffff8fa303fbc4a8
[ 9.773734] RDX: ffff8fa2df06d000 RSI: 0000000000000010 RDI: 0000000000000020
[ 9.780876] RBP: ffff8fa300b5d0d0 R08: ffff8fa3073a8e50 R09: 00000000df06bf00
[ 9.788018] R10: ffff8fa2df06bf00 R11: 00000000df068200 R12: ffff8fa3073a8918
[ 9.795159] R13: 0000000000000000 R14: 0000000000000080 R15: ffff8fa2df068200
[ 9.802317] FS: 0000000000000000(0000) GS:ffff8fa9fec00000(0000) knlGS:0000000000000000
[ 9.810414] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9.816158] CR2: 000055febaf66500 CR3: 0000000101a2e000 CR4: 00000000000406f0
[ 9.823301] Call Trace:
[ 9.825747]
- https://git.kernel.org/stable/c/32b9bd7cfc2e2d92d595386add4e111b232b351f
- https://git.kernel.org/stable/c/6be2e7522eb529b41c16d459f33bbdbcddbf5c15
- https://git.kernel.org/stable/c/81d2a7e93c8322ca6b858f6736d7fc3d034e6c23
- https://git.kernel.org/stable/c/96e34c88000febc83e41aa7db0b0a41676314818
- https://git.kernel.org/stable/c/d0217b09910c081b6471181345ea5b24025edf51
Modified: 2026-03-23
CVE-2023-53608
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread() The finalization of nilfs_segctor_thread() can race with nilfs_segctor_kill_thread() which terminates that thread, potentially causing a use-after-free BUG as KASAN detected. At the end of nilfs_segctor_thread(), it assigns NULL to "sc_task" member of "struct nilfs_sc_info" to indicate the thread has finished, and then notifies nilfs_segctor_kill_thread() of this using waitqueue "sc_wait_task" on the struct nilfs_sc_info. However, here, immediately after the NULL assignment to "sc_task", it is possible that nilfs_segctor_kill_thread() will detect it and return to continue the deallocation, freeing the nilfs_sc_info structure before the thread does the notification. This fixes the issue by protecting the NULL assignment to "sc_task" and its notification, with spinlock "sc_state_lock" of the struct nilfs_sc_info. Since nilfs_segctor_kill_thread() does a final check to see if "sc_task" is NULL with "sc_state_lock" locked, this can eliminate the race.
- https://git.kernel.org/stable/c/034cce77d52ba013ce62b4f5258c29907eb1ada5
- https://git.kernel.org/stable/c/0dbf0e64b91ee8fcb278aea93eb06fc7d56ecbcc
- https://git.kernel.org/stable/c/613bf23c070d11c525268f2945aa594704a9b764
- https://git.kernel.org/stable/c/6be49d100c22ffea3287a4b19d7639d259888e33
- https://git.kernel.org/stable/c/92684e02654c91a61a0b0561433b710bcece19fe
- https://git.kernel.org/stable/c/b4d80bd6370b81a1725b6b8f7894802c23a14e9f
- https://git.kernel.org/stable/c/bae009a2f1b7c2011d2e92d8c84868d315c0b97e
- https://git.kernel.org/stable/c/f32297dba338dc06d62286dedb3cdbd5175b1719
Modified: 2026-03-17
CVE-2023-53610
In the Linux kernel, the following vulnerability has been resolved: irqchip: Fix refcount leak in platform_irqchip_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/4401b485855700f296cae4d0db36a52948bff4fa
- https://git.kernel.org/stable/c/6caa5a2b78f5f53c433d3a3781e53325da22f0ac
- https://git.kernel.org/stable/c/b00baffcc2561374f8fe8af873d00531f19864eb
- https://git.kernel.org/stable/c/c32fb16331f612e66a7fa8930164e0dc15725b72
- https://git.kernel.org/stable/c/ea54b608d85b7536f92238f3259730fa06cb5d21
Modified: 2026-03-17
CVE-2023-53611
In the Linux kernel, the following vulnerability has been resolved: ipmi_si: fix a memleak in try_smi_init() Kmemleak reported the following leak info in try_smi_init(): unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0 [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] do_one_initcall+0x64/0x2a4 [<00000000601399ce>] do_init_module+0x50/0x300 [<000000003c12ba3c>] load_module+0x7a8/0x9e0 [<00000000c246fffe>] __se_sys_init_module+0x104/0x180 [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30 [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250 [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0 [<000000005a05337f>] el0_svc+0x24/0x3c [<000000005eb248d6>] el0_sync_handler+0x160/0x164 [<0000000030a59039>] el0_sync+0x160/0x180 The problem was that when an error occurred before handlers registration and after allocating `new_smi->si_sm`, the variable wouldn't be freed in the error handling afterwards since `shutdown_smi()` hadn't been registered yet. Fix it by adding a `kfree()` in the error handling path in `try_smi_init()`.
- https://git.kernel.org/stable/c/09cb2a71b2e982015fe0464f28da1ab42b8e6375
- https://git.kernel.org/stable/c/1bfcfea0fae0d0a6c6ff5543e6d704b3807b83ce
- https://git.kernel.org/stable/c/5c5f02e16b919c8cb6024dc3778c8d8f1fb1f26b
- https://git.kernel.org/stable/c/6cf1a126de2992b4efe1c3c4d398f8de4aed6e3f
- https://git.kernel.org/stable/c/7291af9a738d936c2d6869d030711dceb68404d0
- https://git.kernel.org/stable/c/b9bc8fbb2d416ce87f0342478dc9fcfd79f2c65f
- https://git.kernel.org/stable/c/cbb7d8a4b4beb3061b3a1847a742983a01dca381
- https://git.kernel.org/stable/c/f53ab5a2bf20fed59a2f7542d3453228b8056358
Modified: 2026-03-17
CVE-2023-53612
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Simplify platform device handling Coretemp's platform driver is unconventional. All the real work is done globally by the initcall and CPU hotplug notifiers, while the "driver" effectively just wraps an allocation and the registration of the hwmon interface in a long-winded round-trip through the driver core. The whole logic of dynamically creating and destroying platform devices to bring the interfaces up and down is error prone, since it assumes platform_device_add() will synchronously bind the driver and set drvdata before it returns, thus results in a NULL dereference if drivers_autoprobe is turned off for the platform bus. Furthermore, the unusual approach of doing that from within a CPU hotplug notifier, already commented in the code that it deadlocks suspend, also causes lockdep issues for other drivers or subsystems which may want to legitimately register a CPU hotplug notifier from a platform bus notifier. All of these issues can be solved by ripping this unusual behaviour out completely, simply tying the platform devices to the lifetime of the module itself, and directly managing the hwmon interfaces from the hotplug notifiers. There is a slight user-visible change in that /sys/bus/platform/drivers/coretemp will no longer appear, and /sys/devices/platform/coretemp.n will remain present if package n is hotplugged off, but hwmon users should really only be looking for the presence of the hwmon interfaces, whose behaviour remains unchanged.
- https://git.kernel.org/stable/c/4000384684f612b3645a944f6acde0e65ac370b8
- https://git.kernel.org/stable/c/52ea47a0ddfbc5fe05e873d3f5a59db4ba3e03fe
- https://git.kernel.org/stable/c/5735878a7b7db7e9ce731cb36cec298a9de67549
- https://git.kernel.org/stable/c/6d03bbff456befeccdd4d663177c4d6c75d0c4ff
- https://git.kernel.org/stable/c/8fcdbc4bc01365f4b10fed7db544a3149e3054fd
- https://git.kernel.org/stable/c/c57a8d14d7880521150ee801d53a0a64fdffd9c8
Modified: 2026-03-17
CVE-2023-53613
In the Linux kernel, the following vulnerability has been resolved:
dax: Fix dax_mapping_release() use after free
A CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax region
provider (like modprobe -r dax_hmem) yields:
kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000)
[..]
DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260
[..]
RIP: 0010:__lock_acquire+0x9fc/0x2260
[..]
Call Trace:
- https://git.kernel.org/stable/c/03859868ab82d57bfdd0cea1bf31f9319a5dded0
- https://git.kernel.org/stable/c/6d24b170a9db0456f577b1ab01226a2254c016a8
- https://git.kernel.org/stable/c/7310b84821f043dcf77d5e6aa0ad55dc1e10a11d
- https://git.kernel.org/stable/c/94a85474f5e3e518bdbf8c9f51cb343d734a04f7
- https://git.kernel.org/stable/c/9c2f993b6ca903c030d58451b5bf9ea27d0d17fa
- https://git.kernel.org/stable/c/f76db6781d76d8464ec2faa9752cc3fb2e4f6923
Modified: 2026-03-17
CVE-2023-53614
In the Linux kernel, the following vulnerability has been resolved: mm/ksm: fix race with VMA iteration and mm_struct teardown exit_mmap() will tear down the VMAs and maple tree with the mmap_lock held in write mode. Ensure that the maple tree is still valid by checking ksm_test_exit() after taking the mmap_lock in read mode, but before the for_each_vma() iterator dereferences a destroyed maple tree. Since the maple tree is destroyed, the flags telling lockdep to check an external lock has been cleared. Skip the for_each_vma() iterator to avoid dereferencing a maple tree without the external lock flag, which would create a lockdep warning.
Modified: 2026-03-17
CVE-2023-53615
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix deletion race condition System crash when using debug kernel due to link list corruption. The cause of the link list corruption is due to session deletion was allowed to queue up twice. Here's the internal trace that show the same port was allowed to double queue for deletion on different cpu. 20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 Move the clearing/setting of deleted flag lock.
- https://git.kernel.org/stable/c/4d7da12483e98c451a51bd294a3d3494f0aee5eb
- https://git.kernel.org/stable/c/6dfe4344c168c6ca20fe7640649aacfcefcccb26
- https://git.kernel.org/stable/c/a4628a5b98e4c6d905e1f7638242612d7db7d9c2
- https://git.kernel.org/stable/c/b05017cb4ff75eea783583f3d400059507510ab1
- https://git.kernel.org/stable/c/cd06c45b326e44f0d21dc1b3fa23e71f46847e28
- https://git.kernel.org/stable/c/f1ea164be545629bf442c22f508ad9e7b94ac100
Modified: 2026-03-17
CVE-2023-53616
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix invalid free of JFS_IP(ipimap)->i_imap in diUnmount
syzbot found an invalid-free in diUnmount:
BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]
BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674
Free of addr ffff88806f410000 by task syz-executor131/3632
CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
- https://git.kernel.org/stable/c/114ea3cb13ab25f7178cb60283adb93d2f96dad7
- https://git.kernel.org/stable/c/4de3a603010e0ca334487de24c6aab0777b7f808
- https://git.kernel.org/stable/c/5873df0195124be2f357de11bfd473ead4f90ed8
- https://git.kernel.org/stable/c/6e2bda2c192d0244b5a78b787ef20aa10cb319b7
- https://git.kernel.org/stable/c/756747d4b439e3e1159282ae89f17eefebbe9b25
- https://git.kernel.org/stable/c/88484bde6f12126616b38e43b6c00edcd941f615
- https://git.kernel.org/stable/c/c3c0f0ddd851b3fa3e9d3450bbcd561f4f850469
- https://git.kernel.org/stable/c/ef7311101ca43dd73b45bca7a30ac72d9535ff87
Modified: 2026-02-05
CVE-2023-53617
In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: socinfo: Add kfree for kstrdup Add kfree() in the later error handling in order to avoid memory leak.
Modified: 2026-02-05
CVE-2023-53618
In the Linux kernel, the following vulnerability has been resolved: btrfs: reject invalid reloc tree root keys with stack dump [BUG] Syzbot reported a crash that an ASSERT() got triggered inside prepare_to_merge(). That ASSERT() makes sure the reloc tree is properly pointed back by its subvolume tree. [CAUSE] After more debugging output, it turns out we had an invalid reloc tree: BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17 Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM, QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree. But reloc trees can only exist for subvolumes, as for non-subvolume trees, we just COW the involved tree block, no need to create a reloc tree since those tree blocks won't be shared with other trees. Only subvolumes tree can share tree blocks with other trees (thus they have BTRFS_ROOT_SHAREABLE flag). Thus this new debug output proves my previous assumption that corrupted on-disk data can trigger that ASSERT(). [FIX] Besides the dedicated fix and the graceful exit, also let tree-checker to check such root keys, to make sure reloc trees can only exist for subvolumes.
Modified: 2026-02-05
CVE-2023-53619
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: Avoid nf_ct_helper_hash uses after free If nf_conntrack_init_start() fails (for example due to a register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini() clean-up path frees the nf_ct_helper_hash map. When built with NF_CONNTRACK=y, further netfilter modules (e.g: netfilter_conntrack_ftp) can still be loaded and call nf_conntrack_helpers_register(), independently of whether nf_conntrack initialized correctly. This accesses the nf_ct_helper_hash dangling pointer and causes a uaf, possibly leading to random memory corruption. This patch guards nf_conntrack_helper_register() from accessing a freed or uninitialized nf_ct_helper_hash pointer and fixes possible uses-after-free when loading a conntrack module.
- https://git.kernel.org/stable/c/00716f25f9697d02a0d9bd622575c7c7321ba3d0
- https://git.kernel.org/stable/c/05561f822f27b9fa88fa5504ddec34bf38833034
- https://git.kernel.org/stable/c/4ee69c91cb8f9ca144bc0861969e5a1a3c6152a7
- https://git.kernel.org/stable/c/61c7a5256543ae7d24cd9d21853d514c8632e1e9
- https://git.kernel.org/stable/c/6eef7a2b933885a17679eb8ed0796ddf0ee5309b
- https://git.kernel.org/stable/c/6f03ce2f1abcb9f9d0511e3659ca6eb60e39f566
- https://git.kernel.org/stable/c/8289d422f5e484efe4a565fe18e862ecd621c175
- https://git.kernel.org/stable/c/fce5cc7cbd4b92f979bf02c9ec5fb69aaeba92d7
Modified: 2026-02-05
CVE-2023-53620
In the Linux kernel, the following vulnerability has been resolved: md: fix soft lockup in status_resync status_resync() will calculate 'curr_resync - recovery_active' to show user a progress bar like following: [============>........] resync = 61.4% 'curr_resync' and 'recovery_active' is updated in md_do_sync(), and status_resync() can read them concurrently, hence it's possible that 'curr_resync - recovery_active' can overflow to a huge number. In this case status_resync() will be stuck in the loop to print a large amount of '=', which will end up soft lockup. Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case, this way resync in progress will be reported to user.
Modified: 2026-02-05
CVE-2023-53622
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix possible data races in gfs2_show_options() Some fields such as gt_logd_secs of the struct gfs2_tune are accessed without holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val); And thus can cause data races when gfs2_show_options() and other functions such as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->ar_commit; To fix these possible data races, the lock sdp->sd_tune.gt_spin is acquired before accessing the fields of gfs2_tune and released after these accesses. Further changes by Andreas: - Don't hold the spin lock over the seq_printf operations.
- https://git.kernel.org/stable/c/235a5ae73cea29109a3e06f100493f17857e6a93
- https://git.kernel.org/stable/c/42077d4de49e4d9c773c97c42d5383b4899a8f9d
- https://git.kernel.org/stable/c/6fa0a72cbbe45db4ed967a51f9e6f4e3afe61d20
- https://git.kernel.org/stable/c/7c5b2649f6a37d45bfb7abf34c9b71d08677139f
- https://git.kernel.org/stable/c/7e5bbeb7eb813bb2568e1d5d02587df943272e57
- https://git.kernel.org/stable/c/85e888150075cb221270b64bf772341fc6bd11d9
- https://git.kernel.org/stable/c/a4f71523ed2123d63b431cc0cea4e9f363a0f054
- https://git.kernel.org/stable/c/b4a7ab57effbed42624842f2ab2a49b177c21a47
Modified: 2026-02-05
CVE-2023-53623
In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix swap_info_struct race between swapoff and get_swap_pages() The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, which can lead to memory corruption. The only place we have found where this happens is in the swapoff path. This case can be described as below: core 0 core 1 swapoff del_from_avail_list(si) waiting try lock si->lock acquire swap_avail_lock and re-add si into swap_avail_head acquire si->lock but missing si already being added again, and continuing to clear SWP_WRITEOK, etc. It can be easily found that a massive warning messages can be triggered inside get_swap_pages() by some special cases, for example, we call madvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile, run much swapon-swapoff operations (e.g. stress-ng-swap). However, in the worst case, panic can be caused by the above scene. In swapoff(), the memory used by si could be kept in swap_info[] after turning off a swap. This means memory corruption will not be caused immediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIG_PLIST_DEBUG enabled) ------------[ cut here ]------------ top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a prev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d next: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a WARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70 Modules linked in: rfkill(E) crct10dif_ce(E)... CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+ Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) pc : plist_check_prev_next_node+0x50/0x70 lr : plist_check_prev_next_node+0x50/0x70 sp : ffff0018009d3c30 x29: ffff0018009d3c40 x28: ffff800011b32a98 x27: 0000000000000000 x26: ffff001803908000 x25: ffff8000128ea088 x24: ffff800011b32a48 x23: 0000000000000028 x22: ffff001800875c00 x21: ffff800010f9e520 x20: ffff001800875c00 x19: ffff001800fdc6e0 x18: 0000000000000030 x17: 0000000000000000 x16: 0000000000000000 x15: 0736076307640766 x14: 0730073007380731 x13: 0736076307640766 x12: 0730073007380731 x11: 000000000004058d x10: 0000000085a85b76 x9 : ffff8000101436e4 x8 : ffff800011c8ce08 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff0017df9ed338 x4 : 0000000000000001 x3 : ffff8017ce62a000 x2 : ffff0017df9ed340 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: plist_check_prev_next_node+0x50/0x70 plist_check_head+0x80/0xf0 plist_add+0x28/0x140 add_to_avail_list+0x9c/0xf0 _enable_swap_info+0x78/0xb4 __do_sys_swapon+0x918/0xa10 __arm64_sys_swapon+0x20/0x30 el0_svc_common+0x8c/0x220 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 irq event stamp: 2082270 Now, si->lock locked before calling 'del_from_avail_list()' to make sure other thread see the si had been deleted and SWP_WRITEOK cleared together, will not reinsert again. This problem exists in versions after stable 5.10.y.
- https://git.kernel.org/stable/c/111a79d9b92f0a679fe300ccd3119ae9741f3d54
- https://git.kernel.org/stable/c/4bdf1514b4268d29360ba9e43becdd49955bc7ae
- https://git.kernel.org/stable/c/6fe7d6b992113719e96744d974212df3fcddc76c
- https://git.kernel.org/stable/c/85cc118ce6f1a627901b6db50c9d01f2ad78cdbf
- https://git.kernel.org/stable/c/a55f268abdb74ac5633b75a09fefb58458e9d2a2
- https://git.kernel.org/stable/c/b9927d3a60ca9ed35625470888629c074e687ba0
- https://git.kernel.org/stable/c/e7bba7ddb4318d5ea939c8db747c2c2780ab66f4
- https://git.kernel.org/stable/c/ea8c42b3b6d95ced3a4f555f04686d00ef0bb206
Modified: 2026-02-05
CVE-2023-53624
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_fq: fix integer overflow of "credit" if sch_fq is configured with "initial quantum" having values greater than INT_MAX, the first assignment of "credit" does signed integer overflow to a very negative value. In this situation, the syzkaller script provided by Cristoph triggers the CPU soft-lockup warning even with few sockets. It's not an infinite loop, but "credit" wasn't probably meant to be minus 2Gb for each new flow. Capping "initial quantum" to INT_MAX proved to fix the issue. v2: validation of "initial quantum" is done in fq_policy, instead of open coding in fq_change() _ suggested by Jakub Kicinski
- https://git.kernel.org/stable/c/2322462d6f9ad4874f4e3c63df3b5cc00cb1acbd
- https://git.kernel.org/stable/c/4b8a05e3801661a0438fcd0cdef181030d966a5a
- https://git.kernel.org/stable/c/4fbefeab88c6e79753a25099d455d3d59d2946b4
- https://git.kernel.org/stable/c/7041101ff6c3073fd8f2e99920f535b111c929cb
- https://git.kernel.org/stable/c/85f24cb2f10b2b0f2882e5786a09b4790bb3a0ad
- https://git.kernel.org/stable/c/d0b43125ec892aeb1b03e5df5aab595097da225a
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
Modified: 2026-02-03
CVE-2023-53629
In the Linux kernel, the following vulnerability has been resolved:
fs: dlm: fix use after free in midcomms commit
While working on processing dlm message in softirq context I experienced
the following KASAN use-after-free warning:
[ 151.760477] ==================================================================
[ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0
[ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347
[ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828
[ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014
[ 151.768726] Call Trace:
[ 151.769277]
Modified: 2026-02-03
CVE-2023-53631
In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-sysman: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned. This means that we need to dispose it accordingly. Use kobject_put() to dispose the duplicate attribute in such a case. Compile-tested only.
- https://git.kernel.org/stable/c/6ced15ff1746006476f1407fe722911a45a7874d
- https://git.kernel.org/stable/c/7295a996fdab7bf83dc3d4078fa8b139b8e0a1bf
- https://git.kernel.org/stable/c/9d9e03bec147407826266580e7d6ec427241d859
- https://git.kernel.org/stable/c/c5402011992bcc2b5614fe7fef24f9cdaec7473b
- https://git.kernel.org/stable/c/d079a3e1ccdd183b75db4f5289be347980b45284
Modified: 2026-02-03
CVE-2023-53634
In the Linux kernel, the following vulnerability has been resolved:
bpf, arm64: Fixed a BTI error on returning to patched function
When BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump
back to the instruction next to call site to call the patched function.
For BTI-enabled kernel, the instruction next to call site is usually
PACIASP, in this case, it's safe to jump back with BLR. But when
the call site is not followed by a PACIASP or bti, a BTI exception
is triggered.
Here is a fault log:
Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI
CPU: 0 PID: 263 Comm: test_progs Tainted: GF
Hardware name: linux,dummy-virt (DT)
pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c)
pc : bpf_fentry_test1+0xc/0x30
lr : bpf_trampoline_6442573892_0+0x48/0x1000
sp : ffff80000c0c3a50
x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050
x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a
x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101
x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001
x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001
Kernel panic - not syncing: Unhandled exception
CPU: 0 PID: 263 Comm: test_progs Tainted: GF
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0xec/0x144
show_stack+0x24/0x7c
dump_stack_lvl+0x8c/0xb8
dump_stack+0x18/0x34
panic+0x1cc/0x3ec
__el0_error_handler_common+0x0/0x130
el1h_64_sync_handler+0x60/0xd0
el1h_64_sync+0x78/0x7c
bpf_fentry_test1+0xc/0x30
bpf_fentry_test1+0xc/0x30
bpf_prog_test_run_tracing+0xdc/0x2a0
__sys_bpf+0x438/0x22a0
__arm64_sys_bpf+0x30/0x54
invoke_syscall+0x78/0x110
el0_svc_common.constprop.0+0x6c/0x1d0
do_el0_svc+0x38/0xe0
el0_svc+0x30/0xd0
el0t_64_sync_handler+0x1ac/0x1b0
el0t_64_sync+0x1a0/0x1a4
Kernel Offset: disabled
CPU features: 0x0000,00034c24,f994fdab
Memory Limit: none
And the instruction next to call site of bpf_fentry_test1 is ADD,
not PACIASP:
Modified: 2026-02-03
CVE-2023-53635
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: fix wrong ct->timeout value
(struct nf_conn)->timeout is an interval before the conntrack
confirmed. After confirmed, it becomes a timestamp.
It is observed that timeout of an unconfirmed conntrack:
- Set by calling ctnetlink_change_timeout(). As a result,
`nfct_time_stamp` was wrongly added to `ct->timeout` twice.
- Get by calling ctnetlink_dump_timeout(). As a result,
`nfct_time_stamp` was wrongly subtracted.
Call Trace:
Modified: 2026-02-03
CVE-2023-53636
In the Linux kernel, the following vulnerability has been resolved: clk: microchip: fix potential UAF in auxdev release callback Similar to commit 1c11289b34ab ("peci: cpu: Fix use-after-free in adev_release()"), the auxiliary device is not torn down in the correct order. If auxiliary_device_add() fails, the release callback will be called twice, resulting in a UAF. Due to timing, the auxdev code in this driver "took inspiration" from the aforementioned commit, and thus its bugs too! Moving auxiliary_device_uninit() to the unregister callback instead avoids the issue.
Modified: 2026-02-03
CVE-2023-53637
In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov772x: Fix memleak in ov772x_probe() A memory leak was reported when testing ov772x with bpf mock device: AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() are leaked.
- https://git.kernel.org/stable/c/1da495101ef7507eb4f4b1dbec2874d740eff251
- https://git.kernel.org/stable/c/448ce1cd50387b1345ec14eb191ef05f7afc2a26
- https://git.kernel.org/stable/c/7485edb2b6ca5960205c0a49bedfd09bba30e521
- https://git.kernel.org/stable/c/ac93f8ac66e60227bed42d5a023f0e6c15b52c0a
- https://git.kernel.org/stable/c/c86d760c1c6855a6131e78d0ddacc48c79324ac3
- https://git.kernel.org/stable/c/cc3b6011d7a9f149489eb9420c6305a779162c57
- https://git.kernel.org/stable/c/dfaafeb8e9537969e8dba75491f732478c7fa9d6
Modified: 2026-02-03
CVE-2023-53639
In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: reduce WARN to dev_dbg() in callback The warn is triggered on a known race condition, documented in the code above the test, that is correctly handled. Using WARN() hinders automated testing. Reducing severity.
- https://git.kernel.org/stable/c/0d1792c98351b7c8ebdc53d052918e77d1e512c3
- https://git.kernel.org/stable/c/1300517e371e4d0acdb0f1237477e1ed223c3a9a
- https://git.kernel.org/stable/c/484d95c69fc1143f09e4c2e3b89019d68d190a92
- https://git.kernel.org/stable/c/644df7e865e76ab7a62c67c25cbbc093c944d0ef
- https://git.kernel.org/stable/c/6f93154d61b345acbc405c6dee16afb845eb298e
- https://git.kernel.org/stable/c/75c4a8154cb6c7239fb55d5550f481f6765fb83c
- https://git.kernel.org/stable/c/cbec770521ebc455c9811a23222faf8911422d4a
- https://git.kernel.org/stable/c/e7865f84adaf75cee1a4bbf79680329eca92b4e1
- https://git.kernel.org/stable/c/f2a429e6da37e32438a9adc250cc176a889c16a4
Modified: 2026-02-03
CVE-2023-53640
In the Linux kernel, the following vulnerability has been resolved: ASoC: lpass: Fix for KASAN use_after_free out of bounds When we run syzkaller we get below Out of Bounds error. "KASAN: slab-out-of-bounds Read in regcache_flat_read" Below is the backtrace of the issue: BUG: KASAN: slab-out-of-bounds in regcache_flat_read+0x10c/0x110 Read of size 4 at addr ffffff8088fbf714 by task syz-executor.4/14144 CPU: 6 PID: 14144 Comm: syz-executor.4 Tainted: G W Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT) Call trace: dump_backtrace+0x0/0x4ec show_stack+0x34/0x50 dump_stack_lvl+0xdc/0x11c print_address_description+0x30/0x2d8 kasan_report+0x178/0x1e4 __asan_report_load4_noabort+0x44/0x50 regcache_flat_read+0x10c/0x110 regcache_read+0xf8/0x5a0 _regmap_read+0x45c/0x86c _regmap_update_bits+0x128/0x290 regmap_update_bits_base+0xc0/0x15c snd_soc_component_update_bits+0xa8/0x22c snd_soc_component_write_field+0x68/0xd4 tx_macro_put_dec_enum+0x1d0/0x268 snd_ctl_elem_write+0x288/0x474 By Error checking and checking valid values issue gets rectifies.
Modified: 2026-02-03
CVE-2023-53641
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: fix memory leak of remain_skbs hif_dev->remain_skb is allocated and used exclusively in ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is processed and subsequently freed (in error paths) only during the next call of ath9k_hif_usb_rx_stream(). So, if the urbs are deallocated between those two calls due to the device deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream() is not called next time and the allocated remain_skb is leaked. Our local Syzkaller instance was able to trigger that. remain_skb makes sense when receiving two consecutive urbs which are logically linked together, i.e. a specific data field from the first skb indicates a cached skb to be allocated, memcpy'd with some data and subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs deallocation supposedly makes that link irrelevant so we need to free the cached skb in those cases. Fix the leak by introducing a function to explicitly free remain_skb (if it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL when it has not been allocated at all (hif_dev struct is kzalloced) or when it has been processed in next call to ath9k_hif_usb_rx_stream(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/320d760a35273aa815d58b57e4fd9ba5279a3489
- https://git.kernel.org/stable/c/59073060fe0950c6ecbe12bdc06469dcac62128d
- https://git.kernel.org/stable/c/6719e3797ec52cd144c8a5ba8aaab36674800585
- https://git.kernel.org/stable/c/7654cc03eb699297130b693ec34e25f77b17c947
- https://git.kernel.org/stable/c/8f02d538878c9b1501f624595eb22ee4e5e0ff84
- https://git.kernel.org/stable/c/9b9356a3014123f0ce4b50d9278c1265173150ab
- https://git.kernel.org/stable/c/d9899318660791141ea6002fda5577b2c5d7386e
- https://git.kernel.org/stable/c/f0931fc8f4b6847c72e170d2326861c0a081d680
Modified: 2026-02-03
CVE-2023-53642
In the Linux kernel, the following vulnerability has been resolved: x86: fix clear_user_rep_good() exception handling annotation This code no longer exists in mainline, because it was removed in commit d2c95f9d6802 ("x86: don't use REP_GOOD or ERMS for user memory clearing") upstream. However, rather than backport the full range of x86 memory clearing and copying cleanups, fix the exception table annotation placement for the final 'rep movsb' in clear_user_rep_good(): rather than pointing at the actual instruction that did the user space access, it pointed to the register move just before it. That made sense from a code flow standpoint, but not from an actual usage standpoint: it means that if user access takes an exception, the exception handler won't actually find the instruction in the exception tables. As a result, rather than fixing it up and returning -EFAULT, it would then turn it into a kernel oops report instead, something like: BUG: unable to handle page fault for address: 0000000020081000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page ... RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147 ... Call Trace: __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline] clear_user arch/x86/include/asm/uaccess_64.h:124 [inline] iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800 iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline] iomap_dio_iter fs/iomap/direct-io.c:440 [inline] __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601 iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689 ext4_dio_read_iter fs/ext4/file.c:94 [inline] ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145 call_read_iter include/linux/fs.h:2183 [inline] do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733 do_iter_read+0x2f2/0x750 fs/read_write.c:796 vfs_readv+0xe5/0x150 fs/read_write.c:916 do_preadv+0x1b6/0x270 fs/read_write.c:1008 __do_sys_preadv2 fs/read_write.c:1070 [inline] __se_sys_preadv2 fs/read_write.c:1061 [inline] __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd which then looks like a filesystem bug rather than the incorrect exception annotation that it is. [ The alternative to this one-liner fix is to take the upstream series that cleans this all up: 68674f94ffc9 ("x86: don't use REP_GOOD or ERMS for small memory copies") 20f3337d350c ("x86: don't use REP_GOOD or ERMS for small memory clearing") adfcf4231b8c ("x86: don't use REP_GOOD or ERMS for user memory copies") * d2c95f9d6802 ("x86: don't use REP_GOOD or ERMS for user memory clearing") 3639a535587d ("x86: move stac/clac from user copy routines into callers") 577e6a7fd50d ("x86: inline the 'rep movs' in user copies for the FSRM case") 8c9b6a88b7e2 ("x86: improve on the non-rep 'clear_user' function") 427fda2c8a49 ("x86: improve on the non-rep 'copy_user' function") * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM") e1f2750edc4a ("x86: remove 'zerorest' argument from __copy_user_nocache()") 034ff37d3407 ("x86: rewrite '__copy_user_nocache' function") with either the whole series or at a minimum the two marked commits being needed to fix this issue ]
Modified: 2026-02-03
CVE-2023-53643
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: don't access released socket during error recovery While the error recovery work is temporarily failing reconnect attempts, running the 'nvme list' command causes a kernel NULL pointer dereference by calling getsockname() with a released socket. During error recovery work, the nvme tcp socket is released and a new one created, so it is not safe to access the socket without proper check.
Modified: 2026-02-03
CVE-2023-53644
In the Linux kernel, the following vulnerability has been resolved:
media: radio-shark: Add endpoint checks
The syzbot fuzzer was able to provoke a WARNING from the radio-shark2
driver:
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7
RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac
RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001
R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/2b580d0f03c4fc00013cd08f9ed96b87a08fd0d9
- https://git.kernel.org/stable/c/3ed6a312ac1e7278f92b1b3d95377b335ae21e89
- https://git.kernel.org/stable/c/4c3057a1927fa0b9ed8948b6f3b56b4ff9fa63d3
- https://git.kernel.org/stable/c/53764a17f5d8f0d00b13297d06b5e65fa844288b
- https://git.kernel.org/stable/c/76e31045ba030e94e72105c01b2e98f543d175ac
- https://git.kernel.org/stable/c/8a30dce9d7f70f8438956f6a01142b926c301334
- https://git.kernel.org/stable/c/afd72825b4fcb7ae4015e1c93b054f4c37a25684
- https://git.kernel.org/stable/c/b1bde4b4360c3d8a35504443efabd3243b802805
Modified: 2026-02-03
CVE-2023-53647
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Don't dereference ACPI root object handle Since the commit referenced in the Fixes: tag below the VMBus client driver is walking the ACPI namespace up from the VMBus ACPI device to the ACPI namespace root object trying to find Hyper-V MMIO ranges. However, if it is not able to find them it ends trying to walk resources of the ACPI namespace root object itself. This object has all-ones handle, which causes a NULL pointer dereference in the ACPI code (from dereferencing this pointer with an offset). This in turn causes an oops on boot with VMBus host implementations that do not provide Hyper-V MMIO ranges in their VMBus ACPI device or its ancestors. The QEMU VMBus implementation is an example of such implementation. I guess providing these ranges is optional, since all tested Windows versions seem to be able to use VMBus devices without them. Fix this by explicitly terminating the lookup at the ACPI namespace root object. Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface by default - they only do so if the KVM PV interface is missing or disabled. Example stack trace of such oops: [ 3.710827] ? __die+0x1f/0x60 [ 3.715030] ? page_fault_oops+0x159/0x460 [ 3.716008] ? exc_page_fault+0x73/0x170 [ 3.716959] ? asm_exc_page_fault+0x22/0x30 [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0 [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0 [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0 [ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200 [ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0 [ 3.723559] ? down_timeout+0x3a/0x60 [ 3.724455] ? acpi_ns_get_node+0x3a/0x60 [ 3.725412] acpi_ns_get_node+0x3a/0x60 [ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0 [ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0 [ 3.728400] acpi_rs_get_method_data+0x2b/0x70 [ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus] [ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus] [ 3.732411] acpi_walk_resources+0x78/0xd0 [ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus] [ 3.734802] platform_probe+0x3d/0x90 [ 3.735684] really_probe+0x19b/0x400 [ 3.736570] ? __device_attach_driver+0x100/0x100 [ 3.737697] __driver_probe_device+0x78/0x160 [ 3.738746] driver_probe_device+0x1f/0x90 [ 3.739743] __driver_attach+0xc2/0x1b0 [ 3.740671] bus_for_each_dev+0x70/0xc0 [ 3.741601] bus_add_driver+0x10e/0x210 [ 3.742527] driver_register+0x55/0xf0 [ 3.744412] ? 0xffffffffc039a000 [ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
Modified: 2026-02-03
CVE-2023-53648
In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer smatch error: sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error: we previously assumed 'rac97' could be null (see line 2072) remove redundant assignment, return error if rac97 is NULL.
- https://git.kernel.org/stable/c/09baf460dfba79ee6a0c72e68ccdbbba84d894df
- https://git.kernel.org/stable/c/228da1fa124470606ac19783e551f9d51a1e01b0
- https://git.kernel.org/stable/c/300e26e3e64880de5013eac8831cf44387ef752c
- https://git.kernel.org/stable/c/5f13d67027fa782096e6aee0db5dce61c4aeb613
- https://git.kernel.org/stable/c/79597c8bf64ca99eab385115743131d260339da5
- https://git.kernel.org/stable/c/809af7bb4219bdeef0dbb8b2ed700d6516d13fe9
- https://git.kernel.org/stable/c/d28b83252e150155b8b8c65b612c555e93c8b45f
- https://git.kernel.org/stable/c/e4cccff1e7ab6ea30995b6fbbb007d02647e025c
- https://git.kernel.org/stable/c/f923a582217b198b557756809ffe42ac0fad6adb
Modified: 2026-02-03
CVE-2023-53649
In the Linux kernel, the following vulnerability has been resolved: perf trace: Really free the evsel->priv area In 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in evsel->priv") it only was freeing if strcmp(evsel->tp_format->system, "syscalls") returned zero, while the corresponding initialization of evsel->priv was being performed if it was _not_ zero, i.e. if the tp system wasn't 'syscalls'. Just stop looking for that and free it if evsel->priv was set, which should be equivalent. Also use the pre-existing evsel_trace__delete() function. This resolves these leaks, detected with: $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin ================================================================= ==481565==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212 #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]# With this we plug all leaks with "perf trace sleep 1".
Modified: 2026-02-03
CVE-2023-53650
In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe() If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.
- https://git.kernel.org/stable/c/09ea1ae4a2ec17774892cfcff50f6d33dfa1e06f
- https://git.kernel.org/stable/c/3b4c21804076e461a6453ee4d09872172336aa1d
- https://git.kernel.org/stable/c/716efd08985e3104031d1b655930b1f1c45fa8a7
- https://git.kernel.org/stable/c/79a3908d1ea6c35157a6d907b1a9d8ec06015e7a
- https://git.kernel.org/stable/c/7a8f9293bee51183023c5e37e7ebf0543cd2a134
- https://git.kernel.org/stable/c/7cca0af3167dd9603da5fa6fff3392f8338e97e1
- https://git.kernel.org/stable/c/9e3858f82e3ced1e990ef7116c3a16c84e62093e
- https://git.kernel.org/stable/c/ce6e0434e502abdf966164b7c72523fb5fe54635
- https://git.kernel.org/stable/c/d97840bf5a388c6cbf6e46216887bf17be62acc2
Modified: 2026-02-03
CVE-2023-53651
In the Linux kernel, the following vulnerability has been resolved: Input: exc3000 - properly stop timer on shutdown We need to stop the timer on driver unbind or probe failures, otherwise we get UAF/Oops.
Modified: 2026-02-03
CVE-2023-53652
In the Linux kernel, the following vulnerability has been resolved: vdpa: Add features attr to vdpa_nl_policy for nlattr length check The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa features attr to avoid such bugs.
Modified: 2026-02-03
CVE-2023-53653
In the Linux kernel, the following vulnerability has been resolved: media: amphion: fix REVERSE_INULL issues reported by coverity null-checking of a pointor is suggested before dereferencing it
Modified: 2026-02-03
CVE-2023-53654
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Add validation before accessing cgx and lmac with the addition of new MAC blocks like CN10K RPM and CN10KB RPM_USX, LMACs are noncontiguous and CGX blocks are also noncontiguous. But during RVU driver initialization, the driver is assuming they are contiguous and trying to access cgx or lmac with their id which is resulting in kernel panic. This patch fixes the issue by adding proper checks. [ 23.219150] pc : cgx_lmac_read+0x38/0x70 [ 23.219154] lr : rvu_program_channels+0x3f0/0x498 [ 23.223852] sp : ffff000100d6fc80 [ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27: 000000000000005a [ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24: fffffffffff0f000
Modified: 2026-02-03
CVE-2023-53655
In the Linux kernel, the following vulnerability has been resolved: rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed Registering a kprobe on __rcu_irq_enter_check_tick() can cause kernel stack overflow as shown below. This issue can be reproduced by enabling CONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=", and then giving the following commands at the shell prompt: # cd /sys/kernel/tracing/ # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events # echo 1 > events/kprobes/enable This commit therefore adds __rcu_irq_enter_check_tick() to the kprobes blacklist using NOKPROBE_SYMBOL(). Insufficient stack space to handle exception! ESR: 0x00000000f2000004 -- BRK (AArch64) FAR: 0x0000ffffccf3e510 Task stack: [0xffff80000ad30000..0xffff80000ad38000] IRQ stack: [0xffff800008050000..0xffff800008058000] Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310] CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19 Hardware name: linux,dummy-virt (DT) pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __rcu_irq_enter_check_tick+0x0/0x1b8 lr : ct_nmi_enter+0x11c/0x138 sp : ffff80000ad30080 x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000 x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148 x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c x14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809 x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000 x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001 x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4 x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000 Kernel panic - not syncing: kernel stack overflow CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0xf8/0x108 show_stack+0x20/0x30 dump_stack_lvl+0x68/0x84 dump_stack+0x1c/0x38 panic+0x214/0x404 add_taint+0x0/0xf8 panic_bad_stack+0x144/0x160 handle_bad_stack+0x38/0x58 __bad_stack+0x78/0x7c __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 [...] el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 el1_interrupt+0x28/0x60 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68 __ftrace_set_clr_event_nolock+0x98/0x198 __ftrace_set_clr_event+0x58/0x80 system_enable_write+0x144/0x178 vfs_write+0x174/0x738 ksys_write+0xd0/0x188 __arm64_sys_write+0x4c/0x60 invoke_syscall+0x64/0x180 el0_svc_common.constprop.0+0x84/0x160 do_el0_svc+0x48/0xe8 el0_svc+0x34/0xd0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x190/0x194 SMP: stopping secondary CPUs Kernel Offset: 0x28da86000000 from 0xffff800008000000 PHYS_OFFSET: 0xfffff76600000000 CPU features: 0x00000,01a00100,0000421b Memory Limit: none
- https://git.kernel.org/stable/c/4c3d1a6720aefb02403ddfebe85db521d3af2c3b
- https://git.kernel.org/stable/c/7a29fb4a4771124bc61de397dbfc1554dbbcc19c
- https://git.kernel.org/stable/c/7b5a97333e920b69356e097f185bdc51d61e66ee
- https://git.kernel.org/stable/c/93b6295f677d96b73cfcb703532f6c7369a60d96
- https://git.kernel.org/stable/c/c8a3341b339285495cf7c8d061d659465f2311e0
- https://git.kernel.org/stable/c/eb18bc5a8678f431c500e6da1b8b5f34478d5bc1
Modified: 2026-02-03
CVE-2023-53656
In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: Don't migrate perf to the CPU going to teardown The driver needs to migrate the perf context if the current using CPU going to teardown. By the time calling the cpuhp::teardown() callback the cpu_online_mask() hasn't updated yet and still includes the CPU going to teardown. In current driver's implementation we may migrate the context to the teardown CPU and leads to the below calltrace: ... [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008 [ 368.113699][ T932] Call trace: [ 368.116834][ T932] __switch_to+0x7c/0xbc [ 368.120924][ T932] __schedule+0x338/0x6f0 [ 368.125098][ T932] schedule+0x50/0xe0 [ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24 [ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc [ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30 [ 368.144573][ T932] mutex_lock+0x50/0x60 [ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0 [ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu] [ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650 [ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190 [ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0 [ 368.175099][ T932] kthread+0x108/0x13c [ 368.179012][ T932] ret_from_fork+0x10/0x18 ... Use function cpumask_any_but() to find one correct active cpu to fixes this issue.
Modified: 2026-02-03
CVE-2023-53657
In the Linux kernel, the following vulnerability has been resolved: ice: Don't tx before switchdev is fully configured There is possibility that ice_eswitch_port_start_xmit might be called while some resources are still not allocated which might cause NULL pointer dereference. Fix this by checking if switchdev configuration was finished.
Modified: 2026-02-03
CVE-2023-53658
In the Linux kernel, the following vulnerability has been resolved: spi: bcm-qspi: return error if neither hif_mspi nor mspi is available If neither a "hif_mspi" nor "mspi" resource is present, the driver will just early exit in probe but still return success. Apart from not doing anything meaningful, this would then also lead to a null pointer access on removal, as platform_get_drvdata() would return NULL, which it would then try to dereference when trying to unregister the spi master. Fix this by unconditionally calling devm_ioremap_resource(), as it can handle a NULL res and will then return a viable ERR_PTR() if we get one. The "return 0;" was previously a "goto qspi_resource_err;" where then ret was returned, but since ret was still initialized to 0 at this place this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix use-after-free on unbind"). The issue was not introduced by this commit, only made more obvious.
- https://git.kernel.org/stable/c/217b6ea8cf7b819477bca597a6ae2d43d38ba283
- https://git.kernel.org/stable/c/22ae32d80ef590d12a2364e4621f90f7c58445c7
- https://git.kernel.org/stable/c/32b9c8f7892c19f7f5c9fed5fb410b9fd5990bb6
- https://git.kernel.org/stable/c/398e6a015877d44327f754aeb48ff3354945c78c
- https://git.kernel.org/stable/c/7c1f23ad34fcdace50275a6aa1e1969b41c6233f
- https://git.kernel.org/stable/c/a91c34357afcfaa5307e254f22a8452550a07b34
- https://git.kernel.org/stable/c/d20db3c58a7f9361e370a7850ceb60dbdf62eea3
- https://git.kernel.org/stable/c/d3dcdb43c872a3b967345144151a2c9bb9124c9b
Modified: 2026-02-03
CVE-2023-53659
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix out-of-bounds when setting channels on remove If we set channels greater during iavf_remove(), and waiting reset done would be timeout, then returned with error but changed num_active_queues directly, that will lead to OOB like the following logs. Because the num_active_queues is greater than tx/rx_rings[] allocated actually. Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) wait Result: [ 3506.152887] iavf 0000:41:02.0: Removing device [ 3510.400799] ================================================================== [ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536 [ 3510.400823] [ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1 [ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021 [ 3510.400835] Call Trace: [ 3510.400851] dump_stack+0x71/0xab [ 3510.400860] print_address_description+0x6b/0x290 [ 3510.400865] ? iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400868] kasan_report+0x14a/0x2b0 [ 3510.400873] iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400880] iavf_remove+0x2b6/0xc70 [iavf] [ 3510.400884] ? iavf_free_all_rx_resources+0x160/0x160 [iavf] [ 3510.400891] ? wait_woken+0x1d0/0x1d0 [ 3510.400895] ? notifier_call_chain+0xc1/0x130 [ 3510.400903] pci_device_remove+0xa8/0x1f0 [ 3510.400910] device_release_driver_internal+0x1c6/0x460 [ 3510.400916] pci_stop_bus_device+0x101/0x150 [ 3510.400919] pci_stop_and_remove_bus_device+0xe/0x20 [ 3510.400924] pci_iov_remove_virtfn+0x187/0x420 [ 3510.400927] ? pci_iov_add_virtfn+0xe10/0xe10 [ 3510.400929] ? pci_get_subsys+0x90/0x90 [ 3510.400932] sriov_disable+0xed/0x3e0 [ 3510.400936] ? bus_find_device+0x12d/0x1a0 [ 3510.400953] i40e_free_vfs+0x754/0x1210 [i40e] [ 3510.400966] ? i40e_reset_all_vfs+0x880/0x880 [i40e] [ 3510.400968] ? pci_get_device+0x7c/0x90 [ 3510.400970] ? pci_get_subsys+0x90/0x90 [ 3510.400982] ? pci_vfs_assigned.part.7+0x144/0x210 [ 3510.400987] ? __mutex_lock_slowpath+0x10/0x10 [ 3510.400996] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e] [ 3510.401001] sriov_numvfs_store+0x214/0x290 [ 3510.401005] ? sriov_totalvfs_show+0x30/0x30 [ 3510.401007] ? __mutex_lock_slowpath+0x10/0x10 [ 3510.401011] ? __check_object_size+0x15a/0x350 [ 3510.401018] kernfs_fop_write+0x280/0x3f0 [ 3510.401022] vfs_write+0x145/0x440 [ 3510.401025] ksys_write+0xab/0x160 [ 3510.401028] ? __ia32_sys_read+0xb0/0xb0 [ 3510.401031] ? fput_many+0x1a/0x120 [ 3510.401032] ? filp_close+0xf0/0x130 [ 3510.401038] do_syscall_64+0xa0/0x370 [ 3510.401041] ? page_fault+0x8/0x30 [ 3510.401043] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 3510.401073] RIP: 0033:0x7f3a9bb842c0 [ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d ---truncated---
- https://git.kernel.org/stable/c/0fb37ce6c01e17839e26d03222f0b44e6a3ed2b9
- https://git.kernel.org/stable/c/65ecebc9ac09427b2c65f271cd5e5bd536c3fe38
- https://git.kernel.org/stable/c/6e1d8f1332076a002e6d910d255aa5903d341c56
- https://git.kernel.org/stable/c/7c4bced3caa749ce468b0c5de711c98476b23a52
- https://git.kernel.org/stable/c/b92defe4e8ee86996c16417ad8c804cb4395fddd
Modified: 2026-02-26
CVE-2023-53660
In the Linux kernel, the following vulnerability has been resolved:
bpf, cpumap: Handle skb as well when clean up ptr_ring
The following warning was reported when running xdp_redirect_cpu with
both skb-mode and stress-mode enabled:
------------[ cut here ]------------
Incorrect XDP memory type (-2128176192) usage
WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405
Modules linked in:
CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: events __cpu_map_entry_free
RIP: 0010:__xdp_return+0x1e4/0x4a0
......
Call Trace:
Modified: 2026-02-26
CVE-2023-53661
In the Linux kernel, the following vulnerability has been resolved: bnxt: avoid overflow in bnxt_get_nvram_directory() The value of an arithmetic expression is subject of possible overflow due to a failure to cast operands to a larger data type before performing arithmetic. Used macro for multiplication instead operator for avoiding overflow. Found by Security Code and Linux Verification Center (linuxtesting.org) with SVACE.
Modified: 2026-02-06
CVE-2023-53662
In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup} If the filename casefolding fails, we'll be leaking memory from the fscrypt_name struct, namely from the 'crypto_buf.name' member. Make sure we free it in the error path on both ext4_fname_setup_filename() and ext4_fname_prepare_lookup() functions.
Modified: 2026-02-26
CVE-2023-53663
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Check instead of asserting on nested TSC scaling support
Check for nested TSC scaling support on nested SVM VMRUN instead of
asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO
has diverged from KVM's default. Userspace can trigger the WARN at will
by writing the MSR and then updating guest CPUID to hide the feature
(modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking
KVM's state_test selftest to do
vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);
after restoring state in a new VM+vCPU yields an endless supply of:
------------[ cut here ]------------
WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699
nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]
Call Trace:
Modified: 2026-02-26
CVE-2023-53666
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd938x: fix missing mbhc init error handling MBHC initialisation can fail so add the missing error handling to avoid dereferencing an error pointer when later configuring the jack: Unable to handle kernel paging request at virtual address fffffffffffffff8 pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc] lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x] Call trace: wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc] wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x] snd_soc_component_set_jack+0x28/0x8c [snd_soc_core] qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common] sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp] snd_soc_link_init+0x28/0x90 [snd_soc_core] snd_soc_bind_card+0x628/0xbfc [snd_soc_core] snd_soc_register_card+0xec/0x104 [snd_soc_core] devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core] sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]
Modified: 2026-02-26
CVE-2023-53667
In the Linux kernel, the following vulnerability has been resolved:
net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize
Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.
For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
size = SKB_DATA_ALIGN(size);
size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")
Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).
However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).
Consequently the SKB bounds checking semantics fails and panics:
skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:
- https://git.kernel.org/stable/c/2334ff0b343ba6ba7a6c0586fcc83992bbbc1776
- https://git.kernel.org/stable/c/42b78c8cc774b47023d6d16d96d54cc7015e4a07
- https://git.kernel.org/stable/c/6147745d43ff4e0d2c542e5b93e398ef0ee4db00
- https://git.kernel.org/stable/c/72d0240b0ee4794efc683975c213e4b384fea733
- https://git.kernel.org/stable/c/7e01c7f7046efc2c7c192c3619db43292b98e997
- https://git.kernel.org/stable/c/9be921854e983a81a0aeeae5febcd87093086e46
- https://git.kernel.org/stable/c/bf415bfe7573596ac213b4fd1da9e62cfc9a9413
- https://git.kernel.org/stable/c/ff484163dfb61b58f23e4dbd007de1094427669c
Modified: 2026-02-26
CVE-2023-53668
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix deadloop issue on reading trace_pipe Soft lockup occurs when reading file 'trace_pipe': watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 ? tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ? __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Through the vmcore, I found it's because in tracing_read_pipe(), ring_buffer_empty_cpu() found some buffer is not empty but then it cannot read anything due to "rb_num_of_entries() == 0" always true, Then it infinitely loop the procedure due to user buffer not been filled, see following code path: tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. find non-empty buffer here trace_find_next_entry_inc() // 2. loop here try to find an entry __find_next_entry() ring_buffer_empty_cpu(); // 3. find non-empty buffer peek_next_entry() // 4. but peek always return NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. because rb_num_of_entries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! } By some analyzing, I found that when resetting ringbuffer, the 'entries' of its pages are not all cleared (see rb_reset_cpu()). Then when reducing the ringbuffer, and if some reduced pages exist dirty 'entries' data, they will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which cause wrong 'overrun' count and eventually cause the deadloop issue. To fix it, we need to clear every pages in rb_reset_cpu().
- https://git.kernel.org/stable/c/0a29dae5786d263016a9aceb1e56bf3fd4cc6fa0
- https://git.kernel.org/stable/c/27bdd93e44cc28dd9b94893fae146b83d4f5b31e
- https://git.kernel.org/stable/c/5e68f1f3a20fe9b6bde018e353269fbfa289609c
- https://git.kernel.org/stable/c/7e42907f3a7b4ce3a2d1757f6d78336984daf8f5
- https://git.kernel.org/stable/c/8b0b63fdac6b70a45614e7d4b30e5bbb93deb007
- https://git.kernel.org/stable/c/a55e8a3596048c2f7b574049aeb1885b5abba1cc
- https://git.kernel.org/stable/c/bb14a93bccc92766b1d9302c6bcbea17d4bce306
- https://git.kernel.org/stable/c/e84829522fc72bb43556b31575731de0440ac0dd
Modified: 2026-02-26
CVE-2023-53669
In the Linux kernel, the following vulnerability has been resolved: tcp: fix skb_copy_ubufs() vs BIG TCP David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy using hugepages, and skb length bigger than ~68 KB. skb_copy_ubufs() assumed it could copy all payload using up to MAX_SKB_FRAGS order-0 pages. This assumption broke when BIG TCP was able to put up to 512 KB per skb. We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45 and limit gso_max_size to 180000. A solution is to use higher order pages if needed. v2: add missing __GFP_COMP, or we leak memory.
Modified: 2026-02-26
CVE-2023-53670
In the Linux kernel, the following vulnerability has been resolved: nvme-core: fix dev_pm_qos memleak Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to avoid following kmemleak:- blktests (master) # kmemleak-clear; ./check nvme/044; blktests (master) # kmemleak-scan ; kmemleak-show nvme/044 (Test bi-directional authentication) [passed] runtime 2.111s ... 2.124s unreferenced object 0xffff888110c46240 (size 96): comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000069ac2cec>] kmalloc_trace+0x25/0x90 [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100 [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core] [<000000007df61b4b>] 0xffffffffc05e88b3 [<00000000d152b985>] 0xffffffffc05744cb [<00000000f04a4041>] vfs_write+0xc5/0x3c0 [<00000000f9491baf>] ksys_write+0x5f/0xe0 [<000000001c46513d>] do_syscall_64+0x3b/0x90 [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Modified: 2026-02-26
CVE-2023-53671
In the Linux kernel, the following vulnerability has been resolved:
srcu: Delegate work to the boot cpu if using SRCU_SIZE_SMALL
Commit 994f706872e6 ("srcu: Make Tree SRCU able to operate without
snp_node array") assumes that cpu 0 is always online. However, there
really are situations when some other CPU is the boot CPU, for example,
when booting a kdump kernel with the maxcpus=1 boot parameter.
On PowerPC, the kdump kernel can hang as follows:
...
[ 1.740036] systemd[1]: Hostname set to
Modified: 2026-02-26
CVE-2023-53672
In the Linux kernel, the following vulnerability has been resolved: btrfs: output extra debug info if we failed to find an inline backref [BUG] Syzbot reported several warning triggered inside lookup_inline_extent_backref(). [CAUSE] As usual, the reproducer doesn't reliably trigger locally here, but at least we know the WARN_ON() is triggered when an inline backref can not be found, and it can only be triggered when @insert is true. (I.e. inserting a new inline backref, which means the backref should already exist) [ENHANCEMENT] After the WARN_ON(), dump all the parameters and the extent tree leaf to help debug.
- https://git.kernel.org/stable/c/28062cd6eda04035d8f6ded2001292ac8b496149
- https://git.kernel.org/stable/c/376b41524b71e494514720bd6114325b0a2ed19c
- https://git.kernel.org/stable/c/400e08a16604b534fdd82c5a288fa150d04f5f79
- https://git.kernel.org/stable/c/6994f806c6d1ae8b59344d3700358547f3b3fe1d
- https://git.kernel.org/stable/c/7afbfde45d665953b4d5a42a721e15bf0315d89b
- https://git.kernel.org/stable/c/7f72f50547b7af4ddf985b07fc56600a4deba281
- https://git.kernel.org/stable/c/b7c3cf2f6c42e6688b1c37215a0b1663f982f915
- https://git.kernel.org/stable/c/e70ba449b04b40584bdabb383d10455397cbf177
Modified: 2026-04-23
CVE-2023-53673
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without
hci_conn_get, so disconn_cfm must be called so they can clean up their
conn, otherwise use-after-free occurs.
ISO:
==========================================================
iso_sock_connect:880: sk 00000000eabd6557
iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da
...
iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073
hci_dev_put:1487: hci0 orig refcnt 17
__iso_chan_add:214: conn 00000000b6251073
iso_sock_clear_timer:117: sock 00000000eabd6557 state 3
...
hci_rx_work:4085: hci0 Event packet
hci_event_packet:7601: hci0: event 0x0f
hci_cmd_status_evt:4346: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3107: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560
hci_conn_unlink:1102: hci0: hcon 000000001696f1fd
hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2
hci_chan_list_flush:2780: hcon 000000001696f1fd
hci_dev_put:1487: hci0 orig refcnt 21
hci_dev_put:1487: hci0 orig refcnt 20
hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c
...
Modified: 2026-02-26
CVE-2023-53674
In the Linux kernel, the following vulnerability has been resolved: clk: Fix memory leak in devm_clk_notifier_register() devm_clk_notifier_register() allocates a devres resource for clk notifier but didn't register that to the device, so the notifier didn't get unregistered on device detach and the allocated resource was leaked. Fix the issue by registering the resource through devres_add(). This issue was found with kmemleak on a Chromebook.
- https://git.kernel.org/stable/c/49451db71b746df990888068961f1033f7c9b734
- https://git.kernel.org/stable/c/7fb933e56f77a57ef7cfc59fc34cbbf1b1fa31ff
- https://git.kernel.org/stable/c/a326cf0107b197e649bbaa2a2b1355894826ce32
- https://git.kernel.org/stable/c/cb1b04fd4283fc8f9acefe0ddc61ba072ed44877
- https://git.kernel.org/stable/c/efbbda79b2881a04dcd0e8f28634933d79e17e49
Modified: 2026-02-26
CVE-2023-53675
In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Fix possible desc_ptr out-of-bounds accesses Sanitize possible desc_ptr out-of-bounds accesses in ses_enclosure_data_process().
- https://git.kernel.org/stable/c/414418abc19fa4ccf730d273061a426c07a061d6
- https://git.kernel.org/stable/c/4b8cae410472653a59e15af62c57c49b8e0a1201
- https://git.kernel.org/stable/c/584892fd29a41ef424a148118a3103b16b94fb8c
- https://git.kernel.org/stable/c/72021ae61a2bc6ca73cd593e255a10ed5f5dc5e7
- https://git.kernel.org/stable/c/79ec5dd5fb07ecaea2f978c2d7a9f2f3526e4d19
- https://git.kernel.org/stable/c/801ab13d50cf3d26170ee073ea8bb4eececb76ab
- https://git.kernel.org/stable/c/c315560e3ef77c1d822249f1743e647dc9c9912a
- https://git.kernel.org/stable/c/cffe09ca0555e235a42d6fa065e463c4b3d5b657
Modified: 2026-02-26
CVE-2023-53676
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show() The function lio_target_nacl_info_show() uses sprintf() in a loop to print details for every iSCSI connection in a session without checking for the buffer length. With enough iSCSI connections it's possible to overflow the buffer provided by configfs and corrupt the memory. This patch replaces sprintf() with sysfs_emit_at() that checks for buffer boundries.
- https://git.kernel.org/stable/c/0cac6cbb9908309352a5d30c1876882771d3da50
- https://git.kernel.org/stable/c/114b44dddea1f8f99576de3c0e6e9059012002fc
- https://git.kernel.org/stable/c/2cbe6a88fbdd6e8aeab358eef61472e2de43d6f6
- https://git.kernel.org/stable/c/4738bf8b2d3635c2944b81b2a84d97b8c8b0978d
- https://git.kernel.org/stable/c/5353df78c22623b42a71d51226d228a8413097e2
- https://git.kernel.org/stable/c/801f287c93ff95582b0a2d2163f12870a2f076d4
- https://git.kernel.org/stable/c/bbe3ff47bf09db8956bc2eeb49d2d514d256ad2a
- https://git.kernel.org/stable/c/df349e84c2cb0dd05d98c8e1189c26ab4b116083
Modified: 2026-02-26
CVE-2023-53678
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix system suspend without fbdev being initialized
If fbdev is not initialized for some reason - in practice on platforms
without display - suspending fbdev should be skipped during system
suspend, fix this up. While at it add an assert that suspending fbdev
only happens with the display present.
This fixes the following:
[ 91.227923] PM: suspend entry (s2idle)
[ 91.254598] Filesystems sync: 0.025 seconds
[ 91.270518] Freezing user space processes
[ 91.272266] Freezing user space processes completed (elapsed 0.001 seconds)
[ 91.272686] OOM killer disabled.
[ 91.272872] Freezing remaining freezable tasks
[ 91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 91.659622] BUG: kernel NULL pointer dereference, address: 00000000000001c8
[ 91.659981] #PF: supervisor write access in kernel mode
[ 91.660252] #PF: error_code(0x0002) - not-present page
[ 91.660511] PGD 0 P4D 0
[ 91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54
[ 91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown
[ 91.661680] RIP: 0010:mutex_lock+0x19/0x30
[ 91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00
Modified: 2026-02-26
CVE-2023-53679
In the Linux kernel, the following vulnerability has been resolved: wifi: mt7601u: fix an integer underflow Fix an integer underflow that leads to a null pointer dereference in 'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet could be manipulated, which could trigger an integer underflow of 'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be bypassed, eventually leading to a dereference of the pointer 'p', which is a null pointer. Ensure that 'dma_len' is greater than 'min_seg_len'. Found by a modified version of syzkaller. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+ #139 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 RIP: 0010:skb_add_rx_frag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: mt7601u_rx_tasklet+0xc73/0x1270 ? mt7601u_submit_rx_buf.isra.0+0x510/0x510 ? tasklet_action_common.isra.0+0x79/0x2f0 tasklet_action_common.isra.0+0x206/0x2f0 __do_softirq+0x1b5/0x880 ? tasklet_unlock+0x30/0x30 run_ksoftirqd+0x26/0x50 smpboot_thread_fn+0x34f/0x7d0 ? smpboot_register_percpu_thread+0x370/0x370 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30 Modules linked in: 88XXau(O) 88x2bu(O) ---[ end trace 57f34f93b4da0f9b ]--- RIP: 0010:skb_add_rx_frag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554
- https://git.kernel.org/stable/c/1a1f43059afae5cc9409e0c3bc63bfc09bc8facb
- https://git.kernel.org/stable/c/47dc1f425af57b71111d7b01ebd24e04e8d967ef
- https://git.kernel.org/stable/c/61d0163e2be7a439cf6f82e9ad7de563ecf41e7a
- https://git.kernel.org/stable/c/67e4519afba215199b6dfa39ce5d7ea673ee4138
- https://git.kernel.org/stable/c/803f3176c5df3b5582c27ea690f204abb60b19b9
- https://git.kernel.org/stable/c/d0db59e2f718d1e2f1d2a2d8092168fdd2f3add0
Modified: 2026-02-26
CVE-2023-53680
In the Linux kernel, the following vulnerability has been resolved: NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL OPDESC() simply indexes into nfsd4_ops[] by the op's operation number, without range checking that value. It assumes callers are careful to avoid calling it with an out-of-bounds opnum value. nfsd4_decode_compound() is not so careful, and can invoke OPDESC() with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end of nfsd4_ops[].
- https://git.kernel.org/stable/c/50827896c365e0f6c8b55ed56d444dafd87c92c5
- https://git.kernel.org/stable/c/804d8e0a6e54427268790472781e03bc243f4ee3
- https://git.kernel.org/stable/c/a64160124d5a078be0c380b1e8a0bad2d040d3a1
- https://git.kernel.org/stable/c/f352c41fa718482979e7e6b71b4da2b718e381cc
- https://git.kernel.org/stable/c/ffcbcf087581ae68ddc0a21460f7ecd4315bdd0e
Modified: 2026-02-26
CVE-2023-53681
In the Linux kernel, the following vulnerability has been resolved: bcache: Fix __bch_btree_node_alloc to make the failure behavior consistent In some specific situations, the return value of __bch_btree_node_alloc may be NULL. This may lead to a potential NULL pointer dereference in caller function like a calling chain : btree_split->bch_btree_node_alloc->__bch_btree_node_alloc. Fix it by initializing the return value in __bch_btree_node_alloc.
- https://git.kernel.org/stable/c/4514847aee18d9391a0cf3aad75d3567c72795a4
- https://git.kernel.org/stable/c/587b4e8bb5dac682f09280ab35db4632b29d5ac4
- https://git.kernel.org/stable/c/7ecea5ce3dc17339c280c75b58ac93d8c8620d9f
- https://git.kernel.org/stable/c/80fca8a10b604afad6c14213fdfd816c4eda3ee4
- https://git.kernel.org/stable/c/a4405f6ee03323410d7b10966fd67b35f71b1944
- https://git.kernel.org/stable/c/b070f29a61436f6f8a2e3abc7ea4f4be81695198
- https://git.kernel.org/stable/c/f67b0e3081f2a24170280a33ac66f6b112083c03
Modified: 2026-02-26
CVE-2023-53682
In the Linux kernel, the following vulnerability has been resolved: hwmon: (xgene) Fix ioremap and memremap leak Smatch reports: drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn: 'ctx->pcc_comm_addr' from ioremap() not released on line: 757. This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(), ioremap and memremap is not released, which may cause a leak. To fix this, ioremap and memremap is modified to devm_ioremap and devm_memremap. [groeck: Fixed formatting and subject]
Modified: 2026-02-26
CVE-2023-53683
In the Linux kernel, the following vulnerability has been resolved: fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode() syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), for crafted filesystem image can contain bogus length. There conditions are not kernel bugs that can justify kernel to panic.
- https://git.kernel.org/stable/c/37cab61a52d6f42b2d961c51bcf369f09e235fb5
- https://git.kernel.org/stable/c/3a9d68d84b2e41ba3f2a727b36f035fad6800492
- https://git.kernel.org/stable/c/48960a503fcec76d3f72347b7e679dda08ca43be
- https://git.kernel.org/stable/c/61af77acd039ffd221bf7adf0dc95d0a4d377505
- https://git.kernel.org/stable/c/81b21c0f0138ff5a499eafc3eb0578ad2a99622c
- https://git.kernel.org/stable/c/a75d9211a07fed513c08c5d4861c4a36ac6a74fe
- https://git.kernel.org/stable/c/c074913b12db3632b11588b31bbfb0fa80a0a1c9
- https://git.kernel.org/stable/c/c8daee66585897a4c90d937c91e762100237bff9
Modified: 2026-02-26
CVE-2023-53684
In the Linux kernel, the following vulnerability has been resolved: xfrm: Zero padding when dumping algos and encap When copying data to user-space we should ensure that only valid data is copied over. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. This patch fixes the copying of xfrm algorithms and the encap template in xfrm_user so that padding is zeroed.
Modified: 2026-02-26
CVE-2023-53685
In the Linux kernel, the following vulnerability has been resolved: tun: Fix memory leak for detached NAPI queue. syzkaller reported [0] memory leaks of sk and skb related to the TUN device with no repro, but we can reproduce it easily with: struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun); If we enable NAPI and multi-queue on a TUN device, we can put skb into tfile->sk.sk_write_queue after the queue is detached. We should prevent it by checking tfile->detached before queuing skb. Note this must be done under tfile->sk.sk_write_queue.lock because write() and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there would be a small race window: write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb) Another solution is to call tun_queue_purge() when closing and reattaching the detached queue, but it could paper over another problems. Also, we do the same kind of test for IFF_NAPI_FRAGS. [0]: unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc unreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [< ---truncated---
Modified: 2026-02-26
CVE-2023-53687
In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk When the best clk is searched, we iterate over all possible clk. If we find a better match, the previous one, if any, needs to be freed. If a better match has already been found, we still need to free the new one, otherwise it leaks.
- https://git.kernel.org/stable/c/01dd8a43a84616c830782166ba3cceb01ad95363
- https://git.kernel.org/stable/c/1962717c4649e026a4252fe6625175affd28a593
- https://git.kernel.org/stable/c/1f426293fef1c13742b2a685bf7e363f51f6ee03
- https://git.kernel.org/stable/c/46574e5a0a2aee41e6ebb979cfe1dbaea8693e16
- https://git.kernel.org/stable/c/832e231cff476102e8204a9e7bddfe5c6154a375
- https://git.kernel.org/stable/c/933e5b2998bc3a527d15efbf1e97c9e63297aa3c
- https://git.kernel.org/stable/c/9dd8091959bc41fee51d0827276a2b982e84adf0
- https://git.kernel.org/stable/c/f0bf102ef9b05d7294bd8d506755465f6867d944
Modified: 2026-02-26
CVE-2023-54207
In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.
- https://git.kernel.org/stable/c/4c2707dfee5847dc0b5ecfbe512c29c93832fdc4
- https://git.kernel.org/stable/c/51f49e3927ad545cec0c0afb86856ccacd9f085d
- https://git.kernel.org/stable/c/58f0d1c0e494a88f301bf455da7df4366f179bbb
- https://git.kernel.org/stable/c/dd613a4e45f8d35f49a63a2064e5308fa5619e29
- https://git.kernel.org/stable/c/f283805d984343b2f216e2f4c6c7af265b9542ae
- https://git.kernel.org/stable/c/f78bb490b16ecb506d4904be4b00bf9aad6588f9
Modified: 2026-02-26
CVE-2023-54321
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential null-ptr-deref in device_add()
I got the following null-ptr-deref report while doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058
CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
- https://git.kernel.org/stable/c/17982304806c5c10924e73f7ca5556e0d7378452
- https://git.kernel.org/stable/c/2c59650d078b1b3f1ea50d5f8ee9fcc537dc02d3
- https://git.kernel.org/stable/c/7cf515bf9e8c2908dc170ecf2df117162a16c9c5
- https://git.kernel.org/stable/c/97aa8fb74bbe9aaf4ed5962a784f73b071bd16bf
- https://git.kernel.org/stable/c/f6837f34a34973ef6600c08195ed300e24e97317
Modified: 2025-02-13
CVE-2023-5717
A heap out-of-bounds write vulnerability in the Linux kernel's Linux Kernel Performance Events (perf) component can be exploited to achieve local privilege escalation. If perf_read_group() is called while an event's sibling_list is smaller than its child's sibling_list, it can increment or write to memory locations outside of the allocated buffer. We recommend upgrading past commit 32671e3799ca2e4590773fd0e63aaa4229e50c06.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/events?id=32671e3799ca2e4590773fd0e63aaa4229e50c06
- https://kernel.dance/32671e3799ca2e4590773fd0e63aaa4229e50c06
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/events?id=32671e3799ca2e4590773fd0e63aaa4229e50c06
- https://kernel.dance/32671e3799ca2e4590773fd0e63aaa4229e50c06
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2025-11-04
CVE-2023-6356
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6356
- https://bugzilla.redhat.com/show_bug.cgi?id=2254054
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6356
- https://bugzilla.redhat.com/show_bug.cgi?id=2254054
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://security.netapp.com/advisory/ntap-20240415-0002/
Modified: 2025-11-04
CVE-2023-6536
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6536
- https://bugzilla.redhat.com/show_bug.cgi?id=2254052
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/errata/RHSA-2024:3810
- https://access.redhat.com/security/cve/CVE-2023-6536
- https://bugzilla.redhat.com/show_bug.cgi?id=2254052
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/
- https://security.netapp.com/advisory/ntap-20240415-0001/
Modified: 2025-02-13
CVE-2023-6817
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free. We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a.
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- http://www.openwall.com/lists/oss-security/2023/12/22/13
- http://www.openwall.com/lists/oss-security/2023/12/22/6
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=317eb9685095678f2c9f5a8189de698c5354316a
- https://kernel.dance/317eb9685095678f2c9f5a8189de698c5354316a
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- http://www.openwall.com/lists/oss-security/2023/12/22/13
- http://www.openwall.com/lists/oss-security/2023/12/22/6
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=317eb9685095678f2c9f5a8189de698c5354316a
- https://kernel.dance/317eb9685095678f2c9f5a8189de698c5354316a
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2025-11-25
CVE-2023-6932
A use-after-free vulnerability in the Linux kernel's ipv4: igmp component can be exploited to achieve local privilege escalation. A race condition can be exploited to cause a timer be mistakenly registered on a RCU read locked object which is freed by another thread. We recommend upgrading past commit e2b706c691905fe78468c361aaabc719d0a496f1.
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e2b706c691905fe78468c361aaabc719d0a496f1
- https://kernel.dance/e2b706c691905fe78468c361aaabc719d0a496f1
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e2b706c691905fe78468c361aaabc719d0a496f1
- https://kernel.dance/e2b706c691905fe78468c361aaabc719d0a496f1
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2024-11-25
CVE-2024-0646
An out-of-bounds memory write flaw was found in the Linux kernel’s Transport Layer Security functionality in how a user calls a function splice with a ktls socket as the destination. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0850
- https://access.redhat.com/errata/RHSA-2024:0851
- https://access.redhat.com/errata/RHSA-2024:0876
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:1250
- https://access.redhat.com/errata/RHSA-2024:1251
- https://access.redhat.com/errata/RHSA-2024:1253
- https://access.redhat.com/errata/RHSA-2024:1268
- https://access.redhat.com/errata/RHSA-2024:1269
- https://access.redhat.com/errata/RHSA-2024:1278
- https://access.redhat.com/errata/RHSA-2024:1306
- https://access.redhat.com/errata/RHSA-2024:1367
- https://access.redhat.com/errata/RHSA-2024:1368
- https://access.redhat.com/errata/RHSA-2024:1377
- https://access.redhat.com/errata/RHSA-2024:1382
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/security/cve/CVE-2024-0646
- https://bugzilla.redhat.com/show_bug.cgi?id=2253908
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5a595000e267
- https://access.redhat.com/errata/RHSA-2024:0723
- https://access.redhat.com/errata/RHSA-2024:0724
- https://access.redhat.com/errata/RHSA-2024:0725
- https://access.redhat.com/errata/RHSA-2024:0850
- https://access.redhat.com/errata/RHSA-2024:0851
- https://access.redhat.com/errata/RHSA-2024:0876
- https://access.redhat.com/errata/RHSA-2024:0881
- https://access.redhat.com/errata/RHSA-2024:0897
- https://access.redhat.com/errata/RHSA-2024:1248
- https://access.redhat.com/errata/RHSA-2024:1250
- https://access.redhat.com/errata/RHSA-2024:1251
- https://access.redhat.com/errata/RHSA-2024:1253
- https://access.redhat.com/errata/RHSA-2024:1268
- https://access.redhat.com/errata/RHSA-2024:1269
- https://access.redhat.com/errata/RHSA-2024:1278
- https://access.redhat.com/errata/RHSA-2024:1306
- https://access.redhat.com/errata/RHSA-2024:1367
- https://access.redhat.com/errata/RHSA-2024:1368
- https://access.redhat.com/errata/RHSA-2024:1377
- https://access.redhat.com/errata/RHSA-2024:1382
- https://access.redhat.com/errata/RHSA-2024:1404
- https://access.redhat.com/errata/RHSA-2024:2094
- https://access.redhat.com/security/cve/CVE-2024-0646
- https://bugzilla.redhat.com/show_bug.cgi?id=2253908
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5a595000e267
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2024-1085
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability. We recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
- https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7
Modified: 2025-10-27
CVE-2024-1086
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT. We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
- http://www.openwall.com/lists/oss-security/2024/04/10/22
- http://www.openwall.com/lists/oss-security/2024/04/10/23
- http://www.openwall.com/lists/oss-security/2024/04/14/1
- http://www.openwall.com/lists/oss-security/2024/04/15/2
- http://www.openwall.com/lists/oss-security/2024/04/17/5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660
- https://github.com/Notselwyn/CVE-2024-1086
- https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/
- https://news.ycombinator.com/item?id=39828424
- https://pwning.tech/nftables/
- https://security.netapp.com/advisory/ntap-20240614-0009/
- http://www.openwall.com/lists/oss-security/2024/04/10/22
- http://www.openwall.com/lists/oss-security/2024/04/10/23
- http://www.openwall.com/lists/oss-security/2024/04/14/1
- http://www.openwall.com/lists/oss-security/2024/04/15/2
- http://www.openwall.com/lists/oss-security/2024/04/17/5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660
- https://github.com/Notselwyn/CVE-2024-1086
- https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/
- https://news.ycombinator.com/item?id=39828424
- https://pwning.tech/nftables/
- https://security.netapp.com/advisory/ntap-20240614-0009/
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-1086
Modified: 2024-11-21
CVE-2024-26588
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Prevent out-of-bounds memory access The test_tag test triggers an unhandled page fault: # ./test_tag [ 130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Oops[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [ 130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 130.642815] Modules linked in: [last unloaded: bpf_testmod(O)] [ 130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd) [ 130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] Call Trace: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [ 130.645507] [ 130.645539] Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ end trace 0000000000000000 ]--- On my machine, which has CONFIG_PAGE_SIZE_16KB=y, the test failed at loading a BPF prog with 2039 instructions: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncated---
- https://git.kernel.org/stable/c/36a87385e31c9343af9a4756598e704741250a67
- https://git.kernel.org/stable/c/4631c2dd69d928bca396f9f58baeddf85e14ced5
- https://git.kernel.org/stable/c/7924ade13a49c0067da6ea13e398102979c0654a
- https://git.kernel.org/stable/c/9aeb09f4d85a87bac46c010d75a2ea299d462f28
- https://git.kernel.org/stable/c/36a87385e31c9343af9a4756598e704741250a67
- https://git.kernel.org/stable/c/4631c2dd69d928bca396f9f58baeddf85e14ced5
- https://git.kernel.org/stable/c/7924ade13a49c0067da6ea13e398102979c0654a
- https://git.kernel.org/stable/c/9aeb09f4d85a87bac46c010d75a2ea299d462f28
Modified: 2024-11-21
CVE-2024-26589
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.
The following prog is accepted:
func#0 @0
0: R1=ctx() R10=fp0
0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx()
1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys()
2: (b7) r8 = 1024 ; R8_w=1024
3: (37) r8 /= 1 ; R8_w=scalar()
4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,
smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
5: (0f) r7 += r8
mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024
mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
=(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
var_off=(0x0; 0x400))
6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar()
7: (95) exit
This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:
BUG: unable to handle page fault for address: ffffc90014c80038
[...]
Call Trace:
- https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3
- https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed
- https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0
- https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8
- https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d
- https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3
- https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed
- https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0
- https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8
- https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d
Modified: 2024-11-21
CVE-2024-26591
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix re-attachment branch in bpf_tracing_prog_attach
The following case can cause a crash due to missing attach_btf:
1) load rawtp program
2) load fentry program with rawtp as target_fd
3) create tracing link for fentry program with target_fd = 0
4) repeat 3
In the end we have:
- prog->aux->dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one
BUG: kernel NULL pointer dereference, address: 0000000000000058
Call Trace:
- https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b
- https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0
- https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee
- https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c
- https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653
- https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b
- https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0
- https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee
- https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c
- https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653
Modified: 2024-11-21
CVE-2024-26592
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix UAF issue in ksmbd_tcp_new_connection() The race is between the handling of a new TCP connection and its disconnection. It leads to UAF on `struct tcp_transport` in ksmbd_tcp_new_connection() function.
- https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111
- https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1
- https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544
- https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126
- https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6
- https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111
- https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1
- https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544
- https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126
- https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6
Modified: 2024-11-21
CVE-2024-26594
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate mech token in session setup If client send invalid mech token in session setup request, ksmbd validate and make the error if it is invalid.
- https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e
- https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9
- https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d
- https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a
- https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b
- https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e
- https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9
- https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d
- https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a
- https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b
Modified: 2024-11-21
CVE-2024-26597
In the Linux kernel, the following vulnerability has been resolved:
net: qualcomm: rmnet: fix global oob in rmnet_policy
The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
global out-of-bounds read when parsing the netlink attributes. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5
- https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590
- https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1
- https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447
- https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468
- https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc
- https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c
- https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534
- https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5
- https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590
- https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1
- https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447
- https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468
- https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc
- https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c
- https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-11-21
CVE-2024-26598
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt.
- https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4
- https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1
- https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f
- https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703
- https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88
- https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6
- https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80
- https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4
- https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1
- https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f
- https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703
- https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88
- https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6
- https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
Modified: 2024-11-21
CVE-2024-26599
In the Linux kernel, the following vulnerability has been resolved: pwm: Fix out-of-bounds access in of_pwm_single_xlate() With args->args_count == 2 args->args[2] is not defined. Actually the flags are contained in args->args[1].
- https://git.kernel.org/stable/c/7b85554c7c2aee91171e038e4d5442ffa130b282
- https://git.kernel.org/stable/c/a297d07b9a1e4fb8cda25a4a2363a507d294b7c9
- https://git.kernel.org/stable/c/bae45b7ebb31984b63b13c3519fd724b3ce92123
- https://git.kernel.org/stable/c/e5f2b4b62977fb6c2efcbc5779e0c9dce18215f7
- https://git.kernel.org/stable/c/7b85554c7c2aee91171e038e4d5442ffa130b282
- https://git.kernel.org/stable/c/a297d07b9a1e4fb8cda25a4a2363a507d294b7c9
- https://git.kernel.org/stable/c/bae45b7ebb31984b63b13c3519fd724b3ce92123
- https://git.kernel.org/stable/c/e5f2b4b62977fb6c2efcbc5779e0c9dce18215f7
Modified: 2025-01-09
CVE-2024-26607
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: sii902x: Fix probing race issue A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge: [ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20 The issue here is as follows: - tidss probes, but is deferred as sii902x is still missing. - sii902x starts probing and enters sii902x_init(). - sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM's perspective. - sii902x calls sii902x_audio_codec_init() and platform_device_register_data() - The registration of the audio platform device causes probing of the deferred devices. - tidss probes, which eventually causes sii902x_bridge_get_edid() to be called. - sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash. Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe().
- https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9
- https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c
- https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1
- https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076
- https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9
- https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c
- https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1
- https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076
Modified: 2025-04-03
CVE-2024-26608
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix global oob in ksmbd_nl_policy
Similar to a reported issue (check the commit b33fb5b801c6 ("net:
qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds
another global out-of-bounds read for policy ksmbd_nl_policy. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810
CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a
- https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95
- https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d
- https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5
- https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa
- https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a
- https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95
- https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d
- https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5
- https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa
Modified: 2024-12-12
CVE-2024-26610
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix a memory corruption iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer.
- https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a
- https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b
- https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd
- https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32
- https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d
- https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67
- https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a
- https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b
- https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd
- https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32
- https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d
- https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-03
CVE-2024-26612
In the Linux kernel, the following vulnerability has been resolved: netfs, fscache: Prevent Oops in fscache_put_cache() This function dereferences "cache" and then checks if it's IS_ERR_OR_NULL(). Check first, then dereference.
- https://git.kernel.org/stable/c/1c45256e599061021e2c848952e50f406457e448
- https://git.kernel.org/stable/c/3be0b3ed1d76c6703b9ee482b55f7e01c369cc68
- https://git.kernel.org/stable/c/4200ad3e46ce50f410fdda302745489441bc70f0
- https://git.kernel.org/stable/c/82a9bc343ba019665d3ddc1d9a180bf0e0390cf3
- https://git.kernel.org/stable/c/1c45256e599061021e2c848952e50f406457e448
- https://git.kernel.org/stable/c/3be0b3ed1d76c6703b9ee482b55f7e01c369cc68
- https://git.kernel.org/stable/c/4200ad3e46ce50f410fdda302745489441bc70f0
- https://git.kernel.org/stable/c/82a9bc343ba019665d3ddc1d9a180bf0e0390cf3
Modified: 2025-04-03
CVE-2024-26614
In the Linux kernel, the following vulnerability has been resolved:
tcp: make sure init the accept_queue's spinlocks once
When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02
- https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2
- https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a
- https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855
- https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882
- https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3
- https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02
- https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2
- https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a
- https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855
- https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882
- https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-12
CVE-2024-26615
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
smc_run nginx
smc_run wrk -t 16 -c 1000 -d
- https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be
- https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22
- https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d
- https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a
- https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a
- https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6
- https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9
- https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c
- https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be
- https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22
- https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d
- https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a
- https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a
- https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6
- https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9
- https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-02-14
CVE-2024-26620
In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: always filter entire AP matrix The vfio_ap_mdev_filter_matrix function is called whenever a new adapter or domain is assigned to the mdev. The purpose of the function is to update the guest's AP configuration by filtering the matrix of adapters and domains assigned to the mdev. When an adapter or domain is assigned, only the APQNs associated with the APID of the new adapter or APQI of the new domain are inspected. If an APQN does not reference a queue device bound to the vfio_ap device driver, then it's APID will be filtered from the mdev's matrix when updating the guest's AP configuration. Inspecting only the APID of the new adapter or APQI of the new domain will result in passing AP queues through to a guest that are not bound to the vfio_ap device driver under certain circumstances. Consider the following: guest's AP configuration (all also assigned to the mdev's matrix): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006 unassign domain 4 unbind queue 16.0005 assign domain 4 When domain 4 is re-assigned, since only domain 4 will be inspected, the APQNs that will be examined will be: 14.0004 16.0004 Since both of those APQNs reference queue devices that are bound to the vfio_ap device driver, nothing will get filtered from the mdev's matrix when updating the guest's AP configuration. Consequently, queue 16.0005 will get passed through despite not being bound to the driver. This violates the linux device model requirement that a guest shall only be given access to devices bound to the device driver facilitating their pass-through. To resolve this problem, every adapter and domain assigned to the mdev will be inspected when filtering the mdev's matrix.
- https://git.kernel.org/stable/c/850fb7fa8c684a4c6bf0e4b6978f4ddcc5d43d11
- https://git.kernel.org/stable/c/c69d821197611678533fb3eb784fc823b921349a
- https://git.kernel.org/stable/c/cdd134d56138302976685e6c7bc4755450b3880e
- https://git.kernel.org/stable/c/d6b8d034b576f406af920a7bee81606c027b24c6
- https://git.kernel.org/stable/c/850fb7fa8c684a4c6bf0e4b6978f4ddcc5d43d11
- https://git.kernel.org/stable/c/c69d821197611678533fb3eb784fc823b921349a
- https://git.kernel.org/stable/c/cdd134d56138302976685e6c7bc4755450b3880e
- https://git.kernel.org/stable/c/d6b8d034b576f406af920a7bee81606c027b24c6
Modified: 2025-01-07
CVE-2024-26625
In the Linux kernel, the following vulnerability has been resolved:
llc: call sock_orphan() at release time
syzbot reported an interesting trace [1] caused by a stale sk->sk_wq
pointer in a closed llc socket.
In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after
calling proto_ops::release()") Eric Biggers hinted that some protocols
are missing a sock_orphan(), we need to perform a full audit.
In net-next, I plan to clear sock->sk from sock_orphan() and
amend Eric patch to add a warning.
[1]
BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812
- https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f
- https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b
- https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4
- https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee
- https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c
- https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7
- https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a
- https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812
- https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f
- https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b
- https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4
- https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee
- https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c
- https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7
- https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-14
CVE-2024-26627
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock for getting busy count because host the lock never covers that. [mkp: Drop unnecessary 'busy' variables pointed out by Bart]
- https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb
- https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0
- https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1
- https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059
- https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c
- https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c
- https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb
- https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0
- https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1
- https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059
- https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c
- https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-10
CVE-2024-26631
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...
- https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155
- https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663
- https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855
- https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900
- https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c
- https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155
- https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663
- https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855
- https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900
- https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c
Modified: 2025-03-03
CVE-2024-26632
In the Linux kernel, the following vulnerability has been resolved: block: Fix iterating over an empty bio with bio_for_each_folio_all If the bio contains no data, bio_first_folio() calls page_folio() on a NULL pointer and oopses. Move the test that we've reached the end of the bio from bio_next_folio() to bio_first_folio(). [axboe: add unlikely() to error case]
- https://git.kernel.org/stable/c/7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7
- https://git.kernel.org/stable/c/a6bd8182137a12d22d3f2cee463271bdcb491659
- https://git.kernel.org/stable/c/c6350b5cb78e9024c49eaee6fdb914ad2903a5fe
- https://git.kernel.org/stable/c/ca3ede3f5893e2d26d4dbdef1eec28a8487fafde
- https://git.kernel.org/stable/c/7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7
- https://git.kernel.org/stable/c/a6bd8182137a12d22d3f2cee463271bdcb491659
- https://git.kernel.org/stable/c/c6350b5cb78e9024c49eaee6fdb914ad2903a5fe
- https://git.kernel.org/stable/c/ca3ede3f5893e2d26d4dbdef1eec28a8487fafde
Modified: 2025-04-04
CVE-2024-26633
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim() syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken. Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage. [1] BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098 __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655 pskb_may_pull_reason include/linux/skbuff.h:2673 [inline] pskb_may_pull include/linux/skbuff.h:2681 [inline] ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendms ---truncated---
- https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee
- https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c
- https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d
- https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2
- https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183
- https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087
- https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198
- https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd
- https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee
- https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c
- https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d
- https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2
- https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183
- https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087
- https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198
- https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd
- https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://security.netapp.com/advisory/ntap-20241220-0001/
Modified: 2025-03-10
CVE-2024-26635
In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring"). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let's remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
- https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62
- https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6
- https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd
- https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097
- https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828
- https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc
- https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61
- https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8
- https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62
- https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6
- https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd
- https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097
- https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828
- https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc
- https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61
- https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-10
CVE-2024-26636
In the Linux kernel, the following vulnerability has been resolved: llc: make llc_ui_sendmsg() more robust against bonding changes syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1] Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed. This fix: - Uses LL_RESERVED_SPACE() to reserve space. - Check all conditions again after socket lock is held again. - Do not account Ethernet header for mtu limitation. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)
- https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c
- https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4
- https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b
- https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d
- https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249
- https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb
- https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b
- https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647
- https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c
- https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4
- https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b
- https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d
- https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249
- https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb
- https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b
- https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-19
CVE-2024-26638
In the Linux kernel, the following vulnerability has been resolved: nbd: always initialize struct msghdr completely syzbot complains that msg->msg_get_inq value can be uninitialized [1] struct msghdr got many new fields recently, we should always make sure their values is zero by default. [1] BUG: KMSAN: uninit-value in tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 inet_recvmsg+0x131/0x580 net/ipv4/af_inet.c:879 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x12b/0x1e0 net/socket.c:1066 __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700 worker_thread+0xf45/0x1490 kernel/workqueue.c:2781 kthread+0x3ed/0x540 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Local variable msg created at: __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 CPU: 1 PID: 7465 Comm: kworker/u5:1 Not tainted 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: nbd5-recv recv_work
- https://git.kernel.org/stable/c/1960f2b534da1e6c65fb96f9e98bda773495f406
- https://git.kernel.org/stable/c/78fbb92af27d0982634116c7a31065f24d092826
- https://git.kernel.org/stable/c/b0028f333420a65a53a63978522db680b37379dd
- https://git.kernel.org/stable/c/d9c54763e5cdbbd3f81868597fe8aca3c96e6387
- https://git.kernel.org/stable/c/1960f2b534da1e6c65fb96f9e98bda773495f406
- https://git.kernel.org/stable/c/78fbb92af27d0982634116c7a31065f24d092826
- https://git.kernel.org/stable/c/b0028f333420a65a53a63978522db680b37379dd
- https://git.kernel.org/stable/c/d9c54763e5cdbbd3f81868597fe8aca3c96e6387
Modified: 2025-03-10
CVE-2024-26640
In the Linux kernel, the following vulnerability has been resolved: tcp: add sanity checks to rx zerocopy TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs. This patch adds to can_map_frag() these additional checks: - Page must not be a compound one. - page->mapping must be NULL. This fixes the panic reported by ZhangPeng. syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy. r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)
- https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60
- https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894
- https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e
- https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e
- https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760
- https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f
- https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60
- https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894
- https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e
- https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e
- https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760
- https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-28
CVE-2024-26641
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() syzbot found __ip6_tnl_rcv() could access unitiliazed data [1]. Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head. [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
- https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6
- https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0
- https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080
- https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0
- https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a
- https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8
- https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6
- https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0
- https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080
- https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0
- https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a
- https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://security.netapp.com/advisory/ntap-20241108-0008/
Modified: 2025-07-17
CVE-2024-26644
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
If the source file descriptor to the snapshot ioctl refers to a deleted
subvolume, we get the following abort:
BTRFS: Transaction aborted (error -2)
WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c
- https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464
- https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b
- https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a
- https://git.kernel.org/stable/c/c06941564027bdbc01d2df7f41e333c11cb0482d
- https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff
- https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256
- https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c
- https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464
- https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b
- https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a
- https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff
- https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-03-17
CVE-2024-26645
In the Linux kernel, the following vulnerability has been resolved: tracing: Ensure visibility when inserting an element into tracing_map Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc) The warning looks as follows: [ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert(). The check for the presence of an element with a given key in this function is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ... The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt; The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---
- https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7
- https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b
- https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7
- https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177
- https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb
- https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c
- https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860
- https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a
- https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7
- https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b
- https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7
- https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177
- https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb
- https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c
- https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860
- https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2024-26646
In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on the boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend and hibernation. Syscore ops only run in these cases. [ rjw: Comment adjustment, subject and changelog edits ]
- https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee
- https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566
- https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9
- https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c
- https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee
- https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566
- https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9
- https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c
Modified: 2025-03-17
CVE-2024-26668
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: reject configurations that cause integer overflow Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s. Its better to reject this rather than having incorrect ratelimit.
- https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a
- https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1
- https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0
- https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b
- https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa
- https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a
- https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1
- https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0
- https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b
- https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa
Modified: 2025-03-17
CVE-2024-26671
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag.
- https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56
- https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed
- https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0
- https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f
- https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b
- https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676
- https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10
- https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2
- https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56
- https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed
- https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0
- https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f
- https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b
- https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676
- https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10
- https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-17
CVE-2024-26673
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.
- https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98
- https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8
- https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d
- https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4
- https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f
- https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e
- https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483
- https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98
- https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8
- https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d
- https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4
- https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f
- https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e
- https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-26808
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER event is reported, otherwise a stale reference to netdevice remains in the hook list.
- https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913
- https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee
- https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58
- https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f
- https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3
- https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4
- https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913
- https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee
- https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58
- https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f
- https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3
- https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-07
CVE-2024-35835
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a double-free in arfs_create_groups When `in` allocated by kvzalloc fails, arfs_create_groups will free ft->g and return an error. However, arfs_create_table, the only caller of arfs_create_groups, will hold this error and call to mlx5e_destroy_flow_table, in which the ft->g will be freed again.
- https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7
- https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b
- https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb
- https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b
- https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7
- https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056
- https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5
- https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629
- https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7
- https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b
- https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb
- https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b
- https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7
- https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056
- https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5
- https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-35837
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: clear BM pool before initialization Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue.
- https://git.kernel.org/stable/c/83f99138bf3b396f761600ab488054396fb5768f
- https://git.kernel.org/stable/c/938729484cfa535e9987ed0f86f29a2ae3a8188b
- https://git.kernel.org/stable/c/9f538b415db862e74b8c5d3abbccfc1b2b6caa38
- https://git.kernel.org/stable/c/af47faa6d3328406038b731794e7cf508c71affa
- https://git.kernel.org/stable/c/cec65f09c47d8c2d67f2bcad6cf05c490628d1ec
- https://git.kernel.org/stable/c/dc77f6ab5c3759df60ff87ed24f4d45df0f3b4c4
- https://git.kernel.org/stable/c/83f99138bf3b396f761600ab488054396fb5768f
- https://git.kernel.org/stable/c/938729484cfa535e9987ed0f86f29a2ae3a8188b
- https://git.kernel.org/stable/c/9f538b415db862e74b8c5d3abbccfc1b2b6caa38
- https://git.kernel.org/stable/c/af47faa6d3328406038b731794e7cf508c71affa
- https://git.kernel.org/stable/c/cec65f09c47d8c2d67f2bcad6cf05c490628d1ec
- https://git.kernel.org/stable/c/dc77f6ab5c3759df60ff87ed24f4d45df0f3b4c4
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-19
CVE-2024-35838
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential sta-link leak When a station is allocated, links are added but not set to valid yet (e.g. during connection to an AP MLD), we might remove the station without ever marking links valid, and leak them. Fix that.
- https://git.kernel.org/stable/c/49aaeb8c539b1633b3bd7c2df131ec578aa1eae1
- https://git.kernel.org/stable/c/587c5892976108674bbe61a8ff659de279318034
- https://git.kernel.org/stable/c/b01a74b3ca6fd51b62c67733ba7c3280fa6c5d26
- https://git.kernel.org/stable/c/e04bf59bdba0fa45d52160be676114e16be855a9
- https://git.kernel.org/stable/c/49aaeb8c539b1633b3bd7c2df131ec578aa1eae1
- https://git.kernel.org/stable/c/587c5892976108674bbe61a8ff659de279318034
- https://git.kernel.org/stable/c/b01a74b3ca6fd51b62c67733ba7c3280fa6c5d26
- https://git.kernel.org/stable/c/e04bf59bdba0fa45d52160be676114e16be855a9
Modified: 2025-09-24
CVE-2024-35839
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: replace physindev with physinif in nf_bridge_info An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge. As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack: arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.
- https://git.kernel.org/stable/c/544add1f1cfb78c3dfa3e6edcf4668f6be5e730c
- https://git.kernel.org/stable/c/7ae19ee81ca56b13c50a78de6c47d5b8fdc9d97b
- https://git.kernel.org/stable/c/9325e3188a9cf3f69fc6f32af59844bbc5b90547
- https://git.kernel.org/stable/c/9874808878d9eed407e3977fd11fee49de1e1d86
- https://git.kernel.org/stable/c/544add1f1cfb78c3dfa3e6edcf4668f6be5e730c
- https://git.kernel.org/stable/c/7ae19ee81ca56b13c50a78de6c47d5b8fdc9d97b
- https://git.kernel.org/stable/c/9325e3188a9cf3f69fc6f32af59844bbc5b90547
- https://git.kernel.org/stable/c/9874808878d9eed407e3977fd11fee49de1e1d86
Modified: 2025-09-24
CVE-2024-35840
In the Linux kernel, the following vulnerability has been resolved: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect() subflow_finish_connect() uses four fields (backup, join_id, thmac, none) that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set in mptcp_parse_option()
- https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
- https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
- https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
- https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
- https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb
- https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
- https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
- https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
- https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
- https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb
Modified: 2025-09-19
CVE-2024-35842
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: sof-common: Add NULL check for normal_link string It's not granted that all entries of struct sof_conn_stream declare a `normal_link` (a non-SOF, direct link) string, and this is the case for SoCs that support only SOF paths (hence do not support both direct and SOF usecases). For example, in the case of MT8188 there is no normal_link string in any of the sof_conn_stream entries and there will be more drivers doing that in the future. To avoid possible NULL pointer KPs, add a NULL check for `normal_link`.
- https://git.kernel.org/stable/c/b1d3db6740d0997ffc6e5a0d96ef7cbd62b35fdd
- https://git.kernel.org/stable/c/cad471227a37c0c7c080bfc9ed01b53750e82afe
- https://git.kernel.org/stable/c/cde6ca5872bf67744dffa875a7cb521ab007b7ef
- https://git.kernel.org/stable/c/e3b3ec967a7d93b9010a5af9a2394c8b5c8f31ed
- https://git.kernel.org/stable/c/b1d3db6740d0997ffc6e5a0d96ef7cbd62b35fdd
- https://git.kernel.org/stable/c/cad471227a37c0c7c080bfc9ed01b53750e82afe
- https://git.kernel.org/stable/c/cde6ca5872bf67744dffa875a7cb521ab007b7ef
- https://git.kernel.org/stable/c/e3b3ec967a7d93b9010a5af9a2394c8b5c8f31ed
