ALT-BU-2023-3084-23
Branch c9f2 update bulletin.
Closed vulnerabilities
Modified: 2026-01-20
BDU:2023-02265
Уязвимость DNS-сервера Dnsmasq. связанная с неограниченным распределением ресурсов, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-03
CVE-2023-28450
An issue was discovered in Dnsmasq before 2.90. The default maximum EDNS.0 UDP packet size was set to 4096 but should be 1232 because of DNS Flag Day 2020.
- https://capec.mitre.org/data/definitions/495.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6UQ6LKDTLSSD64TBIZ3XEKBM2SWC63VV/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OU2ZT4ITSEOOR2CFBAHK4Z67KXJIEWQA/
- https://thekelleys.org.uk/dnsmasq/doc.html
- https://thekelleys.org.uk/gitweb/?p=dnsmasq.git%3Ba=blob%3Bf=CHANGELOG
- https://thekelleys.org.uk/gitweb/?p=dnsmasq.git%3Ba=commit%3Bh=eb92fb32b746f2104b0f370b5b295bb8dd4bd5e5
- https://capec.mitre.org/data/definitions/495.html
- https://lists.debian.org/debian-lts-announce/2024/11/msg00035.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6UQ6LKDTLSSD64TBIZ3XEKBM2SWC63VV/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OU2ZT4ITSEOOR2CFBAHK4Z67KXJIEWQA/
- https://thekelleys.org.uk/dnsmasq/doc.html
- https://thekelleys.org.uk/gitweb/?p=dnsmasq.git%3Ba=blob%3Bf=CHANGELOG
- https://thekelleys.org.uk/gitweb/?p=dnsmasq.git%3Ba=commit%3Bh=eb92fb32b746f2104b0f370b5b295bb8dd4bd5e5
Package kernel-image-std-def updated to version 5.10.176-alt0.c9f.2 for branch c9f2 in task 317233.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2023-01218
Уязвимость функции ene_remove() (drivers/media/rc/ene_ir.c) драйвера инфракрасного приемника\передатчика ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-09-30
BDU:2023-01280
Уязвимость функции _pick_next_task_rt() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02165
Уязвимость фильтра индексирования системы контроля трафика tcindex (net/sched/cls_tcindex.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2026-02-17
BDU:2025-12418
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12788
Уязвимость модуля crypto/xts.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12857
Уязвимость функции udf_merge_extents() в модуле fs/udf/inode.c файловой системы OSTA-UDF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-12901
Уязвимость модуля drivers/scsi/mpt3sas/mpt3sas_base.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12975
Уязвимость функции pm_runtime_resume_and_get() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16229
Уязвимость функции ses_intf_remove() компонента scsi ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-01331
Уязвимость функции ses_enclosure_data_process() модуля drivers/scsi/ses.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01496
Уязвимость функции radeon_atombios_fini() модуля drivers/gpu/drm/radeon/radeon_device.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01502
Уязвимость функции bcmgenet_desc_rx() модуля drivers/net/ethernet/broadcom/genet/bcmgenet.c драйвера сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01521
Уязвимость функций ext4_mb_clear_bb() и ext4_free_blocks() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01525
Уязвимость функции brcmf_c_preinit_dcmds() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01530
Уязвимость функции mt7601u_rx_next_seg_len() модуля drivers/net/wireless/mediatek/mt7601u/dma.c драйвера адаптеров беспроводной связи Mediatek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02175
Уязвимость функции brcmf_c_preinit_dcmds() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02260
Уязвимость функции pick_file() в модуле fs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02274
Уязвимость функции dm_resume() в модуле drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02370
Уязвимость функции alpine_msix_init_domains() модуля drivers/irqchip/irq-alpine-msi.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02438
Уязвимость функции tcindex_set_parms() модуля net/sched/cls_tcindex.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02443
Уязвимость функции io_init() модуля drivers/mtd/ubi/build.c драйвера памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02517
Уязвимость функции seqiv_aead_encrypt_complete2() модуля crypto/seqiv.c криптографической подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02518
Уязвимость функции ath9k_hif_usb_rx_stream() модуля drivers/net/wireless/ath/ath9k/hif_usb.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, вызвать отказ в обслуживании
BDU:2026-03311
Уязвимость функции udf_file_write_iter() модуля fs/udf/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03323
Уязвимость функции do_rbd_add() модуля drivers/block/rbd.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03331
Уязвимость функции mtk_drm_bind() модуля drivers/gpu/drm/mediatek/mtk_drm_drv.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Mediatek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03341
Уязвимость функции allocate_mr_list() модуля fs/cifs/smbdirect.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03349
Уязвимость функции il4965_setup_deferred_work() модуля drivers/net/wireless/intel/iwlegacy/4965-mac.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03645
Уязвимость функции brcmf_netdev_start_xmit() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03646
Уязвимость функции ov2740_init_controls() модуля drivers/media/i2c/ov2740.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03739
Уязвимость функции lookup_rec() модуля kernel/trace/ftrace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03768
Уязвимость функции lbs_init_adapter() модуля drivers/net/wireless/marvell/libertas/main.c драйвера адаптеров беспроводной связи Marvell ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03805
Уязвимость функции __smc_lgr_terminate() модуля net/smc/smc_core.c реализации семейства протоколов сокетов SMC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03836
Уязвимость функции alloc_wbufs() модуля fs/ubifs/super.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03853
Уязвимость функции drm_gem_shmem_mmap() модуля drivers/gpu/drm/drm_gem_shmem_helper.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03855
Уязвимость функции do_feature_check_call() модуля drivers/firmware/xilinx/zynqmp.c драйвера прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03856
Уязвимость функции ndlc_remove() модуля drivers/nfc/st-nci/ndlc.c драйвера NFC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03857
Уязвимость функции __nvmet_req_complete() модуля drivers/nvme/target/core.c драйвера NVME ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03858
Уязвимость функции smsc75xx_rx_fixup() модуля drivers/net/usb/smsc75xx.c драйвера сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03859
Уязвимость функции cfusbl_device_notify() модуля net/caif/caif_usb.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03898
Уязвимость функции icc_node_destroy() модуля drivers/interconnect/core.c драйвера межсоединений ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03952
Уязвимость функции ubi_resize_volume() модуля drivers/mtd/ubi/vmt.c драйвера памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03956
Уязвимость функции mdp5_crtc_reset() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03957
Уязвимость функции watchdog_cdev_register() модуля drivers/watchdog/watchdog_dev.c поддержки сторожевого таймера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03958
Уязвимость функции fdp_nci_i2c_read_device_properties() модуля drivers/nfc/fdp/i2c.c драйвера NFC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03959
Уязвимость функции walk_stackframe() модуля arch/riscv/kernel/stacktrace.c подсистемы управления модулями платформы с архитектурой RISCV ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03960
Уязвимость функции svc_stop_kthreads() модуля net/sunrpc/svc.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04048
Уязвимость функции ov772x_probe() модуля drivers/media/i2c/ov772x.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04332
Уязвимость функции platform_irqchip_probe() модуля drivers/irqchip/irqchip.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04334
Уязвимость функции dc_construct_ctx() модуля drivers/gpu/drm/amd/display/dc/core/dc.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04339
Уязвимость функции mtk_drm_crtc_create() модуля drivers/gpu/drm/mediatek/mtk_drm_crtc.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04517
Уязвимость функции dasd_eckd_init() модуля drivers/s390/block/dasd_eckd.c драйвера блочных устройств на платформе S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04588
Уязвимость функции __ocfs2_move_extent() модуля fs/ocfs2/move_extents.c файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04606
Уязвимость функции fei_debugfs_add_attr() модуля kernel/fail_function.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04619
Уязвимость функции msm_dsi_host_init() модуля drivers/gpu/drm/msm/dsi/dsi_host.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04626
Уязвимость функции swap_inode_boot_loader() модуля fs/ext4/ioctl.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04627
Уязвимость функции ext4_expand_extra_isize_ea() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04628
Уязвимость функции gpio_ir_recv_remove() модуля drivers/media/rc/gpio-ir-recv.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04629
Уязвимость функции ext4_xattr_inode_iget() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04871
Уязвимость функции ila_xlat_nl_cmd_get_mapping() модуля net/ipv6/ila/ila_xlat.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05738
Уязвимость функции cfg80211_sme_connect() модуля net/wireless/sme.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05793
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05852
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05873
Уязвимость функции in_atomic() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05899
Уязвимость функции debugfs_lookup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05976
Уязвимость функции vkms_release() модуля drivers/gpu/drm/vkms/vkms_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05987
Уязвимость функции ti_sci_intr_irq_domain_probe() модуля drivers/irqchip/irq-ti-sci-intr.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06003
Уязвимость функции hi3660_thermal_probe() модуля drivers/thermal/hisi_thermal.c драйвера управления температурой ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06022
Уязвимость функции ubi_wl_put_peb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06074
Уязвимость функции _rtl8812ae_phy_set_txpower_limit() в модуле drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06102
Уязвимость функции rt6_nlmsg_size() в модуле net/ipv6/route.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-13
CVE-2022-50021
In the Linux kernel, the following vulnerability has been resolved:
ext4: block range must be validated before use in ext4_mb_clear_bb()
Block range to free is validated in ext4_free_blocks() using
ext4_inode_block_valid() and then it's passed to ext4_mb_clear_bb().
However in some situations on bigalloc file system the range might be
adjusted after the validation in ext4_free_blocks() which can lead to
troubles on corrupted file systems such as one found by syzkaller that
resulted in the following BUG
kernel BUG at fs/ext4/ext4.h:3319!
PREEMPT SMP NOPTI
CPU: 28 PID: 4243 Comm: repro Kdump: loaded Not tainted 5.19.0-rc6+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
RIP: 0010:ext4_free_blocks+0x95e/0xa90
Call Trace:
Modified: 2025-11-19
CVE-2022-50226
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak For some sev ioctl interfaces, input may be passed that is less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the buffer, the sev ioctl interfaces with the issue may return uninitialized slab memory. Currently, all of the ioctl interfaces in the ccp driver are safe, but to prevent future problems, change all ioctl interfaces that allocate memory with kmalloc to use kzalloc and memset the data buffer to zero in sev_ioctl_do_platform_status.
- https://git.kernel.org/stable/c/13dc15a3f5fd7f884e4bfa8c011a0ae868df12ae
- https://git.kernel.org/stable/c/4c5300f6f5e18b11c02a92f136e69b98fddba15e
- https://git.kernel.org/stable/c/caa395aa16e7c9193fd7fa6cde462dd8229d4953
- https://git.kernel.org/stable/c/e11fb0a3a39bb42da35fa662c46ce7391f277436
- https://git.kernel.org/stable/c/f2a920daa780956b987c14b9f23de7c3c8915bf2
Modified: 2025-11-25
CVE-2022-50258
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds() This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated. Found by a modified version of syzkaller. [ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][ T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [ 47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.633002][ ---truncated---
- https://git.kernel.org/stable/c/0a06cadcc2a0044e4a117cc0e61436fc3a0dad69
- https://git.kernel.org/stable/c/17dbe90e13f52848c460d253f15b765038ec6dc0
- https://git.kernel.org/stable/c/3a3a5e3f94068cd562d62a57da6983c8cd07d53c
- https://git.kernel.org/stable/c/881f50d76c3892262730ddf5c894eb00310e736c
- https://git.kernel.org/stable/c/89243a7b0ea19606ba1c2873c9d569026ccb344f
- https://git.kernel.org/stable/c/ba166e0ebdde3dfa833f0a3edaf2b2934d4a87f7
- https://git.kernel.org/stable/c/d481fd6064bf215d7c5068e15aa390c3b16c9cd0
- https://git.kernel.org/stable/c/d6ef66194bb4a6c18f5b9649bf62597909b040e4
Modified: 2025-12-03
CVE-2022-50279
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()
There is a global-out-of-bounds reported by KASAN:
BUG: KASAN: global-out-of-bounds in
_rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411
CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D
6.1.0-rc8+ #144 e15588508517267d37
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
Call Trace:
- https://git.kernel.org/stable/c/057b52461dc005ecd85a3e4998913b1492ec0f72
- https://git.kernel.org/stable/c/0c962dcd6bf64b78eaffc09e497a2beb4e48bc32
- https://git.kernel.org/stable/c/117dbeda22ec5ea0918254d03b540ef8b8a64d53
- https://git.kernel.org/stable/c/1e950b9a841bc96e98ee25680d5c7aa305120be1
- https://git.kernel.org/stable/c/28ea268d95e57cdf6394a058f0d854206d478772
- https://git.kernel.org/stable/c/f1fe40120de6ad4ffa8299fde035a5feba10d4fb
- https://git.kernel.org/stable/c/fc3442247716fc426bbcf62ed65e086e48a6d44f
Modified: 2025-12-03
CVE-2022-50294
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in lbs_init_adapter() When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not released. Add free memory to processing error path.
- https://git.kernel.org/stable/c/037f84c0bfae5c436c651d0e804264e2648010ec
- https://git.kernel.org/stable/c/16a03958618fb91bb1bc7077cf3211055162cc2f
- https://git.kernel.org/stable/c/23b34e08de5c2380414c9d3c33e8235094bcccae
- https://git.kernel.org/stable/c/4c102ad59bfa66c0f6662af64fa3b9007b02c20f
- https://git.kernel.org/stable/c/653d13a73e498d0bb6aeaf689aaa960defa7878b
- https://git.kernel.org/stable/c/98e0ff6980c89239d9e5d3da90d791c2383dc23a
- https://git.kernel.org/stable/c/9c8f50c7433bdfba1588831c413136ecc3f29f99
- https://git.kernel.org/stable/c/d46c33f667b05c22bc5c5b69aa730349c4b6fe31
Modified: 2025-12-03
CVE-2022-50321
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit() The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it. Compile tested only.
- https://git.kernel.org/stable/c/212fde3fe76e962598ce1d47b97cc78afdfc71b3
- https://git.kernel.org/stable/c/3a4d18318f473e97d628f410215b3fac32d07aed
- https://git.kernel.org/stable/c/4c55fdebc1c358de96bfab52ed309d58a3ba66ef
- https://git.kernel.org/stable/c/7f159116d620615779adbf88a5d94713702216d8
- https://git.kernel.org/stable/c/d869a189505224601e310c7769cb90b0e2f60b31
- https://git.kernel.org/stable/c/e08e6812efb6a8c676e733de0518594d1517e0d9
- https://git.kernel.org/stable/c/e5d01e85cf46628647cd696cb72ba4659b18967f
- https://git.kernel.org/stable/c/e8ef89e5b89ee041a94eecfb6c31fcc237f9168c
Modified: 2026-01-14
CVE-2022-50369
In the Linux kernel, the following vulnerability has been resolved:
drm/vkms: Fix null-ptr-deref in vkms_release()
A null-ptr-deref is triggered when it tries to destroy the workqueue in
vkms->output.composer_workq in vkms_release().
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24
RIP: 0010:destroy_workqueue+0x2f/0x710
...
Call Trace:
- https://git.kernel.org/stable/c/0b8f390e2251191f1b179cc87f65d54c96565f0d
- https://git.kernel.org/stable/c/1f9836f95271e7acf016667eee0aeae3386f9645
- https://git.kernel.org/stable/c/2fe2a8f40c21161ffe7653cc234e7934db5b7cc5
- https://git.kernel.org/stable/c/57031c474c3a920ea73afeb5dc352e537f5793ee
- https://git.kernel.org/stable/c/596f1ba3987e601e31a5abf1f75ce1d2635aceac
Modified: 2026-01-14
CVE-2022-50396
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_set_parms
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810c287f00 (size 256):
comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b
- https://git.kernel.org/stable/c/18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6
- https://git.kernel.org/stable/c/372ae77cf11d11fb118cbe2d37def9dd5f826abd
- https://git.kernel.org/stable/c/399ab7fe0fa0d846881685fd4e57e9a8ef7559f7
- https://git.kernel.org/stable/c/3abebc503a5148072052c229c6b04b329a420ecd
- https://git.kernel.org/stable/c/53af9c793f644d5841d84d8e0ad83bd7ab47f3e0
- https://git.kernel.org/stable/c/55ac68b53f1cea1926ee2313afc5d66b91daad71
- https://git.kernel.org/stable/c/6c55953e232ea668731091d111066521f3b7719b
- https://git.kernel.org/stable/c/7a6fb69bbcb21e9ce13bdf18c008c268874f0480
- https://git.kernel.org/stable/c/7c183dc0af472dec33d2c0786a5e356baa8cad19
- https://git.kernel.org/stable/c/b314f6c3512108d7a656c5caf07c82d1bbbdc0f1
- https://git.kernel.org/stable/c/c4de6057e7c6654983acb63d939d26ac0d7bbf39
- https://git.kernel.org/stable/c/facc4405e8b7407e03216207b1d1d640127de0c8
Modified: 2026-03-25
CVE-2022-50488
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10: ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | Λ | Λ | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | Λ | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) Λ |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic.
- https://git.kernel.org/stable/c/094f3d9314d67691cb21ba091c1b528f6e3c4893
- https://git.kernel.org/stable/c/5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a
- https://git.kernel.org/stable/c/64dc8c732f5c2b406cc752e6aaa1bd5471159cab
- https://git.kernel.org/stable/c/761564d93c8265f65543acf0a576b32d66bfa26a
- https://git.kernel.org/stable/c/b22fd72bfebda3956efc4431b60ddfc0a51e03e0
Modified: 2026-03-17
CVE-2022-50535
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential null-deref in dm_resume [Why] Fixing smatch error: dm_resume() error: we previously assumed 'aconnector->dc_link' could be null [How] Check if dc_link null at the beginning of the loop, so further checks can be dropped.
- https://git.kernel.org/stable/c/00b655fa96b4e941351cc4bf5ca755a65ae94a8e
- https://git.kernel.org/stable/c/7a7175a2cd84b7874bebbf8e59f134557a34161b
- https://git.kernel.org/stable/c/8e365f1bd672cc9320a936f6ae6f8087aa40e9bc
- https://git.kernel.org/stable/c/9f73793b81637c60ccc83cc508645310b8ab7d80
- https://git.kernel.org/stable/c/bb9a5562beb982aa5ebb73c521c49596ff8b8030
- https://git.kernel.org/stable/c/d236103782de25736996a45bd36ac2a89bdc93c6
- https://git.kernel.org/stable/c/fd79b61af2782f8875c78f50cdb8630ec43e2990
Modified: 2024-11-21
CVE-2023-1077
In the Linux kernel, pick_next_rt_entity() may return a type confused entry, not detected by the BUG_ON condition, as the confused entry will not be NULL, but list_head.The buggy error condition would lead to a type confused entry with the list head,which would then be used as a type confused sched_rt_entity,causing memory corruption.
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230511-0002/
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230511-0002/
Modified: 2025-04-23
CVE-2023-1118
A flaw use after free in the Linux kernel integrated infrared receiver/transceiver driver was found in the way user detaching rc device. A local user could use this flaw to crash the system or potentially escalate their privileges on the system.
- https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230413-0003/
- https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230413-0003/
Modified: 2025-02-13
CVE-2023-1829
A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation. The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure. A local attacker user can use this vulnerability to elevate its privileges to root. We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230601-0001/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230601-0001/
Modified: 2025-11-12
CVE-2023-53075
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix invalid address access in lookup_rec() when index is 0 KASAN reported follow problem: BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly added to ftrace_pages_start in ftrace_process_locs(). Before the first pg->index++, index is 0 and accessing pg->records[-1].ip will cause this problem. Don't check the ip when pg->index is 0.
- https://git.kernel.org/stable/c/2a0d71fabfeb349216d33f001a6421b1768bd3a9
- https://git.kernel.org/stable/c/2de28e5ce34b22b73b833a21e2c45ae3aade3964
- https://git.kernel.org/stable/c/4f84f31f63416b0f02fc146ffdc4ab32723eb7e8
- https://git.kernel.org/stable/c/7569ee04b0e3b32df79f64db3a7138573edad9bc
- https://git.kernel.org/stable/c/83c3b2f4e7c61367c7b24551f4c6eb94bbdda283
- https://git.kernel.org/stable/c/ac58b88ccbbb8e9fb83e137cee04a856b1ea6635
- https://git.kernel.org/stable/c/ee92fa443358f4fc0017c1d0d325c27b37802504
- https://git.kernel.org/stable/c/f1bd8b7fd890d87d0dc4dedc6287ea34dd07c0b4
Modified: 2025-11-12
CVE-2023-53077
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes [WHY] When PTEBufferSizeInRequests is zero, UBSAN reports the following warning because dml_log2 returns an unexpected negative value: shift exponent 4294966273 is too large for 32-bit type 'int' [HOW] In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and assign the result directly.
- https://git.kernel.org/stable/c/031f196d1b1b6d5dfcb0533b431e3ab1750e6189
- https://git.kernel.org/stable/c/7257070be70e19a9138f39009c1a26c83a8a7cfa
- https://git.kernel.org/stable/c/a16394b5d661afec9a264fecac3abd87aea439ea
- https://git.kernel.org/stable/c/bec1bea2fa974e63f6059c33edde669c7894d0bc
- https://git.kernel.org/stable/c/e12b95680821b9880cd9992c0f3555389363604f
Modified: 2025-11-12
CVE-2023-53084
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove another errant put in error path drm_gem_shmem_mmap() doesn't own reference in error code path, resulting in the dma-buf shmem GEM object getting prematurely freed leading to a later use-after-free.
- https://git.kernel.org/stable/c/5cfb617967b05f8f27e862c97db1fabd8485f4db
- https://git.kernel.org/stable/c/684c7372bbd6447c2e86a2a84e97a1478604d21f
- https://git.kernel.org/stable/c/77d26c824aa5a7e0681ef1d5b75fe538d746addc
- https://git.kernel.org/stable/c/dede8c14a37a7ac458f9add56154a074ed78e7cf
- https://git.kernel.org/stable/c/ee9adb7a45516cfa536ca92253d7ae59d56db9e4
Modified: 2025-11-12
CVE-2023-53087
In the Linux kernel, the following vulnerability has been resolved: drm/i915/active: Fix misuse of non-idle barriers as fence trackers Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed at an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel context and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. When adding a request to a composite tracker, we try to reuse an existing fence tracker, already allocated and registered with that composite. The tracker we obtain may already track another fence, may be an idle barrier, or an active barrier. If the tracker we get occurs a non-idle barrier then we try to delete that barrier from a list of barrier tasks it belongs to. However, while doing that we don't respect return value from a function that performs the barrier deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since the same structure field is reused with both fence callback lists and barrier tasks list, list corruptions would likely occur. Barriers are now deleted from a barrier tasks list by temporarily removing the list content, traversing that content with skip over the node to be deleted, then populating the list back with the modified content. Should that intentionally racy concurrent deletion attempts be not serialized, one or more of those may fail because of the list being temporary empty. Related code that ignores the results of barrier deletion was initially introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"). However, all users of the barrier deletion routine were apparently serialized at that time, then the issue didn't exhibit itself. Results of git bisect with help of a newly developed igt@gem_barrier_race@remote-request IGT test indicate that list corruptions might start to appear after commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), introduced in v5.5. Respect results of barrier deletion attempts -- mark the barrier as idle only if successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails then don't use that tracker but go back and try to acquire a new, usable one. v3: use unlikely() to document what outcome we expect (Andi), - fix bad grammar in commit description. v2: no code changes, - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"), v5.4, - reword commit description. (cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7)
- https://git.kernel.org/stable/c/5c7591b8574c52c56b3994c2fbef1a3a311b5715
- https://git.kernel.org/stable/c/5e784a7d07af42057c0576fb647b482f4cb0dc2c
- https://git.kernel.org/stable/c/6ab7d33617559cced63d467928f478ea5c459021
- https://git.kernel.org/stable/c/9159db27fb19bbf1c91b5c9d5285e66cc96cc5ff
- https://git.kernel.org/stable/c/e0e6b416b25ee14716f3549e0cbec1011b193809
Modified: 2025-11-12
CVE-2023-53089
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix task hung in ext4_xattr_delete_inode
Syzbot reported a hung task problem:
==================================================================
INFO: task syz-executor232:5073 blocked for more than 143 seconds.
Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004
Call Trace:
- https://git.kernel.org/stable/c/0f7bfd6f8164be32dbbdf36aa1e5d00485c53cd7
- https://git.kernel.org/stable/c/1aec41c98cce61d19ce89650895e51b9f3cdef13
- https://git.kernel.org/stable/c/2c96c52aeaa6fd9163cfacdd98778b4a0398ef18
- https://git.kernel.org/stable/c/64b72f5e7574020dea62ab733d88a54d903c42a1
- https://git.kernel.org/stable/c/73f7987fe1b82596f1a380e85cd0097ebaae7e01
- https://git.kernel.org/stable/c/94fd091576b12540924f6316ebc0678e84cb2800
- https://git.kernel.org/stable/c/a98160d8f3e6242ca9b7f443f26e7ef3a61ba684
- https://git.kernel.org/stable/c/efddc7e106fdf8d1f62d45e79de78f63b7c04fba
Modified: 2025-11-12
CVE-2023-53090
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix an illegal memory access In the kfd_wait_on_events() function, the kfd_event_waiter structure is allocated by alloc_event_waiters(), but the event field of the waiter structure is not initialized; When copy_from_user() fails in the kfd_wait_on_events() function, it will enter exception handling to release the previously allocated memory of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function, this results in illegal memory access and system crash, here is the crash log: localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 localhost kernel: Call Trace: localhost kernel: _raw_spin_lock_irqsave+0x30/0x40 localhost kernel: remove_wait_queue+0x12/0x50 localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu] localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: __x64_sys_ioctl+0x8e/0xd0 localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0 localhost kernel: do_syscall_64+0x33/0x80 localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 localhost kernel: RIP: 0033:0x152a4dff68d7 Allocate the structure with kcalloc, and remove redundant 0-initialization and a redundant loop condition check.
- https://git.kernel.org/stable/c/2fece63b55c5d74cd6f5de51159e2cde37e10555
- https://git.kernel.org/stable/c/4fc8fff378b2f2039f2a666d9f8c570f4e58352c
- https://git.kernel.org/stable/c/5a3fb3b745af0ce46ec2e0c8e507bae45b937334
- https://git.kernel.org/stable/c/61f306f8df0d5559659c5578cf6d95236bcdcb25
- https://git.kernel.org/stable/c/6936525142a015e854d0a23e9ad9ea0a28b3843d
- https://git.kernel.org/stable/c/bbf5eada4334a96e3a204b2307ff5b14dc380b0b
- https://git.kernel.org/stable/c/d9923e7214a870b312bf61f6a89c7554d0966985
Modified: 2025-11-12
CVE-2023-53096
In the Linux kernel, the following vulnerability has been resolved: interconnect: fix mem leak when freeing nodes The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed.
- https://git.kernel.org/stable/c/2e0b13a1827229a02abef97b50ffaf89ba25370a
- https://git.kernel.org/stable/c/3167306455d0fbbbcf08cb25651acc527a86a95e
- https://git.kernel.org/stable/c/a5904f415e1af72fa8fe6665aa4f554dc2099a95
- https://git.kernel.org/stable/c/c1722e4113281fb34e5b4fb5c5387b17cd39a537
- https://git.kernel.org/stable/c/efae80ca13faa94457208852825731da44a788ad
- https://git.kernel.org/stable/c/f1e3a20c60196c37a402c584d0c9de306ba988ce
Modified: 2025-11-12
CVE-2023-53098
In the Linux kernel, the following vulnerability has been resolved: media: rc: gpio-ir-recv: add remove function In case runtime PM is enabled, do runtime PM clean up to remove cpu latency qos request, otherwise driver removal may have below kernel dump: [ 19.463299] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048 [ 19.472161] Mem abort info: [ 19.474985] ESR = 0x0000000096000004 [ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.484081] SET = 0, FnV = 0 [ 19.487149] EA = 0, S1PTW = 0 [ 19.490361] FSC = 0x04: level 0 translation fault [ 19.495256] Data abort info: [ 19.498149] ISV = 0, ISS = 0x00000004 [ 19.501997] CM = 0, WnR = 0 [ 19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000 [ 19.511432] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000 [ 19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last unloaded: rc_core] [ 19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted 6.2.0-rc1-00028-g2c397a46d47c #72 [ 19.531854] Hardware name: FSL i.MX8MM EVK board (DT) [ 19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110 [ 19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.557294] sp : ffff800008ce3740 [ 19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27: ffff800008ce3d50 [ 19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24: ffffc7e3f9ef0e30 [ 19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21: 0000000000000008 [ 19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18: ffffffffffffffff [ 19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15: ffffffffffffffff [ 19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12: 0000000000000001 [ 19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 : 0000000000000008 [ 19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 000000000f0bfe9f [ 19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 : ffff006180382010 [ 19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 : 0000000000000020 [ 19.638548] Call trace: [ 19.640995] cpu_latency_qos_remove_request+0x20/0x110 [ 19.646142] gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.652339] pm_generic_runtime_suspend+0x2c/0x44 [ 19.657055] __rpm_callback+0x48/0x1dc [ 19.660807] rpm_callback+0x6c/0x80 [ 19.664301] rpm_suspend+0x10c/0x640 [ 19.667880] rpm_idle+0x250/0x2d0 [ 19.671198] update_autosuspend+0x38/0xe0 [ 19.675213] pm_runtime_set_autosuspend_delay+0x40/0x60 [ 19.680442] gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv] [ 19.685941] platform_probe+0x68/0xc0 [ 19.689610] really_probe+0xc0/0x3dc [ 19.693189] __driver_probe_device+0x7c/0x190 [ 19.697550] driver_probe_device+0x3c/0x110 [ 19.701739] __driver_attach+0xf4/0x200 [ 19.705578] bus_for_each_dev+0x70/0xd0 [ 19.709417] driver_attach+0x24/0x30 [ 19.712998] bus_add_driver+0x17c/0x240 [ 19.716834] driver_register+0x78/0x130 [ 19.720676] __platform_driver_register+0x28/0x34 [ 19.725386] gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv] [ 19.731404] do_one_initcall+0x44/0x2ac [ 19.735243] do_init_module+0x48/0x1d0 [ 19.739003] load_module+0x19fc/0x2034 [ 19.742759] __do_sys_finit_module+0xac/0x12c [ 19.747124] __arm64_sys_finit_module+0x20/0x30 [ 19.751664] invoke_syscall+0x48/0x114 [ 19.755420] el0_svc_common.constprop.0+0xcc/0xec [ 19.760132] do_el0_svc+0x38/0xb0 [ 19.763456] el0_svc+0x2c/0x84 [ 19.766516] el0t_64_sync_handler+0xf4/0x120 [ 19.770789] el0t_64_sync+0x190/0x194 [ 19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400) [ 19.780556] ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/00e81f191bc00cb6faabf468960e96ebf0404a6c
- https://git.kernel.org/stable/c/2ece4d2f7eac1cb51dc0e9859e09bfdb00faa28e
- https://git.kernel.org/stable/c/30040818b338b8ebc956ce0ebd198f8d593586a6
- https://git.kernel.org/stable/c/513572bb89e8075f5d2a2bb4c89f1152e44da9d8
- https://git.kernel.org/stable/c/a5c140d88a69eb43de2a030f1d7ff7b16bff3b1a
Modified: 2025-11-10
CVE-2023-53099
In the Linux kernel, the following vulnerability has been resolved:
firmware: xilinx: don't make a sleepable memory allocation from an atomic context
The following issue was discovered using lockdep:
[ 6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209
[ 6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0
[ 6.702431] 2 locks held by swapper/0/1:
[ 6.706300] #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4c/0x90
[ 6.714900] #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, at: clk_enable_lock+0x4c/0x140
[ 6.723156] irq event stamp: 304030
[ 6.726596] hardirqs last enabled at (304029): [
- https://git.kernel.org/stable/c/162049c31eb64308afa22e341a257a723526eb5c
- https://git.kernel.org/stable/c/38ed310c22e7a0fc978b1f8292136a4a4a8b3051
- https://git.kernel.org/stable/c/86afb633beaa02ee95b5126a14c9f22cfade4fd9
- https://git.kernel.org/stable/c/9bbab2843f2d1337a268499a1c02b435d2985a17
- https://git.kernel.org/stable/c/b37d3ccbd549494890672136a0e623eb010d46a7
Modified: 2025-11-10
CVE-2023-53100
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in ext4_update_inline_data
Syzbot found the following issue:
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
Modules linked in:
CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/2b96b4a5d9443ca4cad58b0040be455803c05a42
- https://git.kernel.org/stable/c/35161cec76772f74526f5886ad4082ec48511d5c
- https://git.kernel.org/stable/c/39c5df2ca544368b44b59d0f6d80131e90763371
- https://git.kernel.org/stable/c/74d775083e9f3d9dadf9e3b5f3e0028d1ad0bd5c
- https://git.kernel.org/stable/c/92eee6a82a9a6f9f83559e17a2b6b935e1a5cd25
- https://git.kernel.org/stable/c/a9bd94f67b27739bbe8583c52256502bd4cc7e83
- https://git.kernel.org/stable/c/c5aa102b433b1890e1ccaa40c06826c77dda1665
- https://git.kernel.org/stable/c/ca500cf2eceb5a8e93bf71ab97b5f7a18ecabce2
Modified: 2025-11-10
CVE-2023-53101
In the Linux kernel, the following vulnerability has been resolved: ext4: zero i_disksize when initializing the bootloader inode If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024); Fix this by setting i_disksize as well as i_size to zero when initiaizing the boot loader inode.
- https://git.kernel.org/stable/c/01a821aacc64d4b05dafd239dbc9b7856686002f
- https://git.kernel.org/stable/c/0d8a6c9a6415999fee1259ccf1796480c026b7d6
- https://git.kernel.org/stable/c/3f00c476da8fe7c4c34ea16abb55d74127120413
- https://git.kernel.org/stable/c/59eee0cdf8c036f554add97a4da7c06d7a9ff34a
- https://git.kernel.org/stable/c/9cb27b1e76f0cc886ac09055bc41c0ab3f205167
- https://git.kernel.org/stable/c/9e9a4cc5486356158554f6ad73027d8635a48b34
- https://git.kernel.org/stable/c/d6c1447e483c05dbcfb3ff77ac04237a82070b8c
- https://git.kernel.org/stable/c/f5361da1e60d54ec81346aee8e3d8baf1be0b762
Modified: 2025-11-10
CVE-2023-53102
In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: disable txq irq before flushing hw
ice_qp_dis() intends to stop a given queue pair that is a target of xsk
pool attach/detach. One of the steps is to disable interrupts on these
queues. It currently is broken in a way that txq irq is turned off
*after* HW flush which in turn takes no effect.
ice_qp_dis():
-> ice_qvec_dis_irq()
--> disable rxq irq
--> flush hw
-> ice_vsi_stop_tx_ring()
-->disable txq irq
Below splat can be triggered by following steps:
- start xdpsock WITHOUT loading xdp prog
- run xdp_rxq_info with XDP_TX action on this interface
- start traffic
- terminate xdpsock
[ 256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018
[ 256.319560] #PF: supervisor read access in kernel mode
[ 256.324775] #PF: error_code(0x0000) - not-present page
[ 256.329994] PGD 0 P4D 0
[ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G OE 6.2.0-rc5+ #51
[ 256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice]
[ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44
[ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206
[ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f
[ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80
[ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000
[ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000
[ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600
[ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000
[ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0
[ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 256.457770] PKRU: 55555554
[ 256.460529] Call Trace:
[ 256.463015]
- https://git.kernel.org/stable/c/243cde8de10894d7812c8a6b62653bf04d8f9700
- https://git.kernel.org/stable/c/2ecc6e44959382f95c9d427cd8da85121a9cecda
- https://git.kernel.org/stable/c/b830c9642386867863ac64295185f896ff2928ac
- https://git.kernel.org/stable/c/b89a453c6918e0f346fb0562e8c7812b94d28c73
- https://git.kernel.org/stable/c/cccba1ff0798a27f7b8d0c06762ef977400a2afb
Modified: 2025-11-10
CVE-2023-53106
In the Linux kernel, the following vulnerability has been resolved: nfc: st-nci: Fix use after free bug in ndlc_remove due to race condition This bug influences both st_nci_i2c_remove and st_nci_spi_remove. Take st_nci_i2c_remove as an example. In st_nci_i2c_probe, it called ndlc_probe and bound &ndlc->sm_work with llt_ndlc_sm_work. When it calls ndlc_recv or timeout handler, it will finally call schedule_work to start the work. When we call st_nci_i2c_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in ndlc_remove CPU0 CPU1 |llt_ndlc_sm_work st_nci_i2c_remove | ndlc_remove | st_nci_remove | nci_free_device| kfree(ndev) | //free ndlc->ndev | |llt_ndlc_rcv_queue |nci_recv_frame |//use ndlc->ndev
- https://git.kernel.org/stable/c/2156490c4b7cacda9a18ec99929940b8376dc0e3
- https://git.kernel.org/stable/c/3405eb641dafcc8b28d174784b203c1622c121bf
- https://git.kernel.org/stable/c/43aa468df246175207a7d5d7d6d31b231f15b49c
- https://git.kernel.org/stable/c/5000fe6c27827a61d8250a7e4a1d26c3298ef4f6
- https://git.kernel.org/stable/c/5e331022b448fbc5e76f24349cd0246844dcad25
- https://git.kernel.org/stable/c/84dd9cc34014e3a3dcce0eb6d54b8a067e97676b
- https://git.kernel.org/stable/c/b0c202a8dc63008205a5d546559736507a9aae66
- https://git.kernel.org/stable/c/f589e5b56c562d99ea74e05b1c3f0eab78aa17a3
Modified: 2025-11-10
CVE-2023-53108
In the Linux kernel, the following vulnerability has been resolved: net/iucv: Fix size of interrupt data iucv_irq_data needs to be 4 bytes larger. These bytes are not used by the iucv module, but written by the z/VM hypervisor in case a CPU is deconfigured. Reported as: BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten ----------------------------------------------------------------------------- 0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1 __kmem_cache_alloc_node+0x166/0x450 kmalloc_node_trace+0x3a/0x70 iucv_cpu_prepare+0x44/0xd0 cpuhp_invoke_callback+0x156/0x2f0 cpuhp_issue_call+0xf0/0x298 __cpuhp_setup_state_cpuslocked+0x136/0x338 __cpuhp_setup_state+0xf4/0x288 iucv_init+0xf4/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1 __kmem_cache_free+0x308/0x358 iucv_init+0x92/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0| Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000 Redzone 0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2 ................ Object 0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc ................ Object 0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400580: cc cc cc cc cc cc cc cc ........ Padding 00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<000000032aa034ec>] dump_stack_lvl+0xac/0x100 [<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140 [<0000000329f5aa78>] check_object+0x370/0x3c0 [<0000000329f5ede6>] free_debug_processing+0x15e/0x348 [<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0 [<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8 [<0000000329f61768>] __kmem_cache_free+0x308/0x358 [<000000032a91465c>] iucv_cpu_dead+0x6c/0x88 [<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0 [<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0 [<0000000329c3243e>] cpu_device_down+0x4e/0x78 [<000000032a61dee0>] device_offline+0xc8/0x118 [<000000032a61e048>] online_store+0x60/0xe0 [<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8 [<0000000329fab65c>] vfs_write+0x174/0x360 [<0000000329fab9fc>] ksys_write+0x74/0x100 [<000000032aa03a5a>] __do_syscall+0x1da/0x208 [<000000032aa177b2>] system_call+0x82/0xb0 INFO: lockdep is turned off. FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc FIX dma-kmalloc-64: Object at 0x0000000000400540 not freed
- https://git.kernel.org/stable/c/3cfdefdaaa4b2a77e84d0db5e0a47a7aa3bb615a
- https://git.kernel.org/stable/c/3d87debb8ed2649608ff432699e7c961c0c6f03b
- https://git.kernel.org/stable/c/71da5991b6438ad6da13ceb25465ee2760a1c52f
- https://git.kernel.org/stable/c/93a970494881004c348d8feb38463ee72496e99a
- https://git.kernel.org/stable/c/a908eae0f71811afee86be7088692f1aa5855c3b
- https://git.kernel.org/stable/c/b0d2bb5e31a693ebc8888eb407f8a257a3680efa
- https://git.kernel.org/stable/c/bd2e78462ae18484e55ae4d285df2c86b86bdd12
- https://git.kernel.org/stable/c/c78f1345db4e4b3b78f9b768f4074ebd60abe966
Modified: 2025-11-10
CVE-2023-53109
In the Linux kernel, the following vulnerability has been resolved: net: tunnels: annotate lockless accesses to dev->needed_headroom IP tunnels can apparently update dev->needed_headroom in their xmit path. This patch takes care of three tunnels xmit, and also the core LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA() helpers. More changes might be needed for completeness. BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmit read to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1: ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/i ---truncated---
- https://git.kernel.org/stable/c/4b397c06cb987935b1b097336532aa6b4210e091
- https://git.kernel.org/stable/c/51f3bd3765bc5ca4583af07a00833da00d2ace1d
- https://git.kernel.org/stable/c/5aaab217c8f5387b9c5fff9e940d80f135e04366
- https://git.kernel.org/stable/c/8e206f66d824b3b28a7f9ee1366dfc79a937bb46
- https://git.kernel.org/stable/c/9b86a8702b042ee4e15d2d46375be873a6a8834f
- https://git.kernel.org/stable/c/a69b72b57b7d269e833e520ba7500d556e8189b6
- https://git.kernel.org/stable/c/be59b87ee4aed81db7c10e44f603866a0ac3ca5d
- https://git.kernel.org/stable/c/e0a557fc1daf5c1086e47150a4571aebadbb62be
Modified: 2025-11-10
CVE-2023-53110
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler() When performing a stress test on SMC-R by rmmod mlx5_ib driver during the wrk/nginx test, we found that there is a probability of triggering a panic while terminating all link groups. This issue dues to the race between smc_smcr_terminate_all() and smc_buf_create(). smc_smcr_terminate_all smc_buf_create /* init */ conn->sndbuf_desc = NULL; ... __smc_lgr_terminate smc_conn_kill smc_close_abort smc_cdc_get_slot_and_msg_send __softirqentry_text_start smc_wr_tx_process_cqe smc_cdc_tx_handler READ(conn->sndbuf_desc->len); /* panic dues to NULL sndbuf_desc */ conn->sndbuf_desc = xxx; This patch tries to fix the issue by always to check the sndbuf_desc before send any cdc msg, to make sure that no null pointer is seen during cqe processing.
- https://git.kernel.org/stable/c/22a825c541d775c1dbe7b2402786025acad6727b
- https://git.kernel.org/stable/c/31817c530768b0199771ec6019571b4f0ddbf230
- https://git.kernel.org/stable/c/3c270435db8aa34929263dddae8fd050f5216ecb
- https://git.kernel.org/stable/c/3ebac7cf0a184a8102821a7a00203f02bebda83c
- https://git.kernel.org/stable/c/b108bd9e6be000492ebebe867daa699285978a10
Modified: 2025-11-10
CVE-2023-53114
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix kernel crash during reboot when adapter is in recovery mode
If the driver detects during probe that firmware is in recovery
mode then i40e_init_recovery_mode() is called and the rest of
probe function is skipped including pci_set_drvdata(). Subsequent
i40e_shutdown() called during shutdown/reboot dereferences NULL
pointer as pci_get_drvdata() returns NULL.
To fix call pci_set_drvdata() also during entering to recovery mode.
Reproducer:
1) Lets have i40e NIC with firmware in recovery mode
2) Run reboot
Result:
[ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver
[ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.
[ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.
[ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
[ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
[ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0
[ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.
[ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
[ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
[ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0
...
[ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2
[ 156.318330] #PF: supervisor write access in kernel mode
[ 156.323546] #PF: error_code(0x0002) - not-present page
[ 156.328679] PGD 0 P4D 0
[ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1
[ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022
[ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]
[ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00
- https://git.kernel.org/stable/c/3cbecb1c9085a00155639404f7addbcbfc987ba3
- https://git.kernel.org/stable/c/4ff82695266576a0b4f1077a7100b2451e476df4
- https://git.kernel.org/stable/c/6e18f66b704bd725196508c1db93bf7338cdc8de
- https://git.kernel.org/stable/c/7e4f8a0c495413a50413e8c9f1032ce1bc633bae
- https://git.kernel.org/stable/c/b3826fb3ea14646b3d4e6309bfc384b349f36eb6
- https://git.kernel.org/stable/c/c703362a66ea971905b9dc153fc54d1b6ac05423
Modified: 2025-11-10
CVE-2023-53116
In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid potential UAF in nvmet_req_complete() An nvme target ->queue_response() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpu_ref_put() is called in nvmet_req_complete(). Avoid such problem by using a local variable to save the sq pointer before calling __nvmet_req_complete(), thus avoiding dereferencing the req pointer after that function call.
- https://git.kernel.org/stable/c/04c394208831d5e0d5cfee46722eb0f033cd4083
- https://git.kernel.org/stable/c/6173a77b7e9d3e202bdb9897b23f2a8afe7bf286
- https://git.kernel.org/stable/c/8ed9813871038b25a934b21ab76b5b7dbf44fc3a
- https://git.kernel.org/stable/c/a6317235da8aa7cb97529ebc8121cc2a4c4c437a
- https://git.kernel.org/stable/c/bcd535f07c58342302a2cd2bdd8894fe0872c8a9
- https://git.kernel.org/stable/c/e5d99b29012bbf0e86929403209723b2806500c1
- https://git.kernel.org/stable/c/f1d5888a5efe345b63c430b256e95acb0a475642
- https://git.kernel.org/stable/c/fafcb4b26393870c45462f9af6a48e581dbbcf7e
Modified: 2025-11-10
CVE-2023-53117
In the Linux kernel, the following vulnerability has been resolved: fs: prevent out-of-bounds array speculation when closing a file descriptor Google-Bug-Id: 114199369
- https://git.kernel.org/stable/c/3d5d9501b634fd268eb56428cda92cd317752d69
- https://git.kernel.org/stable/c/609d54441493c99f21c1823dfd66fa7f4c512ff4
- https://git.kernel.org/stable/c/6631c8da02cfad96c53b217cf647b511c7f34faf
- https://git.kernel.org/stable/c/a759905de9cd6ec9ca08ceadf0920272772ed830
- https://git.kernel.org/stable/c/cec08b7d1ebcd3138d4658b3868ce26aeb1e8e06
- https://git.kernel.org/stable/c/eea8e4e056a5ffbeb539a13854c017d5d62c756a
- https://git.kernel.org/stable/c/f31cd5da636682caea424fa1c22679016cbfc16b
- https://git.kernel.org/stable/c/f8cd8754a03a3748384ee438c572423643c9c315
Modified: 2025-11-10
CVE-2023-53119
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: initialize struct pn533_out_arg properly
struct pn533_out_arg used as a temporary context for out_urb is not
initialized properly. Its uninitialized 'phy' field can be dereferenced in
error cases inside pn533_out_complete() callback function. It causes the
following failure:
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441
Call Trace:
- https://git.kernel.org/stable/c/0f9c1f26d434c32520dfe33326b28c5954bc4299
- https://git.kernel.org/stable/c/2703da78849c47b6b5b4471edb35fc7b7f91dead
- https://git.kernel.org/stable/c/2bd1ed6d607d7013ed4959e86990a04f028543ef
- https://git.kernel.org/stable/c/2bee84369b76f6c9ef71938069c65a6ebd1a12f7
- https://git.kernel.org/stable/c/2cbd4213baf7be5d87d183e2032c54003de0790f
- https://git.kernel.org/stable/c/484b7059796e3bc1cb527caa61dfc60da649b4f6
- https://git.kernel.org/stable/c/4c20a07ed26a71a8ccc9c6d935fc181573f5462e
- https://git.kernel.org/stable/c/a97ef110c491b72c138111a595a3a3af56cbc94c
Modified: 2025-11-10
CVE-2023-53121
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_make_synack() can be called from process context
tcp_rtx_synack() now could be called in process context as explained in
0a375c822497 ("tcp: tcp_rtx_synack() can be called from process
context").
tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU
variables with preemption enabled. This causes the following BUG:
BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464
caller is tcp_make_synack+0x841/0xac0
Call Trace:
- https://git.kernel.org/stable/c/442aa78ed70188b21ccd8669738448702c0a3281
- https://git.kernel.org/stable/c/7613cde8c0c1f02a7ec2e1d536c01b65b135fc1c
- https://git.kernel.org/stable/c/77ad58bca0119e8cc3e0e9d91a3f22caa66e4dfa
- https://git.kernel.org/stable/c/9180aa4622a720b433e842b4d3aa34d73eec577a
- https://git.kernel.org/stable/c/ad07290d63ff6689f50565b02f5b6f34ec15a5ca
- https://git.kernel.org/stable/c/bced3f7db95ff2e6ca29dc4d1c9751ab5e736a09
- https://git.kernel.org/stable/c/d493d4fe88195a144d6a277a90062a7534ed2192
- https://git.kernel.org/stable/c/e23ca307745be3df7fe9762f3e2a7e311a57852e
Modified: 2025-11-10
CVE-2023-53124
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add() Port is allocated by sas_port_alloc_num() and rphy is allocated by either sas_end_device_alloc() or sas_expander_alloc(), all of which may return NULL. So we need to check the rphy to avoid possible NULL pointer access. If sas_rphy_add() returned with failure, rphy is set to NULL. We would access the rphy in the following lines which would also result NULL pointer access.
- https://git.kernel.org/stable/c/090305c36185c0547e4441d4c08f1cf096b32134
- https://git.kernel.org/stable/c/6f0c2f70d9929208d8427ec72c3ed91e2251e289
- https://git.kernel.org/stable/c/9937f784a608944107dcc2ba9a9c3333f8330b9e
- https://git.kernel.org/stable/c/a26c775ccc4cfe46f9b718b51bd24313053c7e0b
- https://git.kernel.org/stable/c/b5e5bbb3fa5f8412e96c5eda7f4a4af6241d6bd3
- https://git.kernel.org/stable/c/d3c57724f1569311e4b81e98fad0931028b9bdcd
Modified: 2025-11-10
CVE-2023-53125
In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Limit packet length to skb->len Packet length retrieved from skb data may be larger than the actual socket buffer length (up to 9026 bytes). In such case the cloned skb passed up the network stack will leak kernel memory contents.
- https://git.kernel.org/stable/c/105db6574281e1e03fcbf87983f4fee111682306
- https://git.kernel.org/stable/c/4a4de0a68b18485c68ab4f0cfa665b1633c6d277
- https://git.kernel.org/stable/c/53966d572d056d6b234cfe76a5f9d60049d3c178
- https://git.kernel.org/stable/c/8ee5df9c039e37b9d8eb5e3de08bfb7f53d31cb6
- https://git.kernel.org/stable/c/9fabdd79051a9fe51388df099aff6e4b660fedd2
- https://git.kernel.org/stable/c/c7bdc137ca163b90917c1eeba4f1937684bd4f8b
- https://git.kernel.org/stable/c/d8b228318935044dafe3a5bc07ee71a1f1424b8d
- https://git.kernel.org/stable/c/e294f0aa47e4844f3d3c8766c02accd5a76a7d4e
Modified: 2025-11-10
CVE-2023-53131
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a server shutdown leak Fix a race where kthread_stop() may prevent the threadfn from ever getting called. If that happens the svc_rqst will not be cleaned up.
- https://git.kernel.org/stable/c/7a3720361068ab520aed4608bad31ea9a6cc7fe7
- https://git.kernel.org/stable/c/9ca6705d9d609441d34f8b853e1e4a6369b3b171
- https://git.kernel.org/stable/c/ad7e40ee157ba33950a4ccdc284334580da3638d
- https://git.kernel.org/stable/c/ce7dd61e004002bc1c48d1ca47c887f3f3cc7370
- https://git.kernel.org/stable/c/f74b3286859463cd63cc9d4aeaabd8b0c640182a
Modified: 2025-11-10
CVE-2023-53134
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Avoid order-5 memory allocation for TPA data The driver needs to keep track of all the possible concurrent TPA (GRO/LRO) completions on the aggregation ring. On P5 chips, the maximum number of concurrent TPA is 256 and the amount of memory we allocate is order-5 on systems using 4K pages. Memory allocation failure has been reported: NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1 Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022 Call Trace: dump_stack+0x57/0x6e warn_alloc.cold.120+0x7b/0xdd ? _cond_resched+0x15/0x30 ? __alloc_pages_direct_compact+0x15f/0x170 __alloc_pages_slowpath.constprop.108+0xc58/0xc70 __alloc_pages_nodemask+0x2d0/0x300 kmalloc_order+0x24/0xe0 kmalloc_order_trace+0x19/0x80 bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en] ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en] __bnxt_open_nic+0x12e/0x780 [bnxt_en] bnxt_open+0x10b/0x240 [bnxt_en] __dev_open+0xe9/0x180 __dev_change_flags+0x1af/0x220 dev_change_flags+0x21/0x60 do_setlink+0x35c/0x1100 Instead of allocating this big chunk of memory and dividing it up for the concurrent TPA instances, allocate each small chunk separately for each TPA instance. This will reduce it to order-0 allocations.
- https://git.kernel.org/stable/c/16f3aae1aa2dd89bc8d073a67f190af580386ae9
- https://git.kernel.org/stable/c/20fd0607acbf9770db9b99e3418dd75614f80b6c
- https://git.kernel.org/stable/c/accd7e23693aaaa9aa0d3e9eca0ae77d1be80ab3
- https://git.kernel.org/stable/c/ad529d1fae1565d38f929479d4ea8aea90054bd2
- https://git.kernel.org/stable/c/d16701a385b54f44bf41ff1d7485e7a11080deb3
- https://git.kernel.org/stable/c/fcae40e65802547def39b4deaa2ae38a29864d81
Modified: 2025-11-10
CVE-2023-53135
In the Linux kernel, the following vulnerability has been resolved:
riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode
When CONFIG_FRAME_POINTER is unset, the stack unwinding function
walk_stackframe randomly reads the stack and then, when KASAN is enabled,
it can lead to the following backtrace:
[ 0.000000] ==================================================================
[ 0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a
[ 0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0
[ 0.000000]
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43
[ 0.000000] Hardware name: riscv-virtio,qemu (DT)
[ 0.000000] Call Trace:
[ 0.000000] [
- https://git.kernel.org/stable/c/17fa90ffba20743c946920fbb0afe160d0ead8c9
- https://git.kernel.org/stable/c/324912d6c0c4006711054d389faa2239c1655e1e
- https://git.kernel.org/stable/c/3a9418d2c93c1c86ce4d0595112d91c7a8e70c2c
- https://git.kernel.org/stable/c/3de277af481ab931fab9e295ad8762692920732a
- https://git.kernel.org/stable/c/76950340cf03b149412fe0d5f0810e52ac1df8cb
- https://git.kernel.org/stable/c/a99a61d9e1bfca2fc37d223a6a185c0eb66aba02
Modified: 2025-11-10
CVE-2023-53138
In the Linux kernel, the following vulnerability has been resolved:
net: caif: Fix use-after-free in cfusbl_device_notify()
syzbot reported use-after-free in cfusbl_device_notify() [1]. This
causes a stack trace like below:
BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138
Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214
CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
- https://git.kernel.org/stable/c/1793da97a23e31c5bf06631f3f3e5a25f368fd64
- https://git.kernel.org/stable/c/287027d8a567168a5d8ce5cb0cba16a34791a48c
- https://git.kernel.org/stable/c/3f14457e1584224f4296af613bbd99deb60b5d91
- https://git.kernel.org/stable/c/68a45c3cf0e2242a533657f4f535d9b6a7447a79
- https://git.kernel.org/stable/c/9781e98a97110f5e76999058368b4be76a788484
- https://git.kernel.org/stable/c/9dc16be373b382ddd4c274052a6e870a95e76c01
- https://git.kernel.org/stable/c/c3aaec463a632cf4187dc017e421bfa69d7834a9
- https://git.kernel.org/stable/c/d1a11bbdbb5ea9f172019c5a4a3e9d8eabd72179
Modified: 2025-11-10
CVE-2023-53139
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause out-of-bounds write in device_property_read_u8_array later.
- https://git.kernel.org/stable/c/0a3664a1058d4b2b1ea2112cc275ca47fba7fc08
- https://git.kernel.org/stable/c/11f180a5d62a51b484e9648f9b310e1bd50b1a57
- https://git.kernel.org/stable/c/27824b2f98818215adc9661e563252c48dab1a13
- https://git.kernel.org/stable/c/4357bbb921fe9e81d0fd9f70d669d1f177d8380e
- https://git.kernel.org/stable/c/80be62358fa5507cefbaa067c7e6648401f2c3da
- https://git.kernel.org/stable/c/98f49e693e02c1dafd5786be3468657840dd6f06
- https://git.kernel.org/stable/c/ad11b872bc9b5d27e56183c6b01f9218c85395d2
- https://git.kernel.org/stable/c/ce93f1afc05941a572f5a69e2ed4012af905a693
Modified: 2025-11-10
CVE-2023-53140
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Remove the /proc/scsi/${proc_name} directory earlier Remove the /proc/scsi/${proc_name} directory earlier to fix a race condition between unloading and reloading kernel modules. This fixes a bug introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core"). Fix the following kernel warning: proc_dir_entry 'scsi/scsi_debug' already registered WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0 Call Trace: proc_mkdir+0xb5/0xe0 scsi_proc_hostdir_add+0xb5/0x170 scsi_host_alloc+0x683/0x6c0 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug] really_probe+0x159/0x540 __driver_probe_device+0xdc/0x230 driver_probe_device+0x4f/0x120 __device_attach_driver+0xef/0x180 bus_for_each_drv+0xe5/0x130 __device_attach+0x127/0x290 device_initial_probe+0x17/0x20 bus_probe_device+0x110/0x130 device_add+0x673/0xc80 device_register+0x1e/0x30 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug] scsi_debug_init+0x64f/0x1000 [scsi_debug] do_one_initcall+0xd7/0x470 do_init_module+0xe7/0x330 load_module+0x122a/0x12c0 __do_sys_finit_module+0x124/0x1a0 __x64_sys_finit_module+0x46/0x50 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/13daafe1e209b03e9bda16ff2bd2b2da145a139b
- https://git.kernel.org/stable/c/17e98a5ede81b7696bec421f7afa2dfe467f5e6b
- https://git.kernel.org/stable/c/1ec363599f8346d5a8d08c71a0d9860d6c420ec0
- https://git.kernel.org/stable/c/6b223e32d66ca9db1f252f433514783d8b22a8e1
- https://git.kernel.org/stable/c/891a3cba425cf483d96facca55aebd6ff1da4338
- https://git.kernel.org/stable/c/e471e928de97b00f297ad1015cc14f9459765713
- https://git.kernel.org/stable/c/fc663711b94468f4e1427ebe289c9f05669699c9
Modified: 2025-11-10
CVE-2023-53141
In the Linux kernel, the following vulnerability has been resolved:
ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
ila_xlat_nl_cmd_get_mapping() generates an empty skb,
triggerring a recent sanity check [1].
Instead, return an error code, so that user space
can get it.
[1]
skb_assert_len
WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]
WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
Modules linked in:
CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : skb_assert_len include/linux/skbuff.h:2527 [inline]
pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
lr : skb_assert_len include/linux/skbuff.h:2527 [inline]
lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
sp : ffff80001e0d6c40
x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0
x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00
x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10
x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0
x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001
x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600
x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e
Call trace:
skb_assert_len include/linux/skbuff.h:2527 [inline]
__dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
dev_queue_xmit include/linux/netdevice.h:3033 [inline]
__netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]
__netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325
netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338
__netlink_sendskb net/netlink/af_netlink.c:1283 [inline]
netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292
netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380
nlmsg_unicast include/net/netlink.h:1099 [inline]
genlmsg_unicast include/net/genetlink.h:433 [inline]
genlmsg_reply include/net/genetlink.h:443 [inline]
ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493
genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065
netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574
genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0x558/0x844 net/socket.c:2479
___sys_sendmsg net/socket.c:2533 [inline]
__sys_sendmsg+0x26c/0x33c net/socket.c:2562
__do_sys_sendmsg net/socket.c:2571 [inline]
__se_sys_sendmsg net/socket.c:2569 [inline]
__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193
el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
irq event stamp: 136484
hardirqs last enabled at (136483): [
- https://git.kernel.org/stable/c/25b54f247ea060aeb85ec88a82c75060fca03521
- https://git.kernel.org/stable/c/42d9ed4e5dc5f87fbd67c232e2e4a9b88ceeb47f
- https://git.kernel.org/stable/c/60fe7cb483c8c5dcadaeeac867251d6e59c7badc
- https://git.kernel.org/stable/c/693aa2c0d9b6d5b1f2745d31b6e70d09dbbaf06e
- https://git.kernel.org/stable/c/783f218940b3c7b872e4111d0145000f26ecbdf6
- https://git.kernel.org/stable/c/91aceb3844d4aec555c7f423f9fd843eff5835e9
- https://git.kernel.org/stable/c/b26bc5861505f04dea933ca3e522772b20fa086f
- https://git.kernel.org/stable/c/c631e52aea0fc8d4deea06e439f5810a8b40ad0f
Modified: 2025-11-10
CVE-2023-53143
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix another off-by-one fsmap error on 1k block filesystems
Apparently syzbot figured out that issuing this FSMAP call:
struct fsmap_head cmd = {
.fmh_count = ...;
.fmh_keys = {
{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
},
...
};
ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);
Produces this crash if the underlying filesystem is a 1k-block ext4
filesystem:
kernel BUG at fs/ext4/ext4.h:3331!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]
RSP: 0018:ffffc90007c03998 EFLAGS: 00010246
RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000
RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11
RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400
R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001
R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398
FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0
Call Trace:
- https://git.kernel.org/stable/c/15ebade3266b300da9cd1edce4004fe8fd6a2b88
- https://git.kernel.org/stable/c/1d2366624b4c19a2ba6baf67fe57f4a1b0f67c05
- https://git.kernel.org/stable/c/a70b49dc7eee5dbe3775a650ce598e3557ff5475
- https://git.kernel.org/stable/c/c24f838493792b5e78a3596b4ca96375aa0af4c2
- https://git.kernel.org/stable/c/c5d7c31e17224d847a330180ec1b03bf390632b2
- https://git.kernel.org/stable/c/c993799baf9c5861f8df91beb80e1611b12efcbd
- https://git.kernel.org/stable/c/eb3a695aa71a514f2e7f5778e05faba3733b70a0
- https://git.kernel.org/stable/c/f16054ac1774915160ca4e1c73ff7a269465a1b9
Modified: 2025-11-24
CVE-2023-53153
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix use after free for wext Key information in wext.connect is not reset on (re)connect and can hold data from a previous connection. Reset key data to avoid that drivers or mac80211 incorrectly detect a WEP connection request and access the freed or already reused memory. Additionally optimize cfg80211_sme_connect() and avoid an useless schedule of conn_work.
- https://git.kernel.org/stable/c/015b8cc5e7c4d7bb671f1984d7b7338c310b185b
- https://git.kernel.org/stable/c/22dfb21bf1cd876616d45cda1bc6daa89eec6747
- https://git.kernel.org/stable/c/2cfe78619b0de6d2da773978bc2d22797212eaa7
- https://git.kernel.org/stable/c/66af4a2ab1d65d556d638cb9555a3b823c2557a9
- https://git.kernel.org/stable/c/6f1959c17d4cb5b74af6fc31dc787e1dc3e4f6e2
- https://git.kernel.org/stable/c/a2a92b3e9d8e03ee3f9ee407fc46a9b4bd02d8b6
- https://git.kernel.org/stable/c/f4b6a138efb8a32507b8946104e32cb926308da7
- https://git.kernel.org/stable/c/fd081afd21eb35b968b0330700c43ec94986e1c4
Modified: 2025-11-24
CVE-2023-53164
In the Linux kernel, the following vulnerability has been resolved: irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/02298b7bae12936ca313975b02e7f98b06670d37
- https://git.kernel.org/stable/c/07fceab32096c1290b491f2fcaace03f78e2db37
- https://git.kernel.org/stable/c/4ae40c20f1519e1767ba01609abc7e8d6485fc0c
- https://git.kernel.org/stable/c/856fc2195494d1175ada0f1f46f92c5b28ce12eb
- https://git.kernel.org/stable/c/a0d91a48e1a020fb636f0fcaf44672f123bb0799
- https://git.kernel.org/stable/c/df8d3536b660c6c6f6b25fa8b157e9b38ad78142
Modified: 2025-12-02
CVE-2023-53171
In the Linux kernel, the following vulnerability has been resolved: vfio/type1: prevent underflow of locked_vm via exec() When a vfio container is preserved across exec, the task does not change, but it gets a new mm with locked_vm=0, and loses the count from existing dma mappings. If the user later unmaps a dma mapping, locked_vm underflows to a large unsigned value, and a subsequent dma map request fails with ENOMEM in __account_locked_vm. To avoid underflow, grab and save the mm at the time a dma is mapped. Use that mm when adjusting locked_vm, rather than re-acquiring the saved task's mm, which may have changed. If the saved mm is dead, do nothing. locked_vm is incremented for existing mappings in a subsequent patch.
- https://git.kernel.org/stable/c/046eca5018f8a5dd1dc2cedf87fb5843b9ea3026
- https://git.kernel.org/stable/c/5a271242716846cc016736fb76be2b40ee49b0c3
- https://git.kernel.org/stable/c/a6b2aabe664098d5cf877ae0fd96459464a30e17
- https://git.kernel.org/stable/c/b0790dff0760b7734cf0961f497ad64628ca550b
- https://git.kernel.org/stable/c/eafb81c50da899dd80b340c841277acc4a1945b7
Modified: 2025-12-02
CVE-2023-53191
In the Linux kernel, the following vulnerability has been resolved: irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/071d068b89e95d1b078aa6bbcb9d0961b77d6aa1
- https://git.kernel.org/stable/c/5fbf2cc39b62a4afe44f3d42ee3dcf8f012c1926
- https://git.kernel.org/stable/c/65e30bd1310d90b794c377bf405394157854aa30
- https://git.kernel.org/stable/c/9e79ac4f70fd51243e1c6108d4b0baf16cfde99c
- https://git.kernel.org/stable/c/c9aaf4efe1f02b2fef21a69fb3652f5ad12a5710
- https://git.kernel.org/stable/c/d6c66c46889752fa4962c6388516f7ab66a8d6a1
- https://git.kernel.org/stable/c/eef04516f0c317ce80502c1d6b0d06235a87cd8f
- https://git.kernel.org/stable/c/eef09f786df4b34b97557929287c4e5a83bbf09b
Modified: 2025-12-03
CVE-2023-53199
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails Syzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream(). While processing skbs in ath9k_hif_usb_rx_stream(), the already allocated skbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we have an incorrect pkt_len or pkt_tag, the input skb is considered invalid and dropped. All the associated packets already in skb_pool should be dropped and freed. Added a comment describing this issue. The patch also makes remain_skb NULL after being processed so that it cannot be referenced after potential free. The initialization of hif_dev fields which are associated with remain_skb (rx_remain_len, rx_transfer_len and rx_pad_len) is moved after a new remain_skb is allocated. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/0af54343a76263a12dbae7fafb64eb47c4a6ad38
- https://git.kernel.org/stable/c/3fc6401fafde11712a83089fa2cc874cfd10e2cd
- https://git.kernel.org/stable/c/61490d2710277e8a55009b7682456ae22f8087cf
- https://git.kernel.org/stable/c/9acdec72787af1bc8ed92711b52118c8e3e638a2
- https://git.kernel.org/stable/c/c766e37fccd5a5c5059be7efcd9618bf8a2c17c3
- https://git.kernel.org/stable/c/cd8316767099920a5d41feed1afab0c482a43e9f
- https://git.kernel.org/stable/c/f26dd69f61eff2eedf5df2d199bdd23108309947
Modified: 2026-01-14
CVE-2023-53216
In the Linux kernel, the following vulnerability has been resolved: arm64: efi: Make efi_rt_lock a raw_spinlock Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs the following: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by kworker/u320:0/9: #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) Preemption disabled at: efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248) CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1 Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18 Workqueue: efi_rts_wq efi_call_rts Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:158) show_stack (arch/arm64/kernel/stacktrace.c:165) dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) dump_stack (lib/dump_stack.c:114) __might_resched (kernel/sched/core.c:10134) rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4)) efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) [...] This seems to come from commit ff7a167961d1 ("arm64: efi: Execute runtime services from a dedicated stack") which adds a spinlock. This spinlock is taken through: efi_call_rts() \-efi_call_virt() \-efi_call_virt_pointer() \-arch_efi_call_virt_setup() Make 'efi_rt_lock' a raw_spinlock to avoid being preempted. [ardb: The EFI runtime services are called with a different set of translation tables, and are permitted to use the SIMD registers. The context switch code preserves/restores neither, and so EFI calls must be made with preemption disabled, rather than only disabling migration.]
- https://git.kernel.org/stable/c/030b1c4217a4f504c7d0795a2bd86b7181e56f11
- https://git.kernel.org/stable/c/0e68b5517d3767562889f1d83fdb828c26adb24f
- https://git.kernel.org/stable/c/4e8f7d998b582a99aadedd07ae6086e99b89c97a
- https://git.kernel.org/stable/c/6a72729ed6accc86dad5522895e8fa2f96642a2c
- https://git.kernel.org/stable/c/8b38969fa01662ec539a0d08a8ea5ec6f31fa4ed
Modified: 2026-01-14
CVE-2023-53223
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Add missing check for alloc_ordered_workqueue Add check for the return value of alloc_ordered_workqueue as it may return NULL pointer and cause NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/517646/
- https://git.kernel.org/stable/c/115906ca7b535afb1fe7b5406c566ccd3873f82b
- https://git.kernel.org/stable/c/25a6499b1a53d854eda2b161b5c8a20296515dbe
- https://git.kernel.org/stable/c/3a9a4a9725c60f04326b5019a52ce15aee808506
- https://git.kernel.org/stable/c/3e18f157faeeb59034404569e8e07cbe1c0030a7
- https://git.kernel.org/stable/c/540c66180afd59309a442d3bf1f2393464c8b4c5
- https://git.kernel.org/stable/c/5dfe7a5386fde5a656ca06602b31bf50e26954cd
- https://git.kernel.org/stable/c/759ea5677c362fb1e3edc667260ba9f409dc931d
- https://git.kernel.org/stable/c/9257974858ee847b2e1fd552691b8ba5c2fc1c7b
Modified: 2026-01-14
CVE-2023-53233
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix deadlock triggered by cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock: 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0 __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20 __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated---
- https://git.kernel.org/stable/c/13085e1b5cab8ad802904d72e6a6dae85ae0cd20
- https://git.kernel.org/stable/c/3517584cf1b35bd02f4a90267ddf9dcf17bd9c87
- https://git.kernel.org/stable/c/9708efad9ba5095b9bb7916e11a135b3bd66c071
- https://git.kernel.org/stable/c/b615238e5bc01e13dc0610febddc1ca99bab1df6
- https://git.kernel.org/stable/c/c9ca2257150272df1b8d9ebe5059197ffea6e913
Modified: 2026-01-14
CVE-2023-53234
In the Linux kernel, the following vulnerability has been resolved: watchdog: Fix kmemleak in watchdog_cdev_register kmemleak reports memory leaks in watchdog_dev_register, as follows: unreferenced object 0xffff888116233000 (size 2048): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 32 bytes): 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#..... 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#............. backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<000000006a389304>] kmalloc_trace+0x21/0x110 [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... unreferenced object 0xffff888105b9fa80 (size 16): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 16 bytes): 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1....... backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintf_const+0x55/0x180 [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150 [<00000000a92e820b>] dev_set_name+0xab/0xe0 [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... The reason is that put_device is not be called if cdev_device_add fails and wdd->id != 0. watchdog_cdev_register wd_data = kzalloc [1] err = dev_set_name [2] .. err = cdev_device_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // [1],[2] would be leaked To fix it, call put_device in all wdd->id cases.
- https://git.kernel.org/stable/c/13721a2ac66b246f5802ba1b75ad8637e53eeecc
- https://git.kernel.org/stable/c/23cc41c3f19c4d858c3708f1c0a06e94958e6c3b
- https://git.kernel.org/stable/c/50808d034e199fe3ff7a9d2068a4eebeb6b4098a
- https://git.kernel.org/stable/c/59e391b3fc507a15b7e8e9d9f4de87cae177c366
- https://git.kernel.org/stable/c/8c1655600f4f2839fb844fe8c70b2b65fadc7a56
- https://git.kernel.org/stable/c/ac099d94e0480c937aa9172ab64074981ca1a4d3
- https://git.kernel.org/stable/c/bf26b0e430ce34261f45959989edaf680b64d538
- https://git.kernel.org/stable/c/c5a21a5501508ae3afa2fe6d5a3e74a37fa48df3
Modified: 2026-01-14
CVE-2023-53239
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Add check for kzalloc As kzalloc may fail and return NULL pointer, it should be better to check the return value in order to avoid the NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/514154/
- https://git.kernel.org/stable/c/13fcfcb2a9a4787fe4e49841d728f6f2e9fa6911
- https://git.kernel.org/stable/c/37ff771ed008b9cbffd0eab77985968364694ce3
- https://git.kernel.org/stable/c/3975ea6eaffe26aec634b5c473e51dc76e73af62
- https://git.kernel.org/stable/c/49907c8873826ee771ba0ca1629e809c6479f617
- https://git.kernel.org/stable/c/82943a0730e00c14b03e25a4b2a1a9477ae89d7b
- https://git.kernel.org/stable/c/bc579a2ee8b2e20c152b24b437d094832d8c9c9e
Modified: 2026-01-14
CVE-2023-53242
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/hisi: Drop second sensor hi3660 The commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm allocators") exposes a panic "BRK handler: Fatal exception" on the hi3660_thermal_probe funciton. This is because the function allocates memory for only one sensors array entry, but tries to fill up a second one. Fix this by removing the unneeded second access.
- https://git.kernel.org/stable/c/15cc25829a97c3957e520e971868aacc84341317
- https://git.kernel.org/stable/c/3cf2181e438f43ed24e12424fe36d156cca233b9
- https://git.kernel.org/stable/c/68e675a9b69cfc34dd915d91a4650e3ee53421f4
- https://git.kernel.org/stable/c/9f6756cd09889c7201ee31e6f76fbd914fb0b80d
- https://git.kernel.org/stable/c/e02bc492883abf751fd1a8d89fc025fbce6744c6
- https://git.kernel.org/stable/c/f5aaf140ab1c02889c088e1b1098adad600541af
Modified: 2026-01-14
CVE-2023-53265
In the Linux kernel, the following vulnerability has been resolved:
ubi: ensure that VID header offset + VID header size <= alloc, size
Ensure that the VID header offset + VID header size does not exceed
the allocated area to avoid slab OOB.
BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197
Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555
CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W
6.0.0-1868 #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29
04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1b42b1a36fc946f0d7088425b90d491b4257ca3e
- https://git.kernel.org/stable/c/61aeba0e4b4124cfe3c5427feaf29c626dfa89e5
- https://git.kernel.org/stable/c/61e04db3bec87f7dd10074296deb7d083e2ccade
- https://git.kernel.org/stable/c/701bb3ed5a88a73ebbe1266895bdeff065226dca
- https://git.kernel.org/stable/c/771e207a839a29ba943e89f473b0fecd16089e2e
- https://git.kernel.org/stable/c/846bfba34175c23b13cc2023c2d67b96e8c14c43
- https://git.kernel.org/stable/c/e1b73fe4f4c6bb80755eb4bf4b867a8fd8b1a7fe
- https://git.kernel.org/stable/c/f7adb740f97b6fa84e658892dcb08e37a31a4e77
Modified: 2026-01-14
CVE-2023-53271
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()
There is a memory leaks problem reported by kmemleak:
unreferenced object 0xffff888102007a00 (size 128):
comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s)
hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
backtrace:
[
- https://git.kernel.org/stable/c/07b60f7452d2fa731737552937cb81821919f874
- https://git.kernel.org/stable/c/09780a44093b53f9cbca76246af2e4ff0884e512
- https://git.kernel.org/stable/c/1e591ea072df7211f64542a09482b5f81cb3ad27
- https://git.kernel.org/stable/c/26ec2d66aecab8ff997b912c20247fedba4f5740
- https://git.kernel.org/stable/c/27b760b81951d8d5e5c952a696af8574052b0709
- https://git.kernel.org/stable/c/31d60afe2cc2b712dbefcaab6b7d6a47036f844e
- https://git.kernel.org/stable/c/5c0c81a313492b83bd0c038b8839b0e04eb87563
- https://git.kernel.org/stable/c/95a72417dd13ebcdcb1bd0c5d4d15f7c5bfbb288
Modified: 2026-01-14
CVE-2023-53277
In the Linux kernel, the following vulnerability has been resolved: wifi: iwl3945: Add missing check for create_singlethread_workqueue Add the check for the return value of the create_singlethread_workqueue in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/17e07d6587c55015956862ef3b101fd45fa49fbc
- https://git.kernel.org/stable/c/1fdeb8b9f29dfd64805bb49475ac7566a3cb06cb
- https://git.kernel.org/stable/c/2f80b3ff92514ebd227e5c55d3d1e480401b02b7
- https://git.kernel.org/stable/c/34f611204ae589bd5c494b10b41fb13436bd3c3f
- https://git.kernel.org/stable/c/3ae2fc4de12686f3fe695824169c1272c9f798f7
- https://git.kernel.org/stable/c/505c74c4c0b1c5bcaa98a93b3087c268156070f1
- https://git.kernel.org/stable/c/7e594abc0424e4f8c2385f11aefeaadcfc507aa5
Modified: 2026-01-14
CVE-2023-53295
In the Linux kernel, the following vulnerability has been resolved: udf: Do not update file length for failed writes to inline files When write to inline file fails (or happens only partly), we still updated length of inline data as if the whole write succeeded. Fix the update of length of inline data to happen only if the write succeeds.
- https://git.kernel.org/stable/c/256fe4162f8b5a1625b8603ca5f7ff79725bfb47
- https://git.kernel.org/stable/c/5621f7a8139053d0c3c47fb68ee9f602139eb40a
- https://git.kernel.org/stable/c/5a6c373d761f55635e175fa2f407544bae8f583b
- https://git.kernel.org/stable/c/6837910aeb2c9101fc036dcd1b1f32615c20ec1a
- https://git.kernel.org/stable/c/6d18cedc1ef0caeb1567cab660079e48844ff6d6
- https://git.kernel.org/stable/c/7bd8d9e1cf5607ee14407f4060b9a1dbb3c42802
- https://git.kernel.org/stable/c/c5787d77a5c29fffd295d138bd118b334990a567
- https://git.kernel.org/stable/c/eb2133900cac2d2f78befd6be41666cf1a2315d9
Modified: 2026-01-14
CVE-2023-53298
In the Linux kernel, the following vulnerability has been resolved: nfc: fix memory leak of se_io context in nfc_genl_se_io The callback context for sending/receiving APDUs to/from the selected secure element is allocated inside nfc_genl_se_io and supposed to be eventually freed in se_io_cb callback function. However, there are several error paths where the bwi_timer is not charged to call se_io_cb later, and the cb_context is leaked. The patch proposes to free the cb_context explicitly on those error paths. At the moment we can't simply check 'dev->ops->se_io()' return value as it may be negative in both cases: when the timer was charged and was not.
- https://git.kernel.org/stable/c/25ff6f8a5a3b8dc48e8abda6f013e8cc4b14ffea
- https://git.kernel.org/stable/c/271eed1736426103335c5aac50f15b0f4d236bc0
- https://git.kernel.org/stable/c/5321da6d84b87a34eea441677d649c34bd854169
- https://git.kernel.org/stable/c/8978315cb4bf8878c9c8ec05dafd8f7ff539860d
- https://git.kernel.org/stable/c/af452e35b9e6a87cd49e54a7a3d60d934b194651
- https://git.kernel.org/stable/c/b2036a252381949d3b743a3de069324ae3028a57
- https://git.kernel.org/stable/c/ba98db08895748c12e5ded52cd1598dce2c79e55
- https://git.kernel.org/stable/c/c494365432dcdc549986f4d9af9eb6190cbdb153
Modified: 2026-01-14
CVE-2023-53302
In the Linux kernel, the following vulnerability has been resolved: wifi: iwl4965: Add missing check for create_singlethread_workqueue() Add the check for the return value of the create_singlethread_workqueue() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/26e6775f75517ad6844fe5b79bc5f3fa8c22ee61
- https://git.kernel.org/stable/c/2f85c768bea2057e3299d19514da9e932c4f92d2
- https://git.kernel.org/stable/c/3185d6cfc59277a77bf311dce701b7e25193f66a
- https://git.kernel.org/stable/c/874a85051cc8df8c5b928d8ff172b342cdc5424b
- https://git.kernel.org/stable/c/878a7c8357764e08bc778bcb26127fc12a4b36b7
- https://git.kernel.org/stable/c/c002d2741400771171b68dde9af937a4dfa0d1b3
- https://git.kernel.org/stable/c/f15ef0ebcf56be1d4a3c9a7a80a1f1f82ab0eaad
Modified: 2026-01-14
CVE-2023-53307
In the Linux kernel, the following vulnerability has been resolved:
rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails
If getting an ID or setting up a work queue in rbd_dev_create() fails,
use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts
is triggered in do_rbd_add(). The root cause is that the ownership of
these structures is transfered to rbd_dev prematurely and they all end
up getting freed when rbd_dev_create() calls rbd_dev_free() prior to
returning to do_rbd_add().
Found by Linux Verification Center (linuxtesting.org) with SVACE, an
incomplete patch submitted by Natalia Petrova
- https://git.kernel.org/stable/c/71da2a151ed1adb0aea4252b16d81b53012e7afd
- https://git.kernel.org/stable/c/9787b328c42c13c4f31e7d5042c4e877e9344068
- https://git.kernel.org/stable/c/a73783e4e0c4d1507794da211eeca75498544dff
- https://git.kernel.org/stable/c/ae16346078b1189aee934afd872d9f3d0a682c33
- https://git.kernel.org/stable/c/cc8c0dd2984503ed09efa37bcafcef3d3da104e8
- https://git.kernel.org/stable/c/e3cbb4d60764295992c95344f2d779439e8b34ce
- https://git.kernel.org/stable/c/f7c4d9b133c7a04ca619355574e96b6abf209fba
- https://git.kernel.org/stable/c/faa7b683e436664fff5648426950718277831348
Modified: 2026-01-14
CVE-2023-53346
In the Linux kernel, the following vulnerability has been resolved: kernel/fail_function: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
- https://git.kernel.org/stable/c/29d53c4c5a6f6d2b93aaac95b65cb4c907faf2ff
- https://git.kernel.org/stable/c/2bb3669f576559db273efe49e0e69f82450efbca
- https://git.kernel.org/stable/c/94f68f3e059c478e240f65fcb64746fe371295df
- https://git.kernel.org/stable/c/bb99db06b8b6ce9351633fc61bec9919d8f6f52b
- https://git.kernel.org/stable/c/dd9981a11d74ff2eb253bb5c459876f8bd3c6c36
- https://git.kernel.org/stable/c/f6d3aee1c66358471275df9dddd480010f061b0e
Modified: 2026-01-14
CVE-2023-53349
In the Linux kernel, the following vulnerability has been resolved: media: ov2740: Fix memleak in ov2740_init_controls() There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock device: unreferenced object 0xffff8881090e19e0 (size 16): comm "51-i2c-ov2740", pid 278, jiffies 4294781584 (age 23.613s) hex dump (first 16 bytes): 00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|......uj..... backtrace: [<000000004e9fad8f>] __kmalloc_node+0x44/0x1b0 [<0000000039c802f4>] kvmalloc_node+0x34/0x180 [<000000009b8b5c63>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<0000000038644056>] ov2740_probe+0x37d/0x84f [ov2740] [<0000000092489f59>] i2c_device_probe+0x28d/0x680 [<000000001038babe>] really_probe+0x17c/0x3f0 [<0000000098c7af1c>] __driver_probe_device+0xe3/0x170 [<00000000e1b3dc24>] device_driver_attach+0x34/0x80 [<000000005a04a34d>] bind_store+0x10b/0x1a0 [<00000000ce25d4f2>] drv_attr_store+0x49/0x70 [<000000007d9f4e9a>] sysfs_kf_write+0x8c/0xb0 [<00000000be6cff0f>] kernfs_fop_write_iter+0x216/0x2e0 [<0000000031ddb40a>] vfs_write+0x658/0x810 [<0000000041beecdd>] ksys_write+0xd6/0x1b0 [<0000000023755840>] do_syscall_64+0x38/0x90 [<00000000b2cc2da2>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ov2740_init_controls() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak.
- https://git.kernel.org/stable/c/2d899592ed7829d0d5140853bac4d58742a6b8af
- https://git.kernel.org/stable/c/3969b2ebc66039306f505c7c630c5530800f83c0
- https://git.kernel.org/stable/c/7c405ee63447f14eefcfe12a18aa749abbd596ea
- https://git.kernel.org/stable/c/a163ee11345d8322321c28bd61631de32455b987
- https://git.kernel.org/stable/c/fc33380ae06f438b652f66b9370b543976ac8a03
Modified: 2026-01-14
CVE-2023-53373
In the Linux kernel, the following vulnerability has been resolved: crypto: seqiv - Handle EBUSY correctly As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request. However, as the caller of seqiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.
- https://git.kernel.org/stable/c/1effbddaff60eeef8017c6dea1ee0ed970164d14
- https://git.kernel.org/stable/c/32e62025e5e52fbe4812ef044759de7010b15dbc
- https://git.kernel.org/stable/c/36ec108b7bd7e280edb22de028467bd09d644620
- https://git.kernel.org/stable/c/4d497e8b200a175094e0ac252ed878add39b8771
- https://git.kernel.org/stable/c/63551e4b7cbcd9914258827699eb2cb6ed6e4a16
- https://git.kernel.org/stable/c/9477db935eb690f697d9bcc4f608927841bc8b36
- https://git.kernel.org/stable/c/ae849d2f48019ff9c104e32bf588ccbfb200e971
- https://git.kernel.org/stable/c/cc4d0d4251748a8a68026938f4055d2ac47c5719
Modified: 2026-01-14
CVE-2023-53388
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Clean dangling pointer on bind error path mtk_drm_bind() can fail, in which case drm_dev_put() is called, destroying the drm_device object. However a pointer to it was still being held in the private object, and that pointer would be passed along to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that point, resulting in a panic. Clean the pointer when destroying the object in the error path to prevent this from happening.
- https://git.kernel.org/stable/c/36aa8c61af55675ed967900fbe5deb32d776f051
- https://git.kernel.org/stable/c/49cf87919daeeeeeb9e924c39bdd9203af434461
- https://git.kernel.org/stable/c/6a89ddee1686a8872384aaa9f0bcfa6b675acd86
- https://git.kernel.org/stable/c/7b551a501fa714890e55bae73efede1185728d72
- https://git.kernel.org/stable/c/9a48f99aa7bea15e0b1d8b0040c46b4792eddf3b
- https://git.kernel.org/stable/c/a161f1d92aabb3b8463f752bdc3474dc3a5ec0e5
- https://git.kernel.org/stable/c/f3887c771576c5d740c5c5b8bf654a8ab8020b7d
Modified: 2026-01-14
CVE-2023-53411
In the Linux kernel, the following vulnerability has been resolved: PM: EM: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
- https://git.kernel.org/stable/c/30fee10192e1239478a0987bc7ee445d5e980d46
- https://git.kernel.org/stable/c/5100c4efc30636aa48ac517dece3c3b7f84fe367
- https://git.kernel.org/stable/c/84e4d4885d0ae011860fb599d50d01b8fdca2b87
- https://git.kernel.org/stable/c/a0e8c13ccd6a9a636d27353da62c2410c4eca337
- https://git.kernel.org/stable/c/e974e8f1e37d22c0de07374f8ddc84073fef2f1d
Modified: 2026-01-14
CVE-2023-53423
In the Linux kernel, the following vulnerability has been resolved: objtool: Fix memory leak in create_static_call_sections() strdup() allocates memory for key_name. We need to release the memory in the following error paths. Add free() to avoid memory leak.
- https://git.kernel.org/stable/c/3a75866a5ceff5d4fdd5471e06c4c4d03e0298b3
- https://git.kernel.org/stable/c/3da73f102309fe29150e5c35acd20dd82063ff67
- https://git.kernel.org/stable/c/a1368eaea058e451d20ea99ca27e72d9df0d16dd
- https://git.kernel.org/stable/c/a8f63d747bf7c983882a5ea7456a5f84ad3acad5
- https://git.kernel.org/stable/c/d131718d9c45d559951f57c4b88209ca407433c4
Modified: 2026-01-14
CVE-2023-53427
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix warning and UAF when destroy the MR list
If the MR allocate failed, the MR recovery work not initialized
and list not cleared. Then will be warning and UAF when release
the MR:
WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110
CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82
RIP: 0010:__flush_work.isra.0+0xf7/0x110
Call Trace:
- https://git.kernel.org/stable/c/275a3d2b9408fc4895e342f772cab9a89960546e
- https://git.kernel.org/stable/c/2d0c4f5f618f58eba03385363717703bee873c64
- https://git.kernel.org/stable/c/3524d6da0fe88aee79f06be6572955d16ad76b39
- https://git.kernel.org/stable/c/3e161c2791f8e661eed24a2c624087084d910215
- https://git.kernel.org/stable/c/41832c62a75dad530dc5a2856c92ae5459d497e5
- https://git.kernel.org/stable/c/7cbd5bdb5bd4404a5da4309521134b42c65846c0
- https://git.kernel.org/stable/c/cfd85a0922c4696d768965e686ad805a58d9d834
Modified: 2026-01-14
CVE-2023-53437
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Handle cameras with invalid descriptors If the source entity does not contain any pads, do not create a link.
- https://git.kernel.org/stable/c/11196ee3916e50a5da3c1e6ecda19a02dca14ba3
- https://git.kernel.org/stable/c/1a76cfc388cf105d3e04ac592670a52a3864b1ba
- https://git.kernel.org/stable/c/2914259fcea23971c6fed8b2618d3a729a78c365
- https://git.kernel.org/stable/c/31a8d11d28b57656cebfbd4c0b8b76f6ad5b017d
- https://git.kernel.org/stable/c/41ddb251c68ac75c101d3a50a68c4629c9055e4c
- https://git.kernel.org/stable/c/4e4e6ca62e77539d4df8d13137e2683b10baddd9
- https://git.kernel.org/stable/c/c8f4a424af5879baefb0fb8a8a09b09ea1779483
- https://git.kernel.org/stable/c/d8aa2e1ae6426d7cbddf1735aed1a63ddf0e6909
Modified: 2026-01-14
CVE-2023-53443
In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get() as pm_runtime_get_sync() will increase the refcnt even when it returns an error.
- https://git.kernel.org/stable/c/4414a7ab80cebf715045e3c4d465feefbad21139
- https://git.kernel.org/stable/c/5a47bb71b1a94a279144fc3031d3c4591b38dd16
- https://git.kernel.org/stable/c/7195e642b49af60d4120fa1b45bd812ba528174f
- https://git.kernel.org/stable/c/754e81ff44061dda68da0fd4ef51bd1aa9fbf2cf
- https://git.kernel.org/stable/c/9893771097b22a8743a446e45994a177795ca4da
- https://git.kernel.org/stable/c/dc9437e9889c3dacf1f320e3cf08da74127573fe
Modified: 2026-01-16
CVE-2023-53449
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential memleak in dasd_eckd_init() `dasd_reserve_req` is allocated before `dasd_vol_info_req`, and it also needs to be freed before the error returns, just like the other cases in this function.
- https://git.kernel.org/stable/c/460e9bed82e49db1b823dcb4e421783854d86c40
- https://git.kernel.org/stable/c/544a552be0869231799784279d52704c4d314d33
- https://git.kernel.org/stable/c/a50e28d433acf22258f9f34831057387f04ef074
- https://git.kernel.org/stable/c/aede5230d154b6b237985ec9df7ebbd1dce96810
- https://git.kernel.org/stable/c/ee986d80acdef710a886be404308188ea11000c8
- https://git.kernel.org/stable/c/ef3a7ffc0a6f833578bc8d1dcb79d0633c7e4ec3
Modified: 2026-01-16
CVE-2023-53453
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: free iio for atombios when driver shutdown Fix below kmemleak when unload radeon driver: unreferenced object 0xffff9f8608ede200 (size 512): comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s) hex dump (first 32 bytes): 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500 [<00000000b6883cea>] atom_parse+0x117/0x230 [radeon] [<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon] [<00000000683f672e>] si_init+0x57/0x750 [radeon] [<00000000566cc31f>] radeon_device_init+0x559/0x9c0 [radeon] [<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon] [<00000000b5155064>] drm_dev_register+0xdd/0x1d0 [<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon] [<00000000e69ecca3>] pci_device_probe+0xe1/0x160 [<0000000019484b76>] really_probe.part.0+0xc1/0x2c0 [<000000003f2649da>] __driver_probe_device+0x96/0x130 [<00000000231c5bb1>] driver_probe_device+0x24/0xf0 [<0000000000a42377>] __driver_attach+0x77/0x190 [<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0 [<00000000633166d2>] driver_attach+0x1e/0x30 [<00000000313b05b8>] bus_add_driver+0x12c/0x1e0 iio was allocated in atom_index_iio() called by atom_parse(), but it doesn't got released when the dirver is shutdown. Fix this kmemleak by free it in radeon_atombios_fini().
- https://git.kernel.org/stable/c/107b8b542bb9dab4cbdc3276c85fbdd7f6782313
- https://git.kernel.org/stable/c/4773fadedca918faec443daaca5e4ea1c0ced144
- https://git.kernel.org/stable/c/9cdb96b55651c92fc949cfd54124406c3c912b6b
- https://git.kernel.org/stable/c/cb109cedbba11c33473e6780c256d8442a9e4460
- https://git.kernel.org/stable/c/cda2f7efbc2d857220dad32e315a54565b285c1c
- https://git.kernel.org/stable/c/ce9e9d3dcbb0d1551ffd1a7f16e7c051f3ba4140
- https://git.kernel.org/stable/c/e2791f2f4d1d804e45fa91b14295c326b64c65f1
- https://git.kernel.org/stable/c/f9f55fc64928b5e30d78f861c5fc76db9e769ebb
Modified: 2026-01-20
CVE-2023-53468
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix memory leak in alloc_wbufs()
kmemleak reported a sequence of memory leaks, and show them as following:
unreferenced object 0xffff8881575f8400 (size 1024):
comm "mount", pid 19625, jiffies 4297119604 (age 20.383s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/1f206002c6bc302bface871ef3f72c0bbcaa931c
- https://git.kernel.org/stable/c/26ec45f1c504e15268383019df139d7983f1e67f
- https://git.kernel.org/stable/c/3e29634eb56e6547272fe4e568f63421f8b3b9fa
- https://git.kernel.org/stable/c/4a1ff3c5d04b9079b4f768d9a71b51c4af578dd2
- https://git.kernel.org/stable/c/bf50229494f0443b3f08427d7df63e5a7e2a796a
- https://git.kernel.org/stable/c/e11f36d3bc4d23f620754a948fe7b82b63dcb185
Modified: 2026-01-20
CVE-2023-53477
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Add lwtunnel encap size of all siblings in nexthop calculation
In function rt6_nlmsg_size(), the length of nexthop is calculated
by multipling the nexthop length of fib6_info and the number of
siblings. However if the fib6_info has no lwtunnel but the siblings
have lwtunnels, the nexthop length is less than it should be, and
it will trigger a warning in inet6_rt_notify() as follows:
WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130
......
Call Trace:
- https://git.kernel.org/stable/c/4cc59f386991ec9374cb4bc83dbe1c0b5a95033f
- https://git.kernel.org/stable/c/aa75d826c221e8d48607aef33836cf872a159cf1
- https://git.kernel.org/stable/c/aba298b35619213ca787d08d472049627d8cd012
- https://git.kernel.org/stable/c/da26369377f0b671c14692e2d65ceb38131053e1
- https://git.kernel.org/stable/c/dcdddb5f490890d058ea1f194d661219e92fe88d
- https://git.kernel.org/stable/c/e11e4d524eba2d3c8fdf897d7ce3853f7573bae9
Modified: 2026-01-20
CVE-2023-53481
In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed Following process will trigger an infinite loop in ubi_wl_put_peb(): ubifs_bgt ubi_bgt ubifs_leb_unmap ubi_leb_unmap ubi_eba_unmap_leb ubi_wl_put_peb wear_leveling_worker e1 = rb_entry(rb_first(&ubi->used) e2 = get_peb_for_wl(ubi) ubi_io_read_vid_hdr // return err (flash fault) out_error: ubi->move_from = ubi->move_to = NULL wl_entry_destroy(ubi, e1) ubi->lookuptbl[e->pnum] = NULL retry: e = ubi->lookuptbl[pnum]; // return NULL if (e == ubi->move_from) { // NULL == NULL gets true goto retry; // infinite loop !!! $ top PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND 7676 root 20 0 0 0 0 R 100.0 0.0 ubifs_bgt0_0 Fix it by: 1) Letting ubi_wl_put_peb() returns directly if wearl leveling entry has been removed from 'ubi->lookuptbl'. 2) Using 'ubi->wl_lock' protecting wl entry deletion to preventing an use-after-free problem for wl entry in ubi_wl_put_peb(). Fetch a reproducer in [Link].
- https://git.kernel.org/stable/c/3afaaf6f5867dc4ad383808d4053f428ec7b867d
- https://git.kernel.org/stable/c/4d57a7333e26040f2b583983e1970d9d460e56b0
- https://git.kernel.org/stable/c/5af1c643184a5d09ff5b3f334077a4d0a163c677
- https://git.kernel.org/stable/c/8a18856e074479bd050b01e688c58defadce7ab0
- https://git.kernel.org/stable/c/b40d2fbf47af58377e898b5062077a47bb28a132
- https://git.kernel.org/stable/c/b5be23f6ae610bdb262160a1f294afee6d0e6a69
- https://git.kernel.org/stable/c/cc4bc532acda66189bddc03b3fe1ad689d9a48a2
- https://git.kernel.org/stable/c/f006f596fe851c3b6aae60b79f89f89f0e515d2f
Modified: 2026-01-16
CVE-2023-53494
In the Linux kernel, the following vulnerability has been resolved: crypto: xts - Handle EBUSY correctly As it is xts only handles the special return value of EINPROGRESS, which means that in all other cases it will free data related to the request. However, as the caller of xts may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.
- https://git.kernel.org/stable/c/51c082514c2dedf2711c99d93c196cc4eedceb40
- https://git.kernel.org/stable/c/57c3e1d63b63dc0841d41df729297cd7c1c35808
- https://git.kernel.org/stable/c/912eb10b65646ffd222256c78a1c566a3dac177d
- https://git.kernel.org/stable/c/92a07ba4f0af2cccdc2aa5ee32679c9c9714db90
- https://git.kernel.org/stable/c/d5870848879291700fe6c5257dcb48aadd10425c
Modified: 2026-01-23
CVE-2023-53506
In the Linux kernel, the following vulnerability has been resolved: udf: Do not bother merging very long extents When merging very long extents we try to push as much length as possible to the first extent. However this is unnecessarily complicated and not really worth the trouble. Furthermore there was a bug in the logic resulting in corrupting extents in the file as syzbot reproducer shows. So just don't bother with the merging of extents that are too long together.
- https://git.kernel.org/stable/c/3d20e3b768aff32112bdce8d3219d923ae75f9f1
- https://git.kernel.org/stable/c/53cafe1d6d8ef9f93318e5bfccc0d24f27d41ced
- https://git.kernel.org/stable/c/5d029799d381a9ee06209a222cae75f04c5d5304
- https://git.kernel.org/stable/c/7a965da79f2d22601f329cbfce588386b0847544
- https://git.kernel.org/stable/c/965982feb333aefa9256c0fe188b5f1b958aef63
- https://git.kernel.org/stable/c/9a8d602f0723586e668bae7e65c832ceb9bcc8bc
- https://git.kernel.org/stable/c/adac9ac6d2e04ea0782b91a00ba10706002f3ec4
- https://git.kernel.org/stable/c/d52252a1de4cf96a34f722b0cd8902d8ff78eb57
Modified: 2026-01-23
CVE-2023-53512
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix a memory leak Add a forgotten kfree().
- https://git.kernel.org/stable/c/28137ea3eb05a87329a7154a8ff410d9e8bcc0a5
- https://git.kernel.org/stable/c/30c7c72b6cf9d8c95f9b219c9d2e4e31b15bebe5
- https://git.kernel.org/stable/c/378cc0eec4aa546ce1ae17515e2dfab719d4fb1e
- https://git.kernel.org/stable/c/54dd96015e8d7a2a07359e2dfebf05b529d1780c
- https://git.kernel.org/stable/c/847cdbdcd5a24c1eec9595161a23b88fef91ff42
Modified: 2026-04-06
CVE-2023-53521
In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Fix slab-out-of-bounds in ses_intf_remove() A fix for: BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses] Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013 When edev->components is zero, accessing edev->component[0] members is wrong.
- https://git.kernel.org/stable/c/0595cdb587726b4f0fa780eb7462e3679d141e82
- https://git.kernel.org/stable/c/2fb1fa8425cce2dc4dce298275d22d7077694b73
- https://git.kernel.org/stable/c/40af9a6deed723485e05b7d3255a28750692e8db
- https://git.kernel.org/stable/c/578797f0c8cbc2e3ec5fc0dab87087b4c7073686
- https://git.kernel.org/stable/c/76f7050537476ac062ec23a544fbca8270f2d08b
- https://git.kernel.org/stable/c/82143faf01dda831b89eccef60c39ef8575ab08a
- https://git.kernel.org/stable/c/87e47be38d205df338c52ead43f23b2864567423
- https://git.kernel.org/stable/c/8f9542cad6c27297c8391de3a659f0b7948495d0
Modified: 2026-03-25
CVE-2023-53534
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: mtk_drm_crtc: Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference.
- https://git.kernel.org/stable/c/5bf1e3bd7da625ccf9a22c8cb7d65271e6e47f4c
- https://git.kernel.org/stable/c/62952905e195f7350bc230cf0960a74ddbceed5d
- https://git.kernel.org/stable/c/67ea657c7891c2f86a7750395640d9bdf2555926
- https://git.kernel.org/stable/c/7d569ae98ee5490585929be69fea68047679b7b2
- https://git.kernel.org/stable/c/b64b6dff15a38468b8cd33fc7864fa4e02b0933a
Modified: 2026-03-23
CVE-2023-53535
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Add a check for oversized packets Occasionnaly we may get oversized packets from the hardware which exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early check which drops the packet to avoid invoking skb_over_panic() and move on to processing the next packet.
- https://git.kernel.org/stable/c/124ca24e0de958d2e20e0aa1e2434af7b72f8887
- https://git.kernel.org/stable/c/411317d2a4a7d6049d8efeef0d32ae43f8baefce
- https://git.kernel.org/stable/c/5c0862c2c962052ed5055220a00ac1cefb92fbcd
- https://git.kernel.org/stable/c/5f56767fb5f2df875b6553e08dbec6a45431c988
- https://git.kernel.org/stable/c/7cdb07e10c1258c08f31b24898930e4ece88d163
- https://git.kernel.org/stable/c/841881320562cbeac7046b537b91cd000480cea2
- https://git.kernel.org/stable/c/87363d1ab55e497702a9506ff423c422639c8a25
- https://git.kernel.org/stable/c/c34b1c0870323649d45c5074828d7f754dea2673
Modified: 2026-03-21
CVE-2023-53542
In the Linux kernel, the following vulnerability has been resolved: ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy For some reason, the driver adding support for Exynos5420 MIPI phy back in 2016 wasn't used on Exynos5420, which caused a kernel panic. Add the proper compatible for it.
- https://git.kernel.org/stable/c/199624f3144d79fab1cff533ce6a4b82390520a3
- https://git.kernel.org/stable/c/29961ee63dd676cc67f7c00f76faa21e11f0d7c6
- https://git.kernel.org/stable/c/2e68a0f7bc576318a58335c31c542b358bc63f83
- https://git.kernel.org/stable/c/537bdfc1a67836fbd68bbe4210bc380f72cca47f
- https://git.kernel.org/stable/c/5d5aa219a790d61cad2c38e1aa32058f16ad2f0b
- https://git.kernel.org/stable/c/c075aa3467a799855a92289a3c619afc0a2ad193
- https://git.kernel.org/stable/c/f10001af0f7246cf3e43530d25f8d59a8db10df6
- https://git.kernel.org/stable/c/f2a6198f5ed7d6e4e06d87a4de007f2e45cc9583
Modified: 2026-03-21
CVE-2023-53551
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Add null pointer check in gserial_resume Consider a case where gserial_disconnect has already cleared gser->ioport. And if a wakeup interrupt triggers afterwards, gserial_resume gets called, which will lead to accessing of gser->ioport and thus causing null pointer dereference.Add a null pointer check to prevent this. Added a static spinlock to prevent gser->ioport from becoming null after the newly added check.
- https://git.kernel.org/stable/c/3b24c980dc07be4550a9d1450ed7057f882530e5
- https://git.kernel.org/stable/c/44e004f757a7ae13dfebaadbcfdb1a6f98c10377
- https://git.kernel.org/stable/c/5ec63fdbca604568890c577753c6f66c5b3ef0b5
- https://git.kernel.org/stable/c/c5360eec648bd506afa304ae4a71f82e13d41897
- https://git.kernel.org/stable/c/ec357cd3e8af614855d286dd378725cdc7264df6
Modified: 2026-03-21
CVE-2023-53564
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix defrag path triggering jbd2 ASSERT code path: ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERT crash stacks: PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2] Analysis This bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: call ocfs2_journal_access_di() before ocfs2_journal_dirty() in ocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is called by ocfs2_split_extent() during defragmenting. How to fix For ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller only needs to call journal start/stop pair. The fix method is to remove journal access/dirty from __ocfs2_move_extent(). The discussion for this patch: https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
- https://git.kernel.org/stable/c/2c559b3ba8e0b9e3c4bb08159a28ccadc698410f
- https://git.kernel.org/stable/c/33665d1042666f2e5c736a3df1f453e31f030663
- https://git.kernel.org/stable/c/590507ebabd33cd93324c04f9a5538309a5ba934
- https://git.kernel.org/stable/c/5f43d34a51ed30e6a60f7e59d224a63014fe2cd5
- https://git.kernel.org/stable/c/60eed1e3d45045623e46944ebc7c42c30a4350f0
- https://git.kernel.org/stable/c/669134a66d37258e1c4a5cfbd5b82f547ae30fca
- https://git.kernel.org/stable/c/7f3b1c28e2908755fb248d3ee8ff56826f2387db
- https://git.kernel.org/stable/c/8163ea90d89b7012dd1fa4b28edf5db0c641eca7
Modified: 2026-03-23
CVE-2023-53582
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds Fix a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with a CLM version string by memcpy() in brcmf_fil_iovar_data_get(). Ensure buf is null-terminated. Found by a modified version of syzkaller. [ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22 [ 33.021554][ T1896] ================================================================== [ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110 [ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896 [ 33.023852][ T1896] [ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 [ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event [ 33.026581][ T1896] Call Trace: [ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d [ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334 [ 33.028037][ T1896] ? strreplace+0xf2/0x110 [ 33.028403][ T1896] ? strreplace+0xf2/0x110 [ 33.028807][ T1896] kasan_report.cold+0x83/0xdf [ 33.029283][ T1896] ? strreplace+0xf2/0x110 [ 33.029666][ T1896] strreplace+0xf2/0x110 [ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40 [ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0 [ 33.032091][ T1896] ? find_held_lock+0x2d/0x110 [ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260 [ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 33.033582][ T1896] brcmf_attach+0x246/0xd40 [ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50 [ 33.034383][ T1896] ? kmemdup+0x30/0x40 [ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690 [ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 33.035833][ T1896] usb_probe_interface+0x25f/0x710 [ 33.036315][ T1896] really_probe+0x1be/0xa90 [ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460 [ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0 [ 33.037383][ T1896] driver_probe_device+0x49/0x120 [ 33.037790][ T1896] __device_attach_driver+0x18a/0x250 [ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120 [ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0 [ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20 [ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120 [ 33.042330][ T1896] __device_attach+0x207/0x330 [ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0 [ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0 [ 33.043515][ T1896] bus_probe_device+0x1a2/0x260 [ 33.043914][ T1896] device_add+0xa61/0x1ce0 [ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660 [ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550 [ 33.045531][ T1896] usb_set_configuration+0x984/0x1770 [ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230 [ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90 [ 33.046931][ T1896] usb_probe_device+0x9c/0x220 [ 33.047434][ T1896] really_probe+0x1be/0xa90 [ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460 [ 33.048134][ T1896] driver_probe_device+0x49/0x120 [ 33.048516][ T1896] __device_attach_driver+0x18a/0x250 [ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120 ---truncated---
- https://git.kernel.org/stable/c/0ca2efea4f11c6255061e852ac188264c469c197
- https://git.kernel.org/stable/c/3b173b4ad9c001a555f44adc7836d6fe3afbe9ec
- https://git.kernel.org/stable/c/423a1297ea72bbddf64dbb0957f2879c0f2aa5d0
- https://git.kernel.org/stable/c/660145d708be52f946a82e5b633c020f58f996de
- https://git.kernel.org/stable/c/a0f0ce1c8ab9fe90618dc394e3d1568b5a9ac154
- https://git.kernel.org/stable/c/c02f733024d70105f22de8dd0a1252a0350cd516
- https://git.kernel.org/stable/c/ecb980dc79709c02f579a9c03cb92ccec189ab38
Modified: 2026-03-21
CVE-2023-53590
In the Linux kernel, the following vulnerability has been resolved:
sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop
With this refcnt added in sctp_stream_priorities, we don't need to
traverse all streams to check if the prio is used by other streams
when freeing one stream's prio in sctp_sched_prio_free_sid(). This
can avoid a nested loop (up to 65535 * 65535), which may cause a
stuck as Ying reported:
watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]
Call Trace:
- https://git.kernel.org/stable/c/03c3a5584a0a29821e59b7834635ce823050caaa
- https://git.kernel.org/stable/c/68ba44639537de6f91fe32783766322d41848127
- https://git.kernel.org/stable/c/6d529928ea212127851a2df8c40d822237ca946b
- https://git.kernel.org/stable/c/8ee401f89cdb10f39098c0656d695b2bc4052100
- https://git.kernel.org/stable/c/bf5540cbd20e2dae2c81ab9b31deef41ef147d0a
- https://git.kernel.org/stable/c/cec326443f01283ef68ea00c06ea073b1835a562
Modified: 2026-03-23
CVE-2023-53605
In the Linux kernel, the following vulnerability has been resolved: drm: amd: display: Fix memory leakage This commit fixes memory leakage in dc_construct_ctx() function.
- https://git.kernel.org/stable/c/1bdea8ee92a6abc650b2189fd5c53f36859baecb
- https://git.kernel.org/stable/c/6b8701be1f66064ca72733c5f6e13748cdbf8397
- https://git.kernel.org/stable/c/83ace0dd67ee386be1ddcf59dab49d6d9a54e62e
- https://git.kernel.org/stable/c/9ae15ebaefc4878d614f10cc56ea672f88cea582
- https://git.kernel.org/stable/c/d473c55ce1975c9e601c25293328a5039225d2b2
Modified: 2026-03-17
CVE-2023-53610
In the Linux kernel, the following vulnerability has been resolved: irqchip: Fix refcount leak in platform_irqchip_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/4401b485855700f296cae4d0db36a52948bff4fa
- https://git.kernel.org/stable/c/6caa5a2b78f5f53c433d3a3781e53325da22f0ac
- https://git.kernel.org/stable/c/b00baffcc2561374f8fe8af873d00531f19864eb
- https://git.kernel.org/stable/c/c32fb16331f612e66a7fa8930164e0dc15725b72
- https://git.kernel.org/stable/c/ea54b608d85b7536f92238f3259730fa06cb5d21
Modified: 2026-03-17
CVE-2023-53612
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Simplify platform device handling Coretemp's platform driver is unconventional. All the real work is done globally by the initcall and CPU hotplug notifiers, while the "driver" effectively just wraps an allocation and the registration of the hwmon interface in a long-winded round-trip through the driver core. The whole logic of dynamically creating and destroying platform devices to bring the interfaces up and down is error prone, since it assumes platform_device_add() will synchronously bind the driver and set drvdata before it returns, thus results in a NULL dereference if drivers_autoprobe is turned off for the platform bus. Furthermore, the unusual approach of doing that from within a CPU hotplug notifier, already commented in the code that it deadlocks suspend, also causes lockdep issues for other drivers or subsystems which may want to legitimately register a CPU hotplug notifier from a platform bus notifier. All of these issues can be solved by ripping this unusual behaviour out completely, simply tying the platform devices to the lifetime of the module itself, and directly managing the hwmon interfaces from the hotplug notifiers. There is a slight user-visible change in that /sys/bus/platform/drivers/coretemp will no longer appear, and /sys/devices/platform/coretemp.n will remain present if package n is hotplugged off, but hwmon users should really only be looking for the presence of the hwmon interfaces, whose behaviour remains unchanged.
- https://git.kernel.org/stable/c/4000384684f612b3645a944f6acde0e65ac370b8
- https://git.kernel.org/stable/c/52ea47a0ddfbc5fe05e873d3f5a59db4ba3e03fe
- https://git.kernel.org/stable/c/5735878a7b7db7e9ce731cb36cec298a9de67549
- https://git.kernel.org/stable/c/6d03bbff456befeccdd4d663177c4d6c75d0c4ff
- https://git.kernel.org/stable/c/8fcdbc4bc01365f4b10fed7db544a3149e3054fd
- https://git.kernel.org/stable/c/c57a8d14d7880521150ee801d53a0a64fdffd9c8
Modified: 2026-02-03
CVE-2023-53637
In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov772x: Fix memleak in ov772x_probe() A memory leak was reported when testing ov772x with bpf mock device: AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() are leaked.
- https://git.kernel.org/stable/c/1da495101ef7507eb4f4b1dbec2874d740eff251
- https://git.kernel.org/stable/c/448ce1cd50387b1345ec14eb191ef05f7afc2a26
- https://git.kernel.org/stable/c/7485edb2b6ca5960205c0a49bedfd09bba30e521
- https://git.kernel.org/stable/c/ac93f8ac66e60227bed42d5a023f0e6c15b52c0a
- https://git.kernel.org/stable/c/c86d760c1c6855a6131e78d0ddacc48c79324ac3
- https://git.kernel.org/stable/c/cc3b6011d7a9f149489eb9420c6305a779162c57
- https://git.kernel.org/stable/c/dfaafeb8e9537969e8dba75491f732478c7fa9d6
Modified: 2026-02-26
CVE-2023-53675
In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Fix possible desc_ptr out-of-bounds accesses Sanitize possible desc_ptr out-of-bounds accesses in ses_enclosure_data_process().
- https://git.kernel.org/stable/c/414418abc19fa4ccf730d273061a426c07a061d6
- https://git.kernel.org/stable/c/4b8cae410472653a59e15af62c57c49b8e0a1201
- https://git.kernel.org/stable/c/584892fd29a41ef424a148118a3103b16b94fb8c
- https://git.kernel.org/stable/c/72021ae61a2bc6ca73cd593e255a10ed5f5dc5e7
- https://git.kernel.org/stable/c/79ec5dd5fb07ecaea2f978c2d7a9f2f3526e4d19
- https://git.kernel.org/stable/c/801ab13d50cf3d26170ee073ea8bb4eececb76ab
- https://git.kernel.org/stable/c/c315560e3ef77c1d822249f1743e647dc9c9912a
- https://git.kernel.org/stable/c/cffe09ca0555e235a42d6fa065e463c4b3d5b657
Modified: 2026-02-26
CVE-2023-53679
In the Linux kernel, the following vulnerability has been resolved: wifi: mt7601u: fix an integer underflow Fix an integer underflow that leads to a null pointer dereference in 'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet could be manipulated, which could trigger an integer underflow of 'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be bypassed, eventually leading to a dereference of the pointer 'p', which is a null pointer. Ensure that 'dma_len' is greater than 'min_seg_len'. Found by a modified version of syzkaller. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+ #139 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 RIP: 0010:skb_add_rx_frag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: mt7601u_rx_tasklet+0xc73/0x1270 ? mt7601u_submit_rx_buf.isra.0+0x510/0x510 ? tasklet_action_common.isra.0+0x79/0x2f0 tasklet_action_common.isra.0+0x206/0x2f0 __do_softirq+0x1b5/0x880 ? tasklet_unlock+0x30/0x30 run_ksoftirqd+0x26/0x50 smpboot_thread_fn+0x34f/0x7d0 ? smpboot_register_percpu_thread+0x370/0x370 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30 Modules linked in: 88XXau(O) 88x2bu(O) ---[ end trace 57f34f93b4da0f9b ]--- RIP: 0010:skb_add_rx_frag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554
- https://git.kernel.org/stable/c/1a1f43059afae5cc9409e0c3bc63bfc09bc8facb
- https://git.kernel.org/stable/c/47dc1f425af57b71111d7b01ebd24e04e8d967ef
- https://git.kernel.org/stable/c/61d0163e2be7a439cf6f82e9ad7de563ecf41e7a
- https://git.kernel.org/stable/c/67e4519afba215199b6dfa39ce5d7ea673ee4138
- https://git.kernel.org/stable/c/803f3176c5df3b5582c27ea690f204abb60b19b9
- https://git.kernel.org/stable/c/d0db59e2f718d1e2f1d2a2d8092168fdd2f3add0
