ALT-BU-2023-3902-20
Branch p10 update bulletin.
Package firefox-esr updated to version 102.12.0-alt1 for branch p10 in task 322595.
Closed vulnerabilities
Modified: 2024-09-30
BDU:2023-03125
Уязвимость браузеров Mozilla Firefox и Firefox ESR, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2023-03196
Уязвимость браузеров Mozilla Firefox, Firefox ESR и почтового клиента Thunderbird, связанная с неверным ограничением визуализируемых слоев пользовательского интерфейса, позволяющая нарушителю провести атаку типа clickjacking («захват клика»)
Modified: 2024-11-21
CVE-2023-34414
The error page for sites with invalid TLS certificates was missing the activation-delay Firefox uses to protect prompts and permission dialogs from attacks that exploit human response time delays. If a malicious page elicited user clicks in precise locations immediately before navigating to a site with a certificate error and made the renderer extremely busy at the same time, it could create a gap between when the error page was loaded and when the display actually refreshed. With the right timing the elicited clicks could land in that gap and activate the button that overrides the certificate error for that site. This vulnerability affects Firefox ESR < 102.12, Firefox < 114, and Thunderbird < 102.12.
- https://bugzilla.mozilla.org/show_bug.cgi?id=1695986
- https://security.gentoo.org/glsa/202312-03
- https://security.gentoo.org/glsa/202401-10
- https://www.mozilla.org/security/advisories/mfsa2023-19/
- https://www.mozilla.org/security/advisories/mfsa2023-20/
- https://www.mozilla.org/security/advisories/mfsa2023-21/
- https://bugzilla.mozilla.org/show_bug.cgi?id=1695986
- https://security.gentoo.org/glsa/202312-03
- https://security.gentoo.org/glsa/202401-10
- https://www.mozilla.org/security/advisories/mfsa2023-19/
- https://www.mozilla.org/security/advisories/mfsa2023-20/
- https://www.mozilla.org/security/advisories/mfsa2023-21/
Modified: 2025-02-13
CVE-2023-34416
Memory safety bugs present in Firefox 113, Firefox ESR 102.11, and Thunderbird 102.12. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR < 102.12, Firefox < 114, and Thunderbird < 102.12.
- https://bugzilla.mozilla.org/buglist.cgi?bug_id=1752703%2C1818394%2C1826875%2C1827340%2C1827655%2C1828065%2C1830190%2C1830206%2C1830795%2C1833339
- https://security.gentoo.org/glsa/202312-03
- https://security.gentoo.org/glsa/202401-10
- https://www.mozilla.org/security/advisories/mfsa2023-19/
- https://www.mozilla.org/security/advisories/mfsa2023-20/
- https://www.mozilla.org/security/advisories/mfsa2023-21/
- https://bugzilla.mozilla.org/buglist.cgi?bug_id=1752703%2C1818394%2C1826875%2C1827340%2C1827655%2C1828065%2C1830190%2C1830206%2C1830795%2C1833339
- https://security.gentoo.org/glsa/202312-03
- https://security.gentoo.org/glsa/202401-10
- https://www.mozilla.org/security/advisories/mfsa2023-19/
- https://www.mozilla.org/security/advisories/mfsa2023-20/
- https://www.mozilla.org/security/advisories/mfsa2023-21/
Package kernel-image-std-def updated to version 5.10.182-alt1 for branch p10 in task 322473.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2023-01281
Уязвимость функции brcmf_get_assoc_ies() драйвера drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02625
Уязвимость функции nf_tables_commit() в модуле net/netfilter/nf_tables_api.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных или повысить свои привилегии в системе и выполнить произвольный код
Modified: 2025-08-19
BDU:2023-02738
Уязвимость функции kvm_steal_time_set_preempted() в модуле arch/x86/kvm/x86.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-08-19
BDU:2023-03172
Уязвимость функции r592_remove() в модуле drivers/memstick/host/r592.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2025-02-27
BDU:2023-03444
Уязвимость функции rkvdec_remove() в модуле drivers/staging/media/rkvdec/rkvdec.c драйвера Rockchip Video Decoder ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-02-27
BDU:2023-03501
Уязвимость функции renesas_usb3_remove() в модуле drivers/usb/gadget/udc/renesas_usb3.c драйвера USB устройств Renesas ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2024-09-30
BDU:2023-03721
Уязвимость драйвера IPVLAN ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-02-11
BDU:2024-01694
Уязвимость функции user_sdma_txadd драйвера Infiniband ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
BDU:2025-12420
Уязвимость функции cas_init_one ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12822
Уязвимость функции ext4_get_group_info() в модуле fs/ext4/ext4.h файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12908
Уязвимость функции tipc_link_proto_rcv() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12985
Уязвимость функции vlan_get_protocol_and_depth() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16231
Уязвимость функции iwl_write_to_user_buf() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16298
Уязвимость модуля net/core/skbuff.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01417
Уязвимость функции usb_shark_probe() модуля drivers/media/radio/radio-shark.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01505
Уязвимость функции null_init_tag_set() модуля drivers/block/null_blk/main.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01633
Уязвимость функции gfx_v9_0_hw_fini() модуля drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02191
Уязвимость функции get_max_inline_xattr_value_size() в модуле fs/ext4/inline.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02261
Уязвимость функции brcmf_get_assoc_ies() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02282
Уязвимость функции l2cap_disconnect_rsp() модуля net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02515
Уязвимость функции recovery_request_write() модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03277
Уязвимость функций prepare_threshold_block(), amd_threshold_interrupt(), mce_threshold_create_device() модуля arch/x86/kernel/cpu/mce/amd.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03342
Уязвимость функций free_irq_cpu_rmap(), irq_cpu_rmap_release(), irq_cpu_rmap_add() модуля lib/cpu_rmap.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03350
Уязвимость функции ext4_validate_block_bitmap() модуля fs/ext4/balloc.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03795
Уязвимость функции iwl_dbgfs_fw_info_seq_next() модуля drivers/net/wireless/intel/iwlwifi/fw/debugfs.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03801
Уязвимость функции bdisp_probe() модуля drivers/media/platform/st/sti/bdisp/bdisp-v4l2.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03818
Уязвимость функции __rcu_irq_enter_check_tick() модуля kernel/rcu/tree.c подсистемы синхронизации в многопоточных системах ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03827
Уязвимость функции fq_resize() модуля net/sched/sch_fq.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03831
Уязвимость функции ath6kl_htc_pipe_rx_complete() модуля drivers/net/wireless/ath/ath6kl/htc_pipe.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03845
Уязвимость функции ath9k_hif_usb_alloc_tx_urbs() модуля drivers/net/wireless/ath/ath9k/hif_usb.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03948
Уязвимость функции fec_drv_remove() модуля drivers/net/ethernet/freescale/fec_main.c драйвера сетевых адаптеров Ethernet Freescale ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04118
Уязвимость функций hfsplus_cat_read_inode() и hfsplus_cat_write_inode() модуля fs/hfsplus/inode.c поддержки расширенной файловой системы Apple HFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04336
Уязвимость функции rpi_ts_probe() модуля drivers/input/touchscreen/raspberrypi-ts.c драйвера сенсорного экрана ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04417
Уязвимость функции spi_qup_remove() модуля drivers/spi/spi-qup.c драйвера устройств SPI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04421
Уязвимость функции iwl_mvm_update_mcc() модуля drivers/net/wireless/intel/iwlwifi/mvm/nvm.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04431
Уязвимость функции intel_get_crtc_new_encoder() модуля drivers/gpu/drm/i915/display/intel_display.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04442
Уязвимость функции dm_integrity_init() модуля drivers/md/dm-integrity.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04550
Уязвимость функции ext4_mb_release_group_pa() модуля fs/ext4/mballoc.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04610
Уязвимость функции uwrite() модуля scripts/recordmcount.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04614
Уязвимость функции ubifs_tmpfile() модуля fs/ubifs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04622
Уязвимость функции acpi_ds_init_aml_walk() модуля drivers/acpi/acpica/dswstate.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05740
Уязвимость функции serial8250_unregister_port() модуля drivers/tty/serial/8250/8250_core.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05876
Уязвимость компонента imx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05888
Уязвимость функции of_node_put() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05891
Уязвимость функции run_bpf_prog() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05892
Уязвимость функции b15_dma_inv_range() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05897
Уязвимость функции get_line_out_pfx() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05901
Уязвимость функции rcu_print_task_exp_stall() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-05
CVE-2022-39189
An issue was discovered the x86 KVM subsystem in the Linux kernel before 5.18.17. Unprivileged guest users can compromise the guest kernel because TLB flush operations are mishandled in certain KVM_VCPU_PREEMPTED situations.
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2309
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736
- https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230214-0007/
- https://www.debian.org/security/2023/dsa-5480
- https://bugs.chromium.org/p/project-zero/issues/detail?id=2309
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736
- https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230214-0007/
- https://www.debian.org/security/2023/dsa-5480
Modified: 2024-11-21
CVE-2023-1380
A slab-out-of-bound read problem was found in brcmf_get_assoc_ies in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when assoc_info->req_len data is bigger than the size of the buffer, defined as WL_EXTRA_BUF_MAX, leading to a denial of service.
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2177883
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/linux-wireless/20230309104457.22628-1-jisoo.jang%40yonsei.ac.kr/T/#u
- https://security.netapp.com/advisory/ntap-20230511-0001/
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/03/14/1
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2177883
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/linux-wireless/20230309104457.22628-1-jisoo.jang%40yonsei.ac.kr/T/#u
- https://security.netapp.com/advisory/ntap-20230511-0001/
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/03/14/1
Modified: 2025-02-13
CVE-2023-3090
A heap out-of-bounds write vulnerability in the Linux Kernel ipvlan network driver can be exploited to achieve local privilege escalation. The out-of-bounds write is caused by missing skb->cb initialization in the ipvlan network driver. The vulnerability is reachable if CONFIG_IPVLAN is enabled. We recommend upgrading past commit 90cbed5247439a966b645b34eb0a2e037836ea8e.
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbed5247439a966b645b34eb0a2e037836ea8e
- https://kernel.dance/90cbed5247439a966b645b34eb0a2e037836ea8e
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230731-0002/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbed5247439a966b645b34eb0a2e037836ea8e
- https://kernel.dance/90cbed5247439a966b645b34eb0a2e037836ea8e
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230731-0002/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
Modified: 2025-03-11
CVE-2023-3141
A use-after-free flaw was found in r592_remove in drivers/memstick/host/r592.c in media access in the Linux Kernel. This flaw allows a local attacker to crash the system at device disconnect, possibly leading to a kernel information leak.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63264422785021704c39b38f65a78ab9e4a186d7
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/lkml/CAPDyKFoV9aZObZ5GBm0U_-UVeVkBN_rAG-kH3BKoP4EXdYM4bw%40mail.gmail.com/t/
- https://security.netapp.com/advisory/ntap-20230706-0004/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63264422785021704c39b38f65a78ab9e4a186d7
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lore.kernel.org/lkml/CAPDyKFoV9aZObZ5GBm0U_-UVeVkBN_rAG-kH3BKoP4EXdYM4bw%40mail.gmail.com/t/
- https://security.netapp.com/advisory/ntap-20230706-0004/
Modified: 2025-05-05
CVE-2023-32233
In the Linux kernel through 6.3.1, a use-after-free in Netfilter nf_tables when processing batch requests can be abused to perform arbitrary read and write operations on kernel memory. Unprivileged local users can obtain root privileges. This occurs because anonymous sets are mishandled.
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://www.openwall.com/lists/oss-security/2023/05/15/5
- https://bugzilla.redhat.com/show_bug.cgi?id=2196105
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1592a89942e9678f7d9c8030efa777c0d57edab
- https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://news.ycombinator.com/item?id=35879660
- https://security.netapp.com/advisory/ntap-20230616-0002/
- https://www.debian.org/security/2023/dsa-5402
- https://www.openwall.com/lists/oss-security/2023/05/08/4
- http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html
- http://www.openwall.com/lists/oss-security/2023/05/15/5
- https://bugzilla.redhat.com/show_bug.cgi?id=2196105
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1592a89942e9678f7d9c8030efa777c0d57edab
- https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab
- https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://news.ycombinator.com/item?id=35879660
- https://security.netapp.com/advisory/ntap-20230616-0002/
- https://www.debian.org/security/2023/dsa-5402
- https://www.openwall.com/lists/oss-security/2023/05/08/4
Modified: 2024-11-21
CVE-2023-35828
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in renesas_usb3_remove in drivers/usb/gadget/udc/renesas_usb3.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au/
- https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au/
- https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
Modified: 2024-11-21
CVE-2023-35829
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in rkvdec_remove in drivers/staging/media/rkvdec/rkvdec.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3228cec23b8b29215e18090c6ba635840190993d
- https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/
- https://lore.kernel.org/lkml/20230307173900.1299387-1-zyytlz.wz%40163.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3228cec23b8b29215e18090c6ba635840190993d
- https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/
- https://lore.kernel.org/lkml/20230307173900.1299387-1-zyytlz.wz%40163.com/T/
- https://security.netapp.com/advisory/ntap-20230803-0002/
Modified: 2024-11-21
CVE-2023-52474
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request. Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3). 3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node could be evicted by another thread that gets mmu_rb_handler->lock and checks mmu_rb_node->refcount before mmu_rb_node->refcount is incremented. 4. Related to #2 above, SDMA request submission failure path does not check mmu_rb_node->refcount before freeing mmu_rb_node object. If there are other SDMA requests in progress whose iovecs have pointers to the now-freed mmu_rb_node(s), those pointers to the now-freed mmu_rb nodes will be dereferenced when those SDMA requests complete.
- https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127
- https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc
- https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d
- https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678
- https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80
- https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844
- https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127
- https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc
- https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d
- https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678
- https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80
- https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844
Modified: 2025-12-02
CVE-2023-53176
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Reinit port->pm on port specific driver unbind When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs: Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone: serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c Let's fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm.
- https://git.kernel.org/stable/c/04e82793f068d2f0ffe62fcea03d007a8cdc16a7
- https://git.kernel.org/stable/c/1ba5594739d858e524ff0f398ee1ebfe0a8b9d41
- https://git.kernel.org/stable/c/2c86a1305c1406f45ea780d06953c484ea1d9e6e
- https://git.kernel.org/stable/c/490bf37eaabb0a857ed1ae8e75d8854e41662f1c
- https://git.kernel.org/stable/c/8e596aed5f2f98cf3e6e98d6fe1d689f4a319308
- https://git.kernel.org/stable/c/af4d6dbb1a92ea424ad1ba1d0c88c7fa2345d872
- https://git.kernel.org/stable/c/c9e080c3005fd183c56ff8f4d75edb5da0765d2c
- https://git.kernel.org/stable/c/d5cd2928d31042a7c0a01464f9a8d95be736421d
Modified: 2025-12-02
CVE-2023-53182
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Avoid undefined behavior: applying zero offset to null pointer
ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e
Before this change we see the following UBSAN stack trace in Fuchsia:
#0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682
- https://git.kernel.org/stable/c/05bb0167c80b8f93c6a4e0451b7da9b96db990c2
- https://git.kernel.org/stable/c/16359bc02c093b0862e31739c07673340a2106a6
- https://git.kernel.org/stable/c/3048c6b84a51e4ba4a89385ed218d19a670edd47
- https://git.kernel.org/stable/c/35465c7a91c6b46e7c14d0c01d0084349a38ce51
- https://git.kernel.org/stable/c/3a7a4aa3958ce0c4938a443d65001debe9a9af9c
- https://git.kernel.org/stable/c/5a2d0dcb47b16f84880a59571eab8a004e3236d7
- https://git.kernel.org/stable/c/710e09fd116e2fa53e319a416ad4e4f8027682b6
- https://git.kernel.org/stable/c/8c4a7163b7f1495e3cc58bec7a4100de6612cde9
Modified: 2026-01-14
CVE-2023-53213
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() Fix a slab-out-of-bounds read that occurs in kmemdup() called from brcmf_get_assoc_ies(). The bug could occur when assoc_info->req_len, data from a URB provided by a USB device, is bigger than the size of buffer which is defined as WL_EXTRA_BUF_MAX. Add the size check for req_len/resp_len of assoc_info. Found by a modified version of syzkaller. [ 46.592467][ T7] ================================================================== [ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50 [ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7 [ 46.598575][ T7] [ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145 [ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker [ 46.605943][ T7] Call Trace: [ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1 [ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334 [ 46.608610][ T7] ? kmemdup+0x3e/0x50 [ 46.609341][ T7] kasan_report.cold+0x79/0xd5 [ 46.610151][ T7] ? kmemdup+0x3e/0x50 [ 46.610796][ T7] kasan_check_range+0x14e/0x1b0 [ 46.611691][ T7] memcpy+0x20/0x60 [ 46.612323][ T7] kmemdup+0x3e/0x50 [ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60 [ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0 [ 46.614831][ T7] ? lock_chain_count+0x20/0x20 [ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770 [ 46.616552][ T7] ? lock_chain_count+0x20/0x20 [ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770 [ 46.618244][ T7] ? lock_chain_count+0x20/0x20 [ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0 [ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0 [ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790 [ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950 [ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 [ 46.623390][ T7] ? find_held_lock+0x2d/0x110 [ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60 [ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0 [ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0 [ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0 [ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100 [ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60 [ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100 [ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 46.630649][ T7] process_one_work+0x92b/0x1460 [ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330 [ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90 [ 46.632347][ T7] worker_thread+0x95/0xe00 [ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0 [ 46.633393][ T7] ? process_one_work+0x1460/0x1460 [ 46.633957][ T7] kthread+0x3a1/0x480 [ 46.634369][ T7] ? set_kthread_struct+0x120/0x120 [ 46.634933][ T7] ret_from_fork+0x1f/0x30 [ 46.635431][ T7] [ 46.635687][ T7] Allocated by task 7: [ 46.636151][ T7] kasan_save_stack+0x1b/0x40 [ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90 [ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330 [ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040 [ 46.638275][ T7] brcmf_attach+0x389/0xd40 [ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690 [ 46.639279][ T7] usb_probe_interface+0x2aa/0x760 [ 46.639820][ T7] really_probe+0x205/0xb70 [ 46.640342][ T7] __driver_probe_device+0 ---truncated---
- https://git.kernel.org/stable/c/0da40e018fd034d87c9460123fa7f897b69fdee7
- https://git.kernel.org/stable/c/21bee3e649d87f78fe8aef6ae02edd3d6f310fd0
- https://git.kernel.org/stable/c/228186629ea970cc78b7d7d5f593f2d32fddf9f6
- https://git.kernel.org/stable/c/39f9bd880abac6068bedb24a4e16e7bd26bf92da
- https://git.kernel.org/stable/c/425eea395f1f5ae349fb55f7fe51d833a5324bfe
- https://git.kernel.org/stable/c/549825602e3e6449927ca1ea1a08fd89868439df
- https://git.kernel.org/stable/c/936a23293bbb3332bdf4cdb9c1496e80cb0bc2c8
- https://git.kernel.org/stable/c/ac5305e5d227b9af3aae25fa83380d3ff0225b73
- https://git.kernel.org/stable/c/e29661611e6e71027159a3140e818ef3b99f32dd
Modified: 2026-01-14
CVE-2023-53219
In the Linux kernel, the following vulnerability has been resolved: media: netup_unidvb: fix use-after-free at del_timer() When Universal DVB card is detaching, netup_unidvb_dma_fini() uses del_timer() to stop dma->timeout timer. But when timer handler netup_unidvb_dma_timeout() is running, del_timer() could not stop it. As a result, the use-after-free bug could happen. The process is shown below: (cleanup routine) | (timer routine) | mod_timer(&dev->tx_sim_timer, ..) netup_unidvb_finidev() | (wait a time) netup_unidvb_dma_fini() | netup_unidvb_dma_timeout() del_timer(&dma->timeout); | | ndev->pci_dev->dev //USE Fix by changing del_timer() to del_timer_sync().
- https://git.kernel.org/stable/c/051af3f0b7d1cd8ab7f3e2523ad8ae1af44caba3
- https://git.kernel.org/stable/c/07821524f67bf920342bc84ae8b3dea2a315a89e
- https://git.kernel.org/stable/c/0f5bb36bf9b39a2a96e730bf4455095b50713f63
- https://git.kernel.org/stable/c/1550bcf2983ae1220cc8ab899a39a423fa7cb523
- https://git.kernel.org/stable/c/90229e9ee957d4514425e4a4d82c50ab5d57ac4d
- https://git.kernel.org/stable/c/c8f9c05e1ebcc9c7bc211cc8b74d8fb86a8756fc
- https://git.kernel.org/stable/c/dd5c77814f290b353917df329f36de1472d47154
- https://git.kernel.org/stable/c/f9982db735a8495eee14267cf193c806b957e942
Modified: 2026-01-14
CVE-2023-53225
In the Linux kernel, the following vulnerability has been resolved: spi: imx: Don't skip cleanup in remove's error path Returning early in a platform driver's remove callback is wrong. In this case the dma resources are not released in the error path. this is never retried later and so this is a permanent leak. To fix this, only skip hardware disabling if waking the device fails.
- https://git.kernel.org/stable/c/11951c9e3f364d7ae3b568a0e52c8335d43066b5
- https://git.kernel.org/stable/c/57a463226638f1ceabbb029cbd21b0c94640f1b5
- https://git.kernel.org/stable/c/6d16305a1535873e0a8a8ae92ea2d9106ec2d7df
- https://git.kernel.org/stable/c/aa93a46f998a9069368026ac52bba96868c59157
- https://git.kernel.org/stable/c/b64cb3f085fed296103c91f0db6acad30a021b36
- https://git.kernel.org/stable/c/f90822ad63d11301e425311dac0c8e12ca1737b8
Modified: 2026-01-14
CVE-2023-53268
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_mqs: move of_node_put() to the correct location of_node_put() should have been done directly after mqs_priv->regmap = syscon_node_to_regmap(gpr_np); otherwise it creates a reference leak on the success path. To fix this, of_node_put() is moved to the correct location, and change all the gotos to direct returns.
- https://git.kernel.org/stable/c/1bdb4a5ccab2316935ce4ad4fd4df8d36f0ffc6e
- https://git.kernel.org/stable/c/1c34890273a020d61d6127ade3f68ed1cb21c16a
- https://git.kernel.org/stable/c/402299cca89273b62384b5f9645ea49cd5fc4a57
- https://git.kernel.org/stable/c/6a129c0e9935112ecf2ffb6de98f83b8fd090c86
- https://git.kernel.org/stable/c/9a2585088a7d6f98a5a910f5b4b74b6d24e63156
- https://git.kernel.org/stable/c/b5a6930fc6a432e32714c4ed3c597077d999cf6d
Modified: 2026-01-14
CVE-2023-53276
In the Linux kernel, the following vulnerability has been resolved: ubifs: Free memory for tmpfile name When opening a ubifs tmpfile on an encrypted directory, function fscrypt_setup_filename allocates memory for the name that is to be stored in the directory entry, but after the name has been copied to the directory entry inode, the memory is not freed. When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program 'tmpfile' just opening a tmpfile: unreferenced object 0xffff88810178f380 (size 32): comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename ubifs_tmpfile vfs_tmpfile path_openat Free this memory after it has been copied to the inode.
- https://git.kernel.org/stable/c/107d481642c356a5668058066360fc473911e628
- https://git.kernel.org/stable/c/1e43d4284bdc3bd34bd770fea13910ac37ab0618
- https://git.kernel.org/stable/c/1fb815b38bb31d6af9bd0540b8652a0d6fe6cfd3
- https://git.kernel.org/stable/c/29738e1bcc799dd754711d4e4aab967f0c018175
- https://git.kernel.org/stable/c/823f554747f8aafaa965fb2f3ae794110ed429ef
- https://git.kernel.org/stable/c/8ad8c67a897e68426e85990ebfe0a7d1f71fc79f
- https://git.kernel.org/stable/c/b8f444a4fadfb5070ed7e298e0a5ceb4a18014f3
- https://git.kernel.org/stable/c/ce840284929b75dbbf062e0ce7fcb78a63b08b5e
- https://git.kernel.org/stable/c/fd197308c0e4f738c7ea687d5332035c5753881c
Modified: 2026-01-14
CVE-2023-53285
In the Linux kernel, the following vulnerability has been resolved: ext4: add bounds checking in get_max_inline_xattr_value_size() Normally the extended attributes in the inode body would have been checked when the inode is first opened, but if someone is writing to the block device while the file system is mounted, it's possible for the inode table to get corrupted. Add bounds checking to avoid reading beyond the end of allocated memory if this happens.
- https://git.kernel.org/stable/c/1d2caddbeeee56fbbc36b428c5b909c3ad88eb7f
- https://git.kernel.org/stable/c/2220eaf90992c11d888fe771055d4de330385f01
- https://git.kernel.org/stable/c/3d7b8fbcd2273e2b9f4c6de5ce2f4c0cd3cb1205
- https://git.kernel.org/stable/c/4597554b4f7b29e7fd78aa449bab648f8da4ee2c
- https://git.kernel.org/stable/c/486efbbc9445dca7890a1b86adbccb88b91284b0
- https://git.kernel.org/stable/c/5a229d21b98d132673096710e8281ef522dab1d1
- https://git.kernel.org/stable/c/88a06a94942c5c0a896e9da1113a6bb29e36cbef
- https://git.kernel.org/stable/c/e780058bd75614b66882bc02620ddbd884171560
- https://git.kernel.org/stable/c/f22b274429e88d3dc7e79d375b56ce4f2f59f0b4
Modified: 2026-01-14
CVE-2023-53289
In the Linux kernel, the following vulnerability has been resolved: media: bdisp: Add missing check for create_workqueue Add the check for the return value of the create_workqueue in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/0d09ce05724cfb3f5c5136893bec95305c641875
- https://git.kernel.org/stable/c/2371adeab717d8fe32144a84f3491a03c5838cfb
- https://git.kernel.org/stable/c/2bfbe3ad371ac5349302833198df14e442622cbc
- https://git.kernel.org/stable/c/4362444dca02ab44ac844feda3cf6238ef953673
- https://git.kernel.org/stable/c/519b0849401194745ea40f9e07513b870afc1b42
- https://git.kernel.org/stable/c/c2e55481731b0e8c96f30f661e430aa884fbd354
- https://git.kernel.org/stable/c/c6a315f0b14074ac89723f55b749a557dda0ae2b
- https://git.kernel.org/stable/c/eef95a2745cb91559bb03aa111c228fe38deaf64
- https://git.kernel.org/stable/c/fc1aeafdf6fb0a136c2257000f0d478ee62953fe
Modified: 2026-01-14
CVE-2023-53290
In the Linux kernel, the following vulnerability has been resolved: samples/bpf: Fix fout leak in hbm's run_bpf_prog Fix fout being fopen'ed but then not subsequently fclose'd. In the affected branch, fout is otherwise going out of scope.
- https://git.kernel.org/stable/c/23acb14af1914010dd0aae1bbb7fab28bf518b8e
- https://git.kernel.org/stable/c/7560ed6592ff4077528c239c71e91b19de985b97
- https://git.kernel.org/stable/c/a7ec2f424f6edad34651137783a0a59eca9aa37e
- https://git.kernel.org/stable/c/e3e6e252d74f20f6fc610c7fef3ae7dda0109a6f
- https://git.kernel.org/stable/c/edf37bc8b03d3f948e679b2fd2d14464495f5d1b
- https://git.kernel.org/stable/c/f2065b8b0a215bc6aa061287a2e3d9eab2446422
Modified: 2026-01-14
CVE-2023-53297
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix "bad unlock balance" in l2cap_disconnect_rsp conn->chan_lock isn't acquired before l2cap_get_chan_by_scid, if l2cap_get_chan_by_scid returns NULL, then 'bad unlock balance' is triggered.
- https://git.kernel.org/stable/c/116b9c002c894097adc2b8684db2d1da4229ed46
- https://git.kernel.org/stable/c/2112c4c47d36bc5aba3ddeb9afedce6ae6a67e7d
- https://git.kernel.org/stable/c/25e97f7b1866e6b8503be349eeea44bb52d661ce
- https://git.kernel.org/stable/c/5134556c9be582793f30695c09d18a26fe1ff2d7
- https://git.kernel.org/stable/c/55410a9144c76ecda126e6cdec556dfcd8f343b2
- https://git.kernel.org/stable/c/5f352a56f0e607e6ff539cbf12156bfd8af232be
- https://git.kernel.org/stable/c/6a27762340ad08643de3bc17fe1646ea489ca2e2
- https://git.kernel.org/stable/c/fd269a0435f8e9943b7a57c5a59688848d42d449
Modified: 2026-01-14
CVE-2023-53299
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix leak of 'r10bio->remaining' for recovery raid10_sync_request() will add 'r10bio->remaining' for both rdev and replacement rdev. However, if the read io fails, recovery_request_write() returns without issuing the write io, in this case, end_sync_request() is only called once and 'remaining' is leaked, cause an io hang. Fix the problem by decreasing 'remaining' according to if 'bio' and 'repl_bio' is valid.
- https://git.kernel.org/stable/c/11141630f03efffdfe260b3582b2d93d38171b97
- https://git.kernel.org/stable/c/1697fb124c6d6c5237e9cbd78890310154738084
- https://git.kernel.org/stable/c/1d2c6c6e37fe5de11fd01a82badf03390e12df7a
- https://git.kernel.org/stable/c/26208a7cffd0c7cbf14237ccd20c7270b3ffeb7e
- https://git.kernel.org/stable/c/3481dec5ecbbbbe44ab23e22c2b14bd65c644ec6
- https://git.kernel.org/stable/c/4f82e7e07cdaf2947d71968e3d6b73370a217093
- https://git.kernel.org/stable/c/8c5d5d7ffd1e76734811b8ea5417cf0432b9952c
- https://git.kernel.org/stable/c/8d09065802c53cc938d162b62f6c4150b392c90e
- https://git.kernel.org/stable/c/cb827ed2bb34480dc102146d3a1f89fdbcafc028
Modified: 2026-01-14
CVE-2023-53308
In the Linux kernel, the following vulnerability has been resolved: net: fec: Better handle pm_runtime_get() failing in .remove() In the (unlikely) event that pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, the remove callback returned an error early. The problem with this is that the driver core ignores the error value and continues removing the device. This results in a resource leak. Worse the devm allocated resources are freed and so if a callback of the driver is called later the register mapping is already gone which probably results in a crash.
- https://git.kernel.org/stable/c/83996d317b1deddc85006376082e8886f55aa709
- https://git.kernel.org/stable/c/9407454a9b18bbeff216e8ecde87ffb2171e9ccf
- https://git.kernel.org/stable/c/b22b514209ff8c4287abb853399890ab97e1b5ca
- https://git.kernel.org/stable/c/be85912c36ddca3e8b2eef1b5392cd8db6bdb730
- https://git.kernel.org/stable/c/c1bc2870f14e526a01897e14c747a0a0ca125231
- https://git.kernel.org/stable/c/d52a0cca591e899d4e5c8ab19e067b4c6b7d104f
- https://git.kernel.org/stable/c/e02d8d5b1602689b98d9b91550a11b9b57baedbe
- https://git.kernel.org/stable/c/f816b9829b19394d318e01953aa3b2721bca040d
Modified: 2026-01-14
CVE-2023-53315
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Fix SKB corruption in REO destination ring While running traffics for a long time, randomly an RX descriptor filled with value "0" from REO destination ring is received. This descriptor which is invalid causes the wrong SKB (SKB stored in the IDR lookup with buffer id "0") to be fetched which in turn causes SKB memory corruption issue and the same leads to crash after some time. Changed the start id for idr allocation to "1" and the buffer id "0" is reserved for error validation. Introduced Sanity check to validate the descriptor, before processing the SKB. Crash Signature : Unable to handle kernel paging request at virtual address 3f004900 PC points to "b15_dma_inv_range+0x30/0x50" LR points to "dma_cache_maint_page+0x8c/0x128". The Backtrace obtained is as follows: [<8031716c>] (b15_dma_inv_range) from [<80313a4c>] (dma_cache_maint_page+0x8c/0x128) [<80313a4c>] (dma_cache_maint_page) from [<80313b90>] (__dma_page_dev_to_cpu+0x28/0xcc) [<80313b90>] (__dma_page_dev_to_cpu) from [<7fb5dd68>] (ath11k_dp_process_rx+0x1e8/0x4a4 [ath11k]) [<7fb5dd68>] (ath11k_dp_process_rx [ath11k]) from [<7fb53c20>] (ath11k_dp_service_srng+0xb0/0x2ac [ath11k]) [<7fb53c20>] (ath11k_dp_service_srng [ath11k]) from [<7f67bba4>] (ath11k_pci_ext_grp_napi_poll+0x1c/0x78 [ath11k_pci]) [<7f67bba4>] (ath11k_pci_ext_grp_napi_poll [ath11k_pci]) from [<807d5cf4>] (__napi_poll+0x28/0xb8) [<807d5cf4>] (__napi_poll) from [<807d5f28>] (net_rx_action+0xf0/0x280) [<807d5f28>] (net_rx_action) from [<80302148>] (__do_softirq+0xd0/0x280) [<80302148>] (__do_softirq) from [<80320408>] (irq_exit+0x74/0xd4) [<80320408>] (irq_exit) from [<803638a4>] (__handle_domain_irq+0x90/0xb4) [<803638a4>] (__handle_domain_irq) from [<805bedec>] (gic_handle_irq+0x58/0x90) [<805bedec>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
- https://git.kernel.org/stable/c/068fd06148fbf0af95bb08dc77cff34ee679fdbc
- https://git.kernel.org/stable/c/3d3f8fe01a01d94a17fe1ae0d2e894049a972717
- https://git.kernel.org/stable/c/67459491f78146bcf7d93596e5b709d063dff5d8
- https://git.kernel.org/stable/c/866921dc06b94df91acfcf9359b57da943ed99b3
- https://git.kernel.org/stable/c/f9fff67d2d7ca6fa8066132003a3deef654c55b1
Modified: 2026-01-14
CVE-2023-53317
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in mb_find_extent
Syzbot found the following issue:
EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
EXT4-fs (loop0): orphan cleanup on readonly fs
------------[ cut here ]------------
WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30
Modules linked in:
CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869
RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293
RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0
RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040
RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402
R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000
R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc
FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1b90fbc7590124c57a2e590de7fd07eba26606f1
- https://git.kernel.org/stable/c/5d356d902e9d5b1aaaaf2326d365340fa8a90c1b
- https://git.kernel.org/stable/c/775b00ba23f6f916fe2ac60c5ff7fd0fe4f28d0d
- https://git.kernel.org/stable/c/d55e76e11592a1d18a179c7fd34ca1b52632beb3
- https://git.kernel.org/stable/c/dba62fa84a8eac44a53a2862de8a40e5bdfa0ae3
- https://git.kernel.org/stable/c/dd45e536f47a82e0a405f9a4b6c7ceb367171ee9
- https://git.kernel.org/stable/c/e4d503c956a744cb59e509ca5f134cfad423c7a3
- https://git.kernel.org/stable/c/fa08a7b61dff8a4df11ff1e84abfc214b487caf7
Modified: 2026-01-14
CVE-2023-53318
In the Linux kernel, the following vulnerability has been resolved: recordmcount: Fix memory leaks in the uwrite function Common realloc mistake: 'file_append' nulled but not freed upon failure
- https://git.kernel.org/stable/c/25c9b185f121812cbc215fdaa1192c6b9025b428
- https://git.kernel.org/stable/c/2d9ca5f62f2ba160ff9c9be4adf401c46c04edef
- https://git.kernel.org/stable/c/3ed95a6f6c646e8bb15c354536e0ab10e8f39c08
- https://git.kernel.org/stable/c/444ec005404cead222ebce2561a9451c9ee5ad89
- https://git.kernel.org/stable/c/895130e63c93926f07caf5db286b97bd27b81de9
- https://git.kernel.org/stable/c/bd39f68a309a947670379bf9a39b16c584f86ddb
- https://git.kernel.org/stable/c/fa359d068574d29e7d2f0fdd0ebe4c6a12b5cfb9
- https://git.kernel.org/stable/c/ff70ad9159fbb566b2c15724f44207e8deccd527
Modified: 2026-01-14
CVE-2023-53337
In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not write dirty data after degenerating to read-only According to syzbot's report, mark_buffer_dirty() called from nilfs_segctor_do_construct() outputs a warning with some patterns after nilfs2 detects metadata corruption and degrades to read-only mode. After such read-only degeneration, page cache data may be cleared through nilfs_clear_dirty_page() which may also clear the uptodate flag for their buffer heads. However, even after the degeneration, log writes are still performed by unmount processing etc., which causes mark_buffer_dirty() to be called for buffer heads without the "uptodate" flag and causes the warning. Since any writes should not be done to a read-only file system in the first place, this fixes the warning in mark_buffer_dirty() by letting nilfs_segctor_do_construct() abort early if in read-only mode. This also changes the retry check of nilfs_segctor_write_out() to avoid unnecessary log write retries if it detects -EROFS that nilfs_segctor_do_construct() returned.
- https://git.kernel.org/stable/c/13f73ef77baa4764dc1ca4fcbae9cade05b83866
- https://git.kernel.org/stable/c/28a65b49eb53e172d23567005465019658bfdb4d
- https://git.kernel.org/stable/c/4005cec6847c06ee191583270b7cdd7e696543cc
- https://git.kernel.org/stable/c/4569a292a84e340e97d178898ad1cfe1a3080a61
- https://git.kernel.org/stable/c/55f7810632f993cff622a0ddbc7c865892294b61
- https://git.kernel.org/stable/c/7c3e662048053802f6b0db3a78e97f4e1f7edc4f
- https://git.kernel.org/stable/c/a73201c607d8e506358d60aafddda4246bdd9350
- https://git.kernel.org/stable/c/bd89073fc7a5d03b1d06b372addbe405e5a925f4
- https://git.kernel.org/stable/c/e9c5412c5972124776c1b873533eb39e287a4dfa
Modified: 2026-01-14
CVE-2023-53400
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix Oops by 9.1 surround channel names get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec. As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
- https://git.kernel.org/stable/c/082dcd51667b29097500c824c37f24da997a6a8a
- https://git.kernel.org/stable/c/3b44ec8c5c44790a82f07e90db45643c762878c6
- https://git.kernel.org/stable/c/4ef155ddf9578bf035964d58739fdcd7dd44b4a4
- https://git.kernel.org/stable/c/546b1f5f45a355ae0d3a8041cdaca597dfcac825
- https://git.kernel.org/stable/c/b5694aae4c2d9a288bafce7d38f122769e0428e6
- https://git.kernel.org/stable/c/dc8c569d59f17b17d7bca4f68c36bd571659921e
- https://git.kernel.org/stable/c/e8c7d7c43d5edd20e518fe1dfb2371d1fe6e8bb8
- https://git.kernel.org/stable/c/fcf637461019e9a5a0c12fc5c42a9db1779b0634
Modified: 2026-01-14
CVE-2023-53419
In the Linux kernel, the following vulnerability has been resolved: rcu: Protect rcu_print_task_exp_stall() ->exp_tasks access For kernels built with CONFIG_PREEMPT_RCU=y, the following scenario can result in a NULL-pointer dereference: CPU1 CPU2 rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall if (special.b.blocked) READ_ONCE(rnp->exp_tasks) != NULL raw_spin_lock_rcu_node np = rcu_next_node_entry(t, rnp) if (&t->rcu_node_entry == rnp->exp_tasks) WRITE_ONCE(rnp->exp_tasks, np) .... raw_spin_unlock_irqrestore_rcu_node raw_spin_lock_irqsave_rcu_node t = list_entry(rnp->exp_tasks->prev, struct task_struct, rcu_node_entry) (if rnp->exp_tasks is NULL, this will dereference a NULL pointer) The problem is that CPU2 accesses the rcu_node structure's->exp_tasks field without holding the rcu_node structure's ->lock and CPU2 did not observe CPU1's change to rcu_node structure's ->exp_tasks in time. Therefore, if CPU1 sets rcu_node structure's->exp_tasks pointer to NULL, then CPU2 might dereference that NULL pointer. This commit therefore holds the rcu_node structure's ->lock while accessing that structure's->exp_tasks field. [ paulmck: Apply Frederic Weisbecker feedback. ]
- https://git.kernel.org/stable/c/2bc0ae94ef1f9ed322d8ee439de3239ea3632ab2
- https://git.kernel.org/stable/c/3c1566bca3f8349f12b75d0a2d5e4a20ad6262ec
- https://git.kernel.org/stable/c/a7d21b8585894e6fff973f6ddae42f02b13f600f
- https://git.kernel.org/stable/c/d0a8c0e31a09ec1efd53079083e2a677956b4d91
- https://git.kernel.org/stable/c/e30a55e98ae6c44253d8b129efefd5da5bc6e3bc
Modified: 2026-01-14
CVE-2023-53422
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fw: fix memory leak in debugfs Fix a memory leak that occurs when reading the fw_info file all the way, since we return NULL indicating no more data, but don't free the status tracking object.
- https://git.kernel.org/stable/c/37f64bc8e001f216566d17ef9fd5608c762ebcd4
- https://git.kernel.org/stable/c/3d90d2f4a018fe8cfd65068bc6350b6222be4852
- https://git.kernel.org/stable/c/89496d6cff297c88fe0286a440c380ceb172da2b
- https://git.kernel.org/stable/c/b830ba20b43be52eae7d4087b61a0079dec56820
- https://git.kernel.org/stable/c/e302e9ca14a86a80eadfb24a34d8675aadaf3ef3
- https://git.kernel.org/stable/c/fe17124282da055cb2e53f0131521459b5c7866c
Modified: 2026-01-14
CVE-2023-53433
In the Linux kernel, the following vulnerability has been resolved:
net: add vlan_get_protocol_and_depth() helper
Before blamed commit, pskb_may_pull() was used instead
of skb_header_pointer() in __vlan_get_protocol() and friends.
Few callers depended on skb->head being populated with MAC header,
syzbot caught one of them (skb_mac_gso_segment())
Add vlan_get_protocol_and_depth() to make the intent clearer
and use it where sensible.
This is a more generic fix than commit e9d3f80935b6
("net/af_packet: make sure to pull mac header") which was
dealing with a similar issue.
kernel BUG at include/linux/skbuff.h:2655 !
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]
RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136
Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286
RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9
R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012
R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7
FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/15eaeb8941f12fcc2713c4bf6eb8f76a37854b4d
- https://git.kernel.org/stable/c/34a5ee69ec6273f0aee79e7ce4d14afc83ca8122
- https://git.kernel.org/stable/c/4063384ef762cc5946fc7a3f89879e76c6ec51e2
- https://git.kernel.org/stable/c/4188c5269475ac59d467b5814c5df02756f6d907
- https://git.kernel.org/stable/c/55caf900e13cd04466def08173a14b41d18c19c3
- https://git.kernel.org/stable/c/9dd9ffe118415b4ac1cebac43443000072bc8f46
Modified: 2026-01-14
CVE-2023-53435
In the Linux kernel, the following vulnerability has been resolved: cassini: Fix a memory leak in the error handling path of cas_init_one() cas_saturn_firmware_init() allocates some memory using vmalloc(). This memory is freed in the .remove() function but not it the error handling path of the probe. Add the missing vfree() to avoid a memory leak, should an error occur.
- https://git.kernel.org/stable/c/11c0ed097a874156957b515d0ba7e356142eab87
- https://git.kernel.org/stable/c/172146c26f0c1b86ab4e9ebffc7e06f04229fa17
- https://git.kernel.org/stable/c/234e744d86bd95b381d24546df2dba72804e0219
- https://git.kernel.org/stable/c/412cd77a2c24b191c65ea53025222418db09817c
- https://git.kernel.org/stable/c/60d8e8b88087d68e10c8991a0f6733fa2f963ff0
- https://git.kernel.org/stable/c/b8b1a667744741fa7807b09a12797a27f14f3fac
- https://git.kernel.org/stable/c/dc61f7582cc92d547d02e141cd66f5d1f4ed8012
- https://git.kernel.org/stable/c/e20105d967ab5b53ff50a0e5991fe37324d2ba20
Modified: 2026-01-23
CVE-2023-53450
In the Linux kernel, the following vulnerability has been resolved: ext4: remove a BUG_ON in ext4_mb_release_group_pa() If a malicious fuzzer overwrites the ext4 superblock while it is mounted such that the s_first_data_block is set to a very large number, the calculation of the block group can underflow, and trigger a BUG_ON check. Change this to be an ext4_warning so that we don't crash the kernel.
- https://git.kernel.org/stable/c/185062a21976fbc38f2efd296951b02c4500cf65
- https://git.kernel.org/stable/c/463808f237cf73e98a1a45ff7460c2406a150a0b
- https://git.kernel.org/stable/c/53c14e7cc2257191ba15425c15638fc4f8abb92b
- https://git.kernel.org/stable/c/978e5e9111af18741449b81fefd531a622dd969a
- https://git.kernel.org/stable/c/b0fc279de4bf17e1710bb7e83906538ff8f11111
- https://git.kernel.org/stable/c/bf2a16eb4e6d06124bd8436d4546f61539a65f29
- https://git.kernel.org/stable/c/d5bf8f7fb3ee3d99d1303ceb54599ea0599a4a5b
- https://git.kernel.org/stable/c/d87a4e4094c9879fc8acdff8ce59fdffa979c8e0
- https://git.kernel.org/stable/c/ef16d8a1798db1a1604ac44ca1bd73ec6bebf483
Modified: 2026-01-20
CVE-2023-53471
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras
gfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert.
So in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq
should be executed under such condition, otherwise, an amdgpu_irq_put
calltrace will occur.
[ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
[ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246
[ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: 0000000000000000
[ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000
[ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: 0000000000000006
[ 7283.170973] R10: ffffd5764243c008 R11: 0000000000000000 R12: 0000000000001050
[ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
[ 7283.170978] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
[ 7283.170981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
[ 7283.170986] Call Trace:
[ 7283.170988]
- https://git.kernel.org/stable/c/20ca90ceda71ed90a4d6960acbe7d5e120b40c0d
- https://git.kernel.org/stable/c/3d28af21a874c5123d1681c2d686627f7ff7e488
- https://git.kernel.org/stable/c/4a76680311330aefe5074bed8f06afa354b85c48
- https://git.kernel.org/stable/c/625d4112ea25dbad7ddf749fd5c1287ceffb2339
- https://git.kernel.org/stable/c/cd3c0f7013c37cd24fc40b601319007f136c1201
- https://git.kernel.org/stable/c/efce310db74fdc6d2acd959f3582972ae4a8d7d5
- https://git.kernel.org/stable/c/f661ad53658a1ea35c004af1f5fbe25c4d1cdb08
Modified: 2026-01-20
CVE-2023-53474
In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Use an u64 for bank_map Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64"). However, the bank_map which contains a bitfield of which banks to initialize is of type unsigned int and that overflows when those bit numbers are >= 32, leading to UBSAN complaining correctly: UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38 shift exponent 32 is too large for 32-bit type 'int' Change the bank_map to a u64 and use the proper BIT_ULL() macro when modifying bits in there. [ bp: Rewrite commit message. ]
- https://git.kernel.org/stable/c/11c58a0c1937c157dbdf82d5ab634d68c99f3098
- https://git.kernel.org/stable/c/4c1cdec319b9aadb65737c3eb1f5cb74bd6aa156
- https://git.kernel.org/stable/c/67bb7521b6420d81dab7538c0686f18f7d6d09f4
- https://git.kernel.org/stable/c/9669fa17287c3af2bbd4868d4c8fdd9e57f8332e
- https://git.kernel.org/stable/c/a9b9ea0e63a0ec5e97bf1219ab6dcbd55e362f83
- https://git.kernel.org/stable/c/ba8ffb1251eb629c2ec35220e3896cf4f7b888a7
Modified: 2026-01-20
CVE-2023-53484
In the Linux kernel, the following vulnerability has been resolved: lib: cpu_rmap: Avoid use after free on rmap->obj array entries When calling irq_set_affinity_notifier() with NULL at the notify argument, it will cause freeing of the glue pointer in the corresponding array entry but will leave the pointer in the array. A subsequent call to free_irq_cpu_rmap() will try to free this entry again leading to possible use after free. Fix that by setting NULL to the array entry and checking that we have non-zero at the array entry when iterating over the array in free_irq_cpu_rmap(). The current code does not suffer from this since there are no cases where irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the notify arg) is called, followed by a call to free_irq_cpu_rmap() so we don't hit and issue. Subsequent patches in this series excersize this flow, hence the required fix.
- https://git.kernel.org/stable/c/4e0473f1060aa49621d40a113afde24818101d37
- https://git.kernel.org/stable/c/67bca5f1d644f4e79b694abd8052a177de81c37f
- https://git.kernel.org/stable/c/981f339d2905b6a92ef59358158b326493aecac5
- https://git.kernel.org/stable/c/c6ed54dd90698dc0744d669524cc1c122ded8a16
- https://git.kernel.org/stable/c/c9115f49cf260d24d8b5f2d9a4b63cb31a627bb4
- https://git.kernel.org/stable/c/cc2d2b3dbfb0ba57bc027fb7e1121250c50e4000
- https://git.kernel.org/stable/c/d1308bd0b24cb1d78fa2747d5fa3e055cc628a48
- https://git.kernel.org/stable/c/f748e15253833b771acbede14ea98f50831ac289
Modified: 2026-01-21
CVE-2023-53489
In the Linux kernel, the following vulnerability has been resolved: tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp. syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY skbs. We can reproduce the problem with these sequences: sk = socket(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53)) sk.close() sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets skb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, struct ubuf_info_msgzc indirectly holds a refcnt of the socket. When the skb is sent, __skb_tstamp_tx() clones it and puts the clone into the socket's error queue with the TX timestamp. When the original skb is received locally, skb_copy_ubufs() calls skb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt. This additional count is decremented while freeing the skb, but struct ubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is not called. The last refcnt is not released unless we retrieve the TX timestamped skb by recvmsg(). Since we clear the error queue in inet_sock_destruct() after the socket's refcnt reaches 0, there is a circular dependency. If we close() the socket holding such skbs, we never call sock_put() and leak the count, sk, and skb. TCP has the same problem, and commit e0c8bccd40fc ("net: stream: purge sk_error_queue in sk_stream_kill_queues()") tried to fix it by calling skb_queue_purge() during close(). However, there is a small chance that skb queued in a qdisc or device could be put into the error queue after the skb_queue_purge() call. In __skb_tstamp_tx(), the cloned skb should not have a reference to the ubuf to remove the circular dependency, but skb_clone() does not call skb_copy_ubufs() for zerocopy skb. So, we need to call skb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs(). [0]: BUG: memory leak unreferenced object 0xffff88800c6d2d00 (size 1152): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................ 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline] [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd BUG: memory leak unreferenced object 0xffff888017633a00 (size 240): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m..... backtrace: [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>] ---truncated---
- https://git.kernel.org/stable/c/1f69c086b20e27763af28145981435423f088268
- https://git.kernel.org/stable/c/230a5ed7d813fb516de81d23f09d7506753e41e9
- https://git.kernel.org/stable/c/281072fb2a7294cde7acbf5375b879f40a8001b7
- https://git.kernel.org/stable/c/30290f210ba7426ff7592fe2eb4114b1b5bad219
- https://git.kernel.org/stable/c/426384dd4980040651536fef5feac4dcc4d7ee4e
- https://git.kernel.org/stable/c/43e4197dd5f6b474a8b16f8b6a42cd45cf4f9d1a
- https://git.kernel.org/stable/c/50749f2dd6854a41830996ad302aef2ffaf011d8
- https://git.kernel.org/stable/c/602fa8af44fd55a58f9e94eb673e8adad2c6cc46
- https://git.kernel.org/stable/c/cb52e7f24c1d01a536a847dff0d1d95889cc3b5c
Modified: 2026-04-06
CVE-2023-53503
In the Linux kernel, the following vulnerability has been resolved: ext4: allow ext4_get_group_info() to fail Previously, ext4_get_group_info() would treat an invalid group number as BUG(), since in theory it should never happen. However, if a malicious attaker (or fuzzer) modifies the superblock via the block device while it is the file system is mounted, it is possible for s_first_data_block to get set to a very large number. In that case, when calculating the block group of some block number (such as the starting block of a preallocation region), could result in an underflow and very large block group number. Then the BUG_ON check in ext4_get_group_info() would fire, resutling in a denial of service attack that can be triggered by root or someone with write access to the block device. For a quality of implementation perspective, it's best that even if the system administrator does something that they shouldn't, that it will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info() will call ext4_error and return NULL. We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it. The results in a next reduction of the compiled text size of ext4 by roughly 2k.
- https://git.kernel.org/stable/c/100c0ad6c04597fefeaaba2bb1827cc015d95067
- https://git.kernel.org/stable/c/31668cebf45adfb6283e465e641c4f5a21b07afa
- https://git.kernel.org/stable/c/5354b2af34064a4579be8bc0e2f15a7b70f14b5f
- https://git.kernel.org/stable/c/620a3c28221bb219b81bc0bffd065cc187494302
- https://git.kernel.org/stable/c/b4319e457d6e3fb33e443efeaf4634fc36e8a9ed
Modified: 2026-04-06
CVE-2023-53517
In the Linux kernel, the following vulnerability has been resolved:
tipc: do not update mtu if msg_max is too small in mtu negotiation
When doing link mtu negotiation, a malicious peer may send Activate msg
with a very small mtu, e.g. 4 in Shuang's testing, without checking for
the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then
n->links[bearer_id].mtu is set to 4294967228, which is a overflow of
'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().
With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:
tipc: Too large msg, purging xmit list 1 5 0 40 4!
tipc: Too large msg, purging xmit list 1 15 0 60 4!
And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in
named_distribute(), and when purging it in tipc_link_xmit(), a crash
was even caused:
general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19
RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0
Call Trace:
- https://git.kernel.org/stable/c/1dd7ae5e0cf5a56e513f7ab7ab9570b7496281d2
- https://git.kernel.org/stable/c/259683001d7e879fea4b42084fb6560dd9408a7e
- https://git.kernel.org/stable/c/2bd4ff4ffb92113f8acd04dbaed83269172c24b4
- https://git.kernel.org/stable/c/56077b56cd3fb78e1c8619e29581ba25a5c55e86
- https://git.kernel.org/stable/c/575e84d90a74c0b091b3417ba763ebb237aa0a8c
Modified: 2026-04-06
CVE-2023-53524
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf An integer overflow occurs in the iwl_write_to_user_buf() function, which is called by the iwl_dbgfs_monitor_data_read() function. static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count, void *buf, ssize_t *size, ssize_t *bytes_copied) { int buf_size_left = count - *bytes_copied; buf_size_left = buf_size_left - (buf_size_left % sizeof(u32)); if (*size > buf_size_left) *size = buf_size_left; If the user passes a SIZE_MAX value to the "ssize_t count" parameter, the ssize_t count parameter is assigned to "int buf_size_left". Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a negative number, so "*size" is assigned "buf_size_left" and goes into the third argument of the copy_to_user function, causing a heap overflow. This is not a security vulnerability because iwl_dbgfs_monitor_data_read() is a debugfs operation with 0400 privileges.
- https://git.kernel.org/stable/c/059e426d666a41e26b184c177c1ca3ee2d6fa1b6
- https://git.kernel.org/stable/c/0ad8dd870aa187d0c21d032bb2c6433559075eec
- https://git.kernel.org/stable/c/58d1b717879bfeabe09b35e41ad667c79933eb2e
- https://git.kernel.org/stable/c/82f877ec9b041edc4c7c509c605cc3393d837bf0
- https://git.kernel.org/stable/c/de78456976026102babe66258c228691ca5677c0
- https://git.kernel.org/stable/c/eb1ef44efac797b384d361a76e33f77027c29a14
Modified: 2026-03-25
CVE-2023-53533
In the Linux kernel, the following vulnerability has been resolved: Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe rpi_firmware_get() take reference, we need to release it in error paths as well. Use devm_rpi_firmware_get() helper to handling the resources. Also remove the existing rpi_firmware_put().
- https://git.kernel.org/stable/c/0d6a5c9489c8a3d434e685066119c4333476dccd
- https://git.kernel.org/stable/c/1dfa3c9dd27bdc347733d06e980395768520bc3e
- https://git.kernel.org/stable/c/36d087e49dabd28d2c13a7532dac72d625ce69fb
- https://git.kernel.org/stable/c/5bca3688bdbc3b58a2894b8671a8e2378efe28bd
- https://git.kernel.org/stable/c/7acad58049acc6ac148e8b613a6eceeca4bcb4a7
- https://git.kernel.org/stable/c/9216aa5cfd86809a2681be3683cd9ac30432de0c
- https://git.kernel.org/stable/c/9dbbe9db224c23a60dc7b1e00c701be93328c873
Modified: 2026-03-25
CVE-2023-53536
In the Linux kernel, the following vulnerability has been resolved: blk-crypto: make blk_crypto_evict_key() more robust If blk_crypto_evict_key() sees that the key is still in-use (due to a bug) or that ->keyslot_evict failed, it currently just returns while leaving the key linked into the keyslot management structures. However, blk_crypto_evict_key() is only called in contexts such as inode eviction where failure is not an option. So actually the caller proceeds with freeing the blk_crypto_key regardless of the return value of blk_crypto_evict_key(). These two assumptions don't match, and the result is that there can be a use-after-free in blk_crypto_reprogram_all_keys() after one of these errors occurs. (Note, these errors *shouldn't* happen; we're just talking about what happens if they do anyway.) Fix this by making blk_crypto_evict_key() unlink the key from the keyslot management structures even on failure. Also improve some comments.
- https://git.kernel.org/stable/c/5bb4005fb667c6e2188fa87950f8d5faf2994410
- https://git.kernel.org/stable/c/5c62852942667c613de0458fc797c5b8c36112b5
- https://git.kernel.org/stable/c/5c7cb94452901a93e90c2230632e2c12a681bc92
- https://git.kernel.org/stable/c/64ef787bb1588475163069c2e62fdd8f6c27b1f6
- https://git.kernel.org/stable/c/701a8220762ff90615dc91d3543f789391b63298
- https://git.kernel.org/stable/c/809a5be62e92a444a3c3d7b9f438019d0b322f55
Modified: 2026-03-23
CVE-2023-53537
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free for cached IPU bio xfstest generic/019 reports a bug: kernel BUG at mm/filemap.c:1619! RIP: 0010:folio_end_writeback+0x8a/0x90 Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0 __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50 The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write() in f2fs_write_single_data_page() tries to flush IPU bio in cache, however f2fs_submit_merged_ipu_write() missed to check validity of @bio parameter, result in submitting random cached bio which belong to other IO context, then it will cause use-after-free issue, fix it by adding additional validity check.
- https://git.kernel.org/stable/c/5cdb422c839134273866208dad5360835ddb9794
- https://git.kernel.org/stable/c/7d058f0ab161437369ad6e45a4b67c2886e71373
- https://git.kernel.org/stable/c/97ec6f1788cc6bee3f8c89cb908e1a2a1cd859bb
- https://git.kernel.org/stable/c/9a7f63283af6befc0f91d549f4f6917dff7479a9
- https://git.kernel.org/stable/c/af4ce124d7bd74cb839bbdaccffbb416771a56b5
- https://git.kernel.org/stable/c/b2f423fda64fb49213aa0ed5056079cf295a5df2
Modified: 2026-03-21
CVE-2023-53566
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: fix null deref on element insertion There is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem(): general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] nft_add_set_elem+0x14b0/0x2990 nf_tables_newsetelem+0x528/0xb30 Furthermore, there is a possible use-after-free while iterating, 'node' can be free'd so we need to cache the next value to use.
- https://git.kernel.org/stable/c/3fa13203b6d90cc3a33af47b058739f92ab82eef
- https://git.kernel.org/stable/c/61ae320a29b0540c16931816299eb86bf2b66c08
- https://git.kernel.org/stable/c/899aa5638568abf5d69de7a7bb95e4615157375b
- https://git.kernel.org/stable/c/a337706c1fb35aac3f26b48aca80421bdbe1d33a
- https://git.kernel.org/stable/c/a836be60a3aabcedcd9c79f545d409ace1f20ba6
- https://git.kernel.org/stable/c/b76db53ee8802ee5683f8cb401d7e2ec6f9b3d56
- https://git.kernel.org/stable/c/ec5caa765f7f6960011c919c9aeb1467940421f6
Modified: 2026-03-21
CVE-2023-53567
In the Linux kernel, the following vulnerability has been resolved: spi: qup: Don't skip cleanup in remove's error path Returning early in a platform driver's remove callback is wrong. In this case the dma resources are not released in the error path. this is never retried later and so this is a permanent leak. To fix this, only skip hardware disabling if waking the device fails.
- https://git.kernel.org/stable/c/2d0f63077f481f11a07f20eab1c1f4367dfaef32
- https://git.kernel.org/stable/c/49c17fccae36505550c9121891722fff337f148a
- https://git.kernel.org/stable/c/55ecdcd12bc176b86fecbcb125ac814ac8fe857a
- https://git.kernel.org/stable/c/61f49171a43ab1f80c73c5c88c508770c461e0f2
- https://git.kernel.org/stable/c/8632384337038b97910c2f7bb5a3f377aa68d001
- https://git.kernel.org/stable/c/bc88243bbe6140d289bb32b4ee4607ba5ce1124a
- https://git.kernel.org/stable/c/f345d4d71e87d878437417ffbb9a7d4e16d235eb
- https://git.kernel.org/stable/c/fd53f41bd86daa39b454fd4637a908ff2123547f
Modified: 2026-03-21
CVE-2023-53569
In the Linux kernel, the following vulnerability has been resolved: ext2: Check block size validity during mount Check that log of block size stored in the superblock has sensible value. Otherwise the shift computing the block size can overflow leading to undefined behavior.
- https://git.kernel.org/stable/c/0ebfaf14150f55550cffb1148ed3920143c7a69c
- https://git.kernel.org/stable/c/22ab5fed07ad4b206ea910fd0132d1a0d4831584
- https://git.kernel.org/stable/c/451b98155be5dfee05bc6e7c8b30c0be4add3f71
- https://git.kernel.org/stable/c/62aeb94433fcec80241754b70d0d1836d5926b0a
- https://git.kernel.org/stable/c/99f8a15af6c9f0653193104a9e70891f950c6001
- https://git.kernel.org/stable/c/c2e7776843a953fd7e48895c3880c277f996193e
- https://git.kernel.org/stable/c/c4813f858e5c3e4c4659ce95385c1c400c593e1e
- https://git.kernel.org/stable/c/e6f4fb28890c1361e0db9eb1adee3fc04e7fe7f5
Modified: 2026-03-21
CVE-2023-53571
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Make intel_get_crtc_new_encoder() less oopsy The point of the WARN was to print something, not oops straight up. Currently that is precisely what happens if we can't find the connector for the crtc in the atomic state. Get the dev pointer from the atomic state instead of the potentially NULL encoder to avoid that. (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)
- https://git.kernel.org/stable/c/0fe6ef82e4f4764e8f556632e4cd93d78d448e99
- https://git.kernel.org/stable/c/54202488c835dab8c648acd107f0bb8eaa699894
- https://git.kernel.org/stable/c/631420b06597a33c72b6dcef78d1c2dea17f452d
- https://git.kernel.org/stable/c/780f303233c35eeb5132e3ee1cbc8f4cebe86dd2
- https://git.kernel.org/stable/c/8cd725315c559a8a4d18ac1d7fce1d6b9a667529
- https://git.kernel.org/stable/c/fd8b0abecdf66379e9d25d7448b942b5be379cb2
Modified: 2026-03-23
CVE-2023-53576
In the Linux kernel, the following vulnerability has been resolved:
null_blk: Always check queue mode setting from configfs
Make sure to check device queue mode in the null_validate_conf() and
return error for NULL_Q_RQ as we don't allow legacy I/O path, without
this patch we get OOPs when queue mode is set to 1 from configfs,
following are repro steps :-
modprobe null_blk nr_devices=0
mkdir config/nullb/nullb0
echo 1 > config/nullb/nullb0/memory_backed
echo 4096 > config/nullb/nullb0/blocksize
echo 20480 > config/nullb/nullb0/size
echo 1 > config/nullb/nullb0/queue_mode
echo 1 > config/nullb/nullb0/power
Entering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)
due to oops @ 0xffffffffc041c329
CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]
Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20
RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246
RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00
RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002
R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740
FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0
DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a
DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/35e304dbcefa95237a3d6f94c007bfb10f012b17
- https://git.kernel.org/stable/c/63f8793ee60513a09f110ea460a6ff2c33811cdb
- https://git.kernel.org/stable/c/651260e563d9f50827dac496dc8a0b9b23d5db1a
- https://git.kernel.org/stable/c/e732a266b973cd4e115e2cc2ea5007119e8a7fbc
- https://git.kernel.org/stable/c/fd35b7bb6d5a329c427924886949ab51f210200a
Modified: 2026-03-23
CVE-2023-53586
In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix multiple LUN_RESET handling This fixes a bug where an initiator thinks a LUN_RESET has cleaned up running commands when it hasn't. The bug was added in commit 51ec502a3266 ("target: Delete tmr from list before processing"). The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUN_RESET for each session. 3. session1's LUN_RESET loops over all the running commands from both sessions and moves them to its local drain_task_list. 4. session2's LUN_RESET does not see the LUN_RESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists. 5. sessions2's LUN_RESET will then complete with a successful response. 6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them. 7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already. Fix the bug by reverting the patch, and serialize the execution of LUN_RESETs and Preempt and Aborts. Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list, because it turns out the original patch fixed a bug that was not mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second LUN_RESET and wait on it. Then the second reset will run core_tmr_drain_tmr_list and see the first reset and wait on it resulting in a deadlock.
- https://git.kernel.org/stable/c/2c43de56f9220dca3e28c774d1c5e2cab574223a
- https://git.kernel.org/stable/c/673db054d7a2b5a470d7a25baf65956d005ad729
- https://git.kernel.org/stable/c/9158c86fd3237acaea8f0181c7836d90fd6eea10
- https://git.kernel.org/stable/c/e1f59cd18a10969d08a082264b557876ca38766e
- https://git.kernel.org/stable/c/eacfe32c3650bfd0e54224d160c431013d7f6998
- https://git.kernel.org/stable/c/ed18526289b5603bf2253dee50f1d7ec245cf397
Modified: 2026-03-23
CVE-2023-53587
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Sync IRQ works before buffer destruction If something was written to the buffer just before destruction, it may be possible (maybe not in a real system, but it did happen in ARCH=um with time-travel) to destroy the ringbuffer before the IRQ work ran, leading this KASAN report (or a crash without KASAN): BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96/0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>] __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>] tick_sched_timer+0x79/0x10c [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] Allocated by task 411: save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x2d/0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28 ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00) Add the appropriate irq_work_sync() so the work finishes before the buffers are destroyed. Prior to the commit in the Fixes tag below, there was only a single global IRQ work, so this issue didn't exist.
- https://git.kernel.org/stable/c/0a65165bd24ee9231191597b7c232376fcd70cdb
- https://git.kernel.org/stable/c/1c99f65d6af2a454bfd5207b4f6a97c8474a1191
- https://git.kernel.org/stable/c/2399b1fda025e939b6fb1ac94505bcf718534e65
- https://git.kernel.org/stable/c/2702b67f59d455072a08dc40312f9b090d4dec04
- https://git.kernel.org/stable/c/372c5ee537b8366b64b691ba29e9335525e1655e
- https://git.kernel.org/stable/c/675751bb20634f981498c7d66161584080cc061e
- https://git.kernel.org/stable/c/c63741e872fcfb10e153517750f7908f0c00f60d
- https://git.kernel.org/stable/c/d9834abd8b24d1fe8092859e436fe1e0fd467c61
- https://git.kernel.org/stable/c/fc6858b7f8e1221f62ce8c6ff8a13a349c32cd76
Modified: 2026-03-21
CVE-2023-53589
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response. Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictly.
- https://git.kernel.org/stable/c/05ad5a4d421ce65652fcb24d46b7e273130240d6
- https://git.kernel.org/stable/c/557ba100d8cf3661ff8d71c0b4a2cba8db555ec2
- https://git.kernel.org/stable/c/682b6dc29d98e857e6ca4bbc077c7dc2899b7473
- https://git.kernel.org/stable/c/c176f03350954b795322de0bfe1d7b514db41f45
- https://git.kernel.org/stable/c/d0d39bed9e95f27a246be91c5929254ac043ed30
- https://git.kernel.org/stable/c/e519a404a5bbba37693cb10fa61794a5fce4fd9b
Modified: 2026-03-23
CVE-2023-53604
In the Linux kernel, the following vulnerability has been resolved: dm integrity: call kmem_cache_destroy() in dm_integrity_init() error path Otherwise the journal_io_cache will leak if dm_register_target() fails.
- https://git.kernel.org/stable/c/3877b5c1509b16eeb1f275228fd91789cd88cf17
- https://git.kernel.org/stable/c/44f29e93a55b544dc961b6f8b4e93abaeaafb9ee
- https://git.kernel.org/stable/c/6b79a428c02769f2a11f8ae76bf866226d134887
- https://git.kernel.org/stable/c/6d126899b0747305c9d39a0bcf87e0df9c3f555b
- https://git.kernel.org/stable/c/a5d8c6bf58e5b2e70fbc15f3b08dfc1ba6f269ac
- https://git.kernel.org/stable/c/c8c9c50268729bf35f6c9bb1205f490db920454e
- https://git.kernel.org/stable/c/ca8b634fdf07dee3f6dfde57079c4511480b525e
- https://git.kernel.org/stable/c/e09a592fdd6c716506774bdbebb5f6c537b47767
- https://git.kernel.org/stable/c/ff4d6b5b38429a7731e5593680d2138bf74dd546
Modified: 2026-02-05
CVE-2023-53624
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_fq: fix integer overflow of "credit" if sch_fq is configured with "initial quantum" having values greater than INT_MAX, the first assignment of "credit" does signed integer overflow to a very negative value. In this situation, the syzkaller script provided by Cristoph triggers the CPU soft-lockup warning even with few sockets. It's not an infinite loop, but "credit" wasn't probably meant to be minus 2Gb for each new flow. Capping "initial quantum" to INT_MAX proved to fix the issue. v2: validation of "initial quantum" is done in fq_policy, instead of open coding in fq_change() _ suggested by Jakub Kicinski
- https://git.kernel.org/stable/c/2322462d6f9ad4874f4e3c63df3b5cc00cb1acbd
- https://git.kernel.org/stable/c/4b8a05e3801661a0438fcd0cdef181030d966a5a
- https://git.kernel.org/stable/c/4fbefeab88c6e79753a25099d455d3d59d2946b4
- https://git.kernel.org/stable/c/7041101ff6c3073fd8f2e99920f535b111c929cb
- https://git.kernel.org/stable/c/85f24cb2f10b2b0f2882e5786a09b4790bb3a0ad
- https://git.kernel.org/stable/c/d0b43125ec892aeb1b03e5df5aab595097da225a
Modified: 2026-02-03
CVE-2023-53639
In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: reduce WARN to dev_dbg() in callback The warn is triggered on a known race condition, documented in the code above the test, that is correctly handled. Using WARN() hinders automated testing. Reducing severity.
- https://git.kernel.org/stable/c/0d1792c98351b7c8ebdc53d052918e77d1e512c3
- https://git.kernel.org/stable/c/1300517e371e4d0acdb0f1237477e1ed223c3a9a
- https://git.kernel.org/stable/c/484d95c69fc1143f09e4c2e3b89019d68d190a92
- https://git.kernel.org/stable/c/644df7e865e76ab7a62c67c25cbbc093c944d0ef
- https://git.kernel.org/stable/c/6f93154d61b345acbc405c6dee16afb845eb298e
- https://git.kernel.org/stable/c/75c4a8154cb6c7239fb55d5550f481f6765fb83c
- https://git.kernel.org/stable/c/cbec770521ebc455c9811a23222faf8911422d4a
- https://git.kernel.org/stable/c/e7865f84adaf75cee1a4bbf79680329eca92b4e1
- https://git.kernel.org/stable/c/f2a429e6da37e32438a9adc250cc176a889c16a4
Modified: 2026-02-03
CVE-2023-53641
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: fix memory leak of remain_skbs hif_dev->remain_skb is allocated and used exclusively in ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is processed and subsequently freed (in error paths) only during the next call of ath9k_hif_usb_rx_stream(). So, if the urbs are deallocated between those two calls due to the device deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream() is not called next time and the allocated remain_skb is leaked. Our local Syzkaller instance was able to trigger that. remain_skb makes sense when receiving two consecutive urbs which are logically linked together, i.e. a specific data field from the first skb indicates a cached skb to be allocated, memcpy'd with some data and subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs deallocation supposedly makes that link irrelevant so we need to free the cached skb in those cases. Fix the leak by introducing a function to explicitly free remain_skb (if it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL when it has not been allocated at all (hif_dev struct is kzalloced) or when it has been processed in next call to ath9k_hif_usb_rx_stream(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/320d760a35273aa815d58b57e4fd9ba5279a3489
- https://git.kernel.org/stable/c/59073060fe0950c6ecbe12bdc06469dcac62128d
- https://git.kernel.org/stable/c/6719e3797ec52cd144c8a5ba8aaab36674800585
- https://git.kernel.org/stable/c/7654cc03eb699297130b693ec34e25f77b17c947
- https://git.kernel.org/stable/c/8f02d538878c9b1501f624595eb22ee4e5e0ff84
- https://git.kernel.org/stable/c/9b9356a3014123f0ce4b50d9278c1265173150ab
- https://git.kernel.org/stable/c/d9899318660791141ea6002fda5577b2c5d7386e
- https://git.kernel.org/stable/c/f0931fc8f4b6847c72e170d2326861c0a081d680
Modified: 2026-02-03
CVE-2023-53644
In the Linux kernel, the following vulnerability has been resolved:
media: radio-shark: Add endpoint checks
The syzbot fuzzer was able to provoke a WARNING from the radio-shark2
driver:
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7
RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac
RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001
R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/2b580d0f03c4fc00013cd08f9ed96b87a08fd0d9
- https://git.kernel.org/stable/c/3ed6a312ac1e7278f92b1b3d95377b335ae21e89
- https://git.kernel.org/stable/c/4c3057a1927fa0b9ed8948b6f3b56b4ff9fa63d3
- https://git.kernel.org/stable/c/53764a17f5d8f0d00b13297d06b5e65fa844288b
- https://git.kernel.org/stable/c/76e31045ba030e94e72105c01b2e98f543d175ac
- https://git.kernel.org/stable/c/8a30dce9d7f70f8438956f6a01142b926c301334
- https://git.kernel.org/stable/c/afd72825b4fcb7ae4015e1c93b054f4c37a25684
- https://git.kernel.org/stable/c/b1bde4b4360c3d8a35504443efabd3243b802805
Modified: 2026-02-03
CVE-2023-53655
In the Linux kernel, the following vulnerability has been resolved: rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed Registering a kprobe on __rcu_irq_enter_check_tick() can cause kernel stack overflow as shown below. This issue can be reproduced by enabling CONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=", and then giving the following commands at the shell prompt: # cd /sys/kernel/tracing/ # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events # echo 1 > events/kprobes/enable This commit therefore adds __rcu_irq_enter_check_tick() to the kprobes blacklist using NOKPROBE_SYMBOL(). Insufficient stack space to handle exception! ESR: 0x00000000f2000004 -- BRK (AArch64) FAR: 0x0000ffffccf3e510 Task stack: [0xffff80000ad30000..0xffff80000ad38000] IRQ stack: [0xffff800008050000..0xffff800008058000] Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310] CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19 Hardware name: linux,dummy-virt (DT) pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __rcu_irq_enter_check_tick+0x0/0x1b8 lr : ct_nmi_enter+0x11c/0x138 sp : ffff80000ad30080 x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000 x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148 x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c x14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809 x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000 x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001 x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4 x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000 Kernel panic - not syncing: kernel stack overflow CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0xf8/0x108 show_stack+0x20/0x30 dump_stack_lvl+0x68/0x84 dump_stack+0x1c/0x38 panic+0x214/0x404 add_taint+0x0/0xf8 panic_bad_stack+0x144/0x160 handle_bad_stack+0x38/0x58 __bad_stack+0x78/0x7c __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 [...] el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 el1_interrupt+0x28/0x60 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68 __ftrace_set_clr_event_nolock+0x98/0x198 __ftrace_set_clr_event+0x58/0x80 system_enable_write+0x144/0x178 vfs_write+0x174/0x738 ksys_write+0xd0/0x188 __arm64_sys_write+0x4c/0x60 invoke_syscall+0x64/0x180 el0_svc_common.constprop.0+0x84/0x160 do_el0_svc+0x48/0xe8 el0_svc+0x34/0xd0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x190/0x194 SMP: stopping secondary CPUs Kernel Offset: 0x28da86000000 from 0xffff800008000000 PHYS_OFFSET: 0xfffff76600000000 CPU features: 0x00000,01a00100,0000421b Memory Limit: none
- https://git.kernel.org/stable/c/4c3d1a6720aefb02403ddfebe85db521d3af2c3b
- https://git.kernel.org/stable/c/7a29fb4a4771124bc61de397dbfc1554dbbcc19c
- https://git.kernel.org/stable/c/7b5a97333e920b69356e097f185bdc51d61e66ee
- https://git.kernel.org/stable/c/93b6295f677d96b73cfcb703532f6c7369a60d96
- https://git.kernel.org/stable/c/c8a3341b339285495cf7c8d061d659465f2311e0
- https://git.kernel.org/stable/c/eb18bc5a8678f431c500e6da1b8b5f34478d5bc1
Modified: 2026-02-26
CVE-2023-53667
In the Linux kernel, the following vulnerability has been resolved:
net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize
Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.
For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
size = SKB_DATA_ALIGN(size);
size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")
Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).
However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).
Consequently the SKB bounds checking semantics fails and panics:
skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:
- https://git.kernel.org/stable/c/2334ff0b343ba6ba7a6c0586fcc83992bbbc1776
- https://git.kernel.org/stable/c/42b78c8cc774b47023d6d16d96d54cc7015e4a07
- https://git.kernel.org/stable/c/6147745d43ff4e0d2c542e5b93e398ef0ee4db00
- https://git.kernel.org/stable/c/72d0240b0ee4794efc683975c213e4b384fea733
- https://git.kernel.org/stable/c/7e01c7f7046efc2c7c192c3619db43292b98e997
- https://git.kernel.org/stable/c/9be921854e983a81a0aeeae5febcd87093086e46
- https://git.kernel.org/stable/c/bf415bfe7573596ac213b4fd1da9e62cfc9a9413
- https://git.kernel.org/stable/c/ff484163dfb61b58f23e4dbd007de1094427669c
Modified: 2026-02-26
CVE-2023-53683
In the Linux kernel, the following vulnerability has been resolved: fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode() syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), for crafted filesystem image can contain bogus length. There conditions are not kernel bugs that can justify kernel to panic.
- https://git.kernel.org/stable/c/37cab61a52d6f42b2d961c51bcf369f09e235fb5
- https://git.kernel.org/stable/c/3a9d68d84b2e41ba3f2a727b36f035fad6800492
- https://git.kernel.org/stable/c/48960a503fcec76d3f72347b7e679dda08ca43be
- https://git.kernel.org/stable/c/61af77acd039ffd221bf7adf0dc95d0a4d377505
- https://git.kernel.org/stable/c/81b21c0f0138ff5a499eafc3eb0578ad2a99622c
- https://git.kernel.org/stable/c/a75d9211a07fed513c08c5d4861c4a36ac6a74fe
- https://git.kernel.org/stable/c/c074913b12db3632b11588b31bbfb0fa80a0a1c9
- https://git.kernel.org/stable/c/c8daee66585897a4c90d937c91e762100237bff9
Closed bugs
Упаковать без modprobe.d/blacklist-e1000e.conf
Ошибка sysctl: reading key "net.ipv4.tcp_min_tso_segs": Недопустимый аргумент
Package kernel-image-un-def updated to version 6.1.34-alt1 for branch p10 in task 323044.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2023-00644
Уязвимость драйвера DVB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2025-08-19
BDU:2023-00645
Уязвимость драйвера DVB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-12-24
BDU:2023-01278
Уязвимость функции parse_lease_state() (fs/ksmbd/oplock.c) подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-19
BDU:2023-01734
Уязвимость функции ntfs_read_mft() в модуле fs/ntfs3/inode.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-01-09
BDU:2023-02580
Уязвимость реализации протокола IPv6 RPL ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03498
Уязвимость функции fl_set_geneve_opt() в модуле net/sched/cls_flower.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии.
Modified: 2025-02-27
BDU:2023-03952
Уязвимость функции ksmbd_conn_handler_loop() в модуле fs/smb/server/connection.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2025-02-27
BDU:2023-03956
Уязвимость функции deassemble_neg_contexts() в модуле fs/smb/server/smb2pdu.c файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.
Modified: 2024-11-21
CVE-2022-45886
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_net.c has a .disconnect versus dvb_device_open race condition that leads to a use-after-free.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4172385b0c9ac366dcab78eda48c26814b87ed1a
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-3-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4172385b0c9ac366dcab78eda48c26814b87ed1a
- https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/
- https://lore.kernel.org/linux-media/20221115131822.6640-3-imv4bel%40gmail.com/
- https://security.netapp.com/advisory/ntap-20230113-0006/
Modified: 2024-11-21
CVE-2022-45919
An issue was discovered in the Linux kernel through 6.0.10. In drivers/media/dvb-core/dvb_ca_en50221.c, a use-after-free can occur is there is a disconnect after an open, because of the lack of a wait_event.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=280a8ab81733da8bc442253c700a52c4c0886ffd
- https://lore.kernel.org/linux-media/20221121063308.GA33821%40ubuntu/T/#u
- https://security.netapp.com/advisory/ntap-20230113-0008/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=280a8ab81733da8bc442253c700a52c4c0886ffd
- https://lore.kernel.org/linux-media/20221121063308.GA33821%40ubuntu/T/#u
- https://security.netapp.com/advisory/ntap-20230113-0008/
Modified: 2025-05-16
CVE-2022-48425
In the Linux kernel through 6.2.7, fs/ntfs3/inode.c has an invalid kfree because it does not validate MFT flags before replaying logs.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=467333af2f7b95eeaa61a5b5369a80063cd971fd
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd
- https://security.netapp.com/advisory/ntap-20230413-0006/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=467333af2f7b95eeaa61a5b5369a80063cd971fd
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd
- https://security.netapp.com/advisory/ntap-20230413-0006/
Modified: 2025-03-20
CVE-2023-1194
An out-of-bounds (OOB) memory read flaw was found in parse_lease_state in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. When an attacker sends the CREATE command with a malformed payload to KSMBD, due to a missing check of `NameOffset` in the `parse_lease_state()` function, the `create_context` object can access invalid memory.
- https://access.redhat.com/security/cve/CVE-2023-1194
- https://bugzilla.redhat.com/show_bug.cgi?id=2154176
- https://security.netapp.com/advisory/ntap-20231221-0006/
- https://www.spinics.net/lists/stable-commits/msg303065.html
- https://access.redhat.com/security/cve/CVE-2023-1194
- https://bugzilla.redhat.com/show_bug.cgi?id=2154176
- https://security.netapp.com/advisory/ntap-20231221-0006/
- https://www.spinics.net/lists/stable-commits/msg303065.html
Modified: 2024-11-21
CVE-2023-2156
A flaw was found in the networking subsystem of the Linux kernel within the handling of the RPL protocol. This issue results from the lack of proper handling of user-supplied data, which can lead to an assertion failure. This may allow an unauthenticated remote attacker to create a denial of service condition on the system.
- http://www.openwall.com/lists/oss-security/2023/05/17/8
- http://www.openwall.com/lists/oss-security/2023/05/17/9
- http://www.openwall.com/lists/oss-security/2023/05/18/1
- http://www.openwall.com/lists/oss-security/2023/05/19/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2196292
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://security.netapp.com/advisory/ntap-20230622-0001/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5453
- https://www.zerodayinitiative.com/advisories/ZDI-23-547/
- http://www.openwall.com/lists/oss-security/2023/05/17/8
- http://www.openwall.com/lists/oss-security/2023/05/17/9
- http://www.openwall.com/lists/oss-security/2023/05/18/1
- http://www.openwall.com/lists/oss-security/2023/05/19/1
- https://bugzilla.redhat.com/show_bug.cgi?id=2196292
- https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html
- https://security.netapp.com/advisory/ntap-20230622-0001/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5453
- https://www.zerodayinitiative.com/advisories/ZDI-23-547/
Modified: 2025-05-05
CVE-2023-35788
An issue was discovered in fl_set_geneve_opt in net/sched/cls_flower.c in the Linux kernel before 6.3.7. It allows an out-of-bounds write in the flower classifier code via TCA_FLOWER_KEY_ENC_OPTS_GENEVE packets. This may result in denial of service or privilege escalation.
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://www.openwall.com/lists/oss-security/2023/06/17/1
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.7
- https://git.kernel.org/linus/4d56304e5827c8cc8cc18c75343d283af7c4825c
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230714-0002/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/06/07/1
- http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html
- http://www.openwall.com/lists/oss-security/2023/06/17/1
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.7
- https://git.kernel.org/linus/4d56304e5827c8cc8cc18c75343d283af7c4825c
- https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://security.netapp.com/advisory/ntap-20230714-0002/
- https://www.debian.org/security/2023/dsa-5448
- https://www.debian.org/security/2023/dsa-5480
- https://www.openwall.com/lists/oss-security/2023/06/07/1
Modified: 2025-05-05
CVE-2023-38427
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/smb2pdu.c in ksmbd has an integer underflow and out-of-bounds read in deassemble_neg_contexts.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b
- https://security.netapp.com/advisory/ntap-20230824-0011/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b
- https://security.netapp.com/advisory/ntap-20230824-0011/
Modified: 2024-11-21
CVE-2023-38431
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/connection.c in ksmbd does not validate the relationship between the NetBIOS header's length field and the SMB header sizes, via pdu_size in ksmbd_conn_handler_loop, leading to an out-of-bounds read.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=368ba06881c395f1c9a7ba22203cf8d78b4addc0
- https://security.netapp.com/advisory/ntap-20230824-0011/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=368ba06881c395f1c9a7ba22203cf8d78b4addc0
- https://security.netapp.com/advisory/ntap-20230824-0011/
