ALT-PU-2023-8472-18
Package kernel-image-std-def updated to version 5.10.188-alt1 for branch p10 in task 325669.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2023-03677
Уязвимость подсистемы Netfilter ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2023-03778
Уязвимость функции nft_byteorder_eval() в модуле net/netfilter/nft_byteorder.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-04-27
BDU:2023-03947
Уязвимость функции nft_chain_lookup_byid() в модуле net/netfilter/nf_tables_api.c подсистемы фильтрации пакетов netfilter ядра операционной системы 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-01-31
BDU:2023-07976
Уязвимость функции nf_conntrack_dccp_packet() модуля net/netfilter/nf_conntrack_proto_dccp.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2024-10-10
BDU:2024-06074
Уязвимость функции svc_tcp_listen_data_ready() реализации протокола RPC (Remote Procedure Call) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-00165
Уязвимость функции bcm_release() в модуле net/can/bcm.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-12977
Уязвимость функции pcie_link_state() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14376
Уязвимость функции cma_cancel_operation() модуля drivers/infiniband/core/cma.c драйвера поддержки InfiniBand ядра операционной системы 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-16287
Уязвимость модуля drivers/clk/tegra/clk-tegra124-emc.c ядра операционной системы 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-02203
Уязвимость функции qla2x00_terminate_rport_io() в модуле drivers/scsi/qla2xxx/qla_attr.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02264
Уязвимость функции dbMount() в модуле fs/jfs/jfs_dmap.c файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02513
Уязвимость функции ena_com_comp_status_to_errno() модуля drivers/net/ethernet/amazon/ena/ena_com.c драйвера сетевых адаптеров Ethernet Amazon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03348
Уязвимость функции qla_nvme_ls_req() модуля drivers/scsi/qla2xxx/qla_nvme.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03356
Уязвимость функции find_tosym() модуля scripts/mod/modpost.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03360
Уязвимость функции raid10_sync_request() модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы 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-03835
Уязвимость функции mipid_spi_probe() модуля drivers/video/fbdev/omap/lcd_mipid.c драйвера устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03889
Уязвимость функции imx8mn_clocks_probe() модуля drivers/clk/imx/clk-imx8mn.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03912
Уязвимость функции dp_display_remove() модуля drivers/gpu/drm/msm/dp/dp_display.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03923
Уязвимость функции rcu_scale_cleanup() модуля kernel/rcu/rcuscale.c подсистемы синхронизации в многопоточных системах ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03954
Уязвимость функции btrfs_reduce_alloc_profile() модуля fs/btrfs/block-group.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04075
Уязвимость функции __bch_btree_node_alloc() модуля drivers/md/bcache/btree.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04081
Уязвимость функции io_ring_exit_work() модуля io_uring/io_uring.c интерфейса асинхронного ввода/вывода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04090
Уязвимость функции snd_ac97_mixer() модуля sound/pci/ac97/ac97_codec.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04106
Уязвимость функции rb_reset_cpu() модуля kernel/trace/ring_buffer.c поддержки трассировки ядра операционной системы 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-04117
Уязвимость функции s3c24xx_serial_getclk() модуля drivers/tty/serial/samsung_tty.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04406
Уязвимость функции iavf_alloc_q_vectors() модуля drivers/net/ethernet/intel/iavf/iavf_main.c драйвера сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04415
Уязвимость функции event_hist_trigger_parse() модуля kernel/trace/trace_events_hist.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04589
Уязвимость функции qla24xx_build_scsi_type_6_iocbs() модуля drivers/scsi/qla2xxx/qla_iocb.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04612
Уязвимость функции drm_client_modeset_probe() модуля drivers/gpu/drm/drm_client_modeset.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04624
Уязвимость функции qla24xx_bsg_request() модуля drivers/scsi/qla2xxx/qla_bsg.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05737
Уязвимость модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05739
Уязвимость функции tracing_err_log_open() модуля kernel/trace/trace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05868
Уязвимость компонента Wi-Fi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05870
Уязвимость функции bnxt_re() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05896
Уязвимость функции ramfs_kill_sb() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05995
Уязвимость функции addrconf_del_dad_work() модуля net/ipv6/addrconf.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05998
Уязвимость функции dwc3_qcom_probe() модуля drivers/usb/dwc3/dwc3-qcom.c драйвера контроллера на базе DesignWare USB3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06010
Уязвимость функции icmp6_dev() модуля net/ipv6/icmp.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06011
Уязвимость функции __acquires() модуля drivers/md/md-bitmap.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-09-23
CVE-2021-47391
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests The FSM can run in a circle allowing rdma_resolve_ip() to be called twice on the same id_priv. While this cannot happen without going through the work, it violates the invariant that the same address resolution background request cannot be active twice. CPU 1 CPU 2 rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): for #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND mutex_unlock(&id_priv->handler_mutex); [.. handler still running ..] rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) !! two requests are now on the req_list rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel() // process_one_req() self removes it spin_lock_bh(&lock); cancel_delayed_work(&req->work); if (!list_empty(&req->list)) == true ! rdma_addr_cancel() returns after process_on_req #1 is done kfree(id_priv) process_one_req(): for #2 addr_handler(): mutex_lock(&id_priv->handler_mutex); !! Use after free on id_priv rdma_addr_cancel() expects there to be one req on the list and only cancels the first one. The self-removal behavior of the work only happens after the handler has returned. This yields a situations where the req_list can have two reqs for the same "handle" but rdma_addr_cancel() only cancels the first one. The second req remains active beyond rdma_destroy_id() and will use-after-free id_priv once it inevitably triggers. Fix this by remembering if the id_priv has called rdma_resolve_ip() and always cancel before calling it again. This ensures the req_list never gets more than one item in it and doesn't cost anything in the normal flow that never uses this strange error path.
- https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589
- https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808
- https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a
- https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589
- https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808
- https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a
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: 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-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-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: 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: 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-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-53151
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: prevent soft lockup while flush writes
Currently, there is no limit for raid1/raid10 plugged bio. While flushing
writes, raid1 has cond_resched() while raid10 doesn't, and too many
writes can cause soft lockup.
Follow up soft lockup can be triggered easily with writeback test for
raid10 with ramdisks:
watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]
Call Trace:
- https://git.kernel.org/stable/c/00ecb6fa67c0f772290c5ea5ae8b46eefd503b83
- https://git.kernel.org/stable/c/010444623e7f4da6b4a4dd603a7da7469981e293
- https://git.kernel.org/stable/c/1d467e10507167eb6dc2c281a87675b731955d86
- https://git.kernel.org/stable/c/634daf6b2c81015cc5e28bf694a6a94a50c641cd
- https://git.kernel.org/stable/c/84a578961b2566e475bfa8740beaf0abcc781a6f
- https://git.kernel.org/stable/c/d0345f7c7dbc5d42e4e6f1db99c1c1879d7b0eb5
- https://git.kernel.org/stable/c/f45b2fa7678ab385299de345f7e85d05caea386b
- https://git.kernel.org/stable/c/fbf50184190d55f8717bd29aa9530c399be96f30
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-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-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-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-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: 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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
