ALT-BU-2025-10499-13
Branch c10f2 update bulletin.
Closed vulnerabilities
Modified: 2025-11-06
BDU:2025-09847
Уязвимость функции PS_Lvl2page() библиотеки LibTIFF, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-03
BDU:2025-13919
Уязвимость функции get_histogram библиотеки LibTIFF, позволяющая нарушителю выполнить произвольный код
Modified: 2025-12-03
BDU:2025-13920
Уязвимость функции setrow библиотеки LibTIFF, позволяющая нарушителю выполнить произвольный код
Modified: 2026-04-29
CVE-2025-8176
A vulnerability was found in LibTIFF up to 4.7.0. It has been declared as critical. This vulnerability affects the function get_histogram of the file tools/tiffmedian.c. The manipulation leads to use after free. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The patch is identified as fe10872e53efba9cc36c66ac4ab3b41a839d5172. It is recommended to apply a patch to fix this issue.
- http://www.libtiff.org/
- https://gitlab.com/libtiff/libtiff/-/commit/fe10872e53efba9cc36c66ac4ab3b41a839d5172
- https://gitlab.com/libtiff/libtiff/-/issues/707
- https://gitlab.com/libtiff/libtiff/-/merge_requests/727
- https://vuldb.com/?ctiid.317590
- https://vuldb.com/?id.317590
- https://vuldb.com/?submit.621796
Modified: 2025-09-11
CVE-2025-8177
A vulnerability was found in LibTIFF up to 4.7.0. It has been rated as critical. This issue affects the function setrow of the file tools/thumbnail.c. The manipulation leads to buffer overflow. An attack has to be approached locally. The patch is named e8c9d6c616b19438695fd829e58ae4fde5bfbc22. It is recommended to apply a patch to fix this issue. This vulnerability only affects products that are no longer supported by the maintainer.
- http://www.libtiff.org/
- https://gitlab.com/libtiff/libtiff/-/commit/e8c9d6c616b19438695fd829e58ae4fde5bfbc22
- https://gitlab.com/libtiff/libtiff/-/issues/715
- https://gitlab.com/libtiff/libtiff/-/merge_requests/737
- https://vuldb.com/?ctiid.317591
- https://vuldb.com/?id.317591
- https://vuldb.com/?submit.621797
- https://gitlab.com/libtiff/libtiff/-/issues/715
- https://vuldb.com/?submit.621797
Modified: 2026-04-29
CVE-2025-8534
A vulnerability classified as problematic was found in libtiff 4.6.0. This vulnerability affects the function PS_Lvl2page of the file tools/tiff2ps.c of the component tiff2ps. The manipulation leads to null pointer dereference. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 6ba36f159fd396ad11bf6b7874554197736ecc8b. It is recommended to apply a patch to fix this issue. One of the maintainers explains, that "[t]his error only occurs if DEFER_STRILE_LOAD (defer-strile-load:BOOL=ON) or TIFFOpen( .. "rD") option is used."
- http://www.libtiff.org/
- https://drive.google.com/file/d/15JPA3kLYiYD-nRNJ8y8HmnYjhv9NE7k6/view?usp=drive_link
- https://gitlab.com/libtiff/libtiff/-/commit/6ba36f159fd396ad11bf6b7874554197736ecc8b
- https://gitlab.com/libtiff/libtiff/-/issues/718
- https://gitlab.com/libtiff/libtiff/-/merge_requests/746
- https://vuldb.com/?ctiid.318664
- https://vuldb.com/?id.318664
- https://vuldb.com/?submit.617831
- https://gitlab.com/libtiff/libtiff/-/issues/718
- https://vuldb.com/?submit.617831
Package python3-module-pip updated to version 23.3.2-alt1 for branch c10f2 in task 392412.
Closed vulnerabilities
Modified: 2026-02-10
BDU:2023-08026
Уязвимость модуля pip языка программирования Python, связанная с непринятием мер по чистке данных на управляющем уровне, позволяющая нарушителю изменить конфигурацию репозитория
Modified: 2025-11-03
CVE-2023-5752
When installing a package from a Mercurial VCS URL (ie "pip install hg+...") with pip prior to v23.3, the specified Mercurial revision could be used to inject arbitrary configuration options to the "hg clone" call (ie "--config"). Controlling the Mercurial configuration can modify how and which repository is installed. This vulnerability does not affect users who aren't installing from Mercurial.
- https://github.com/pypa/pip/pull/12306
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/622OZXWG72ISQPLM5Y57YCVIMWHD4C3U/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/65UKKF5LBHEFDCUSPBHUN4IHYX7SRMHH/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FXUVMJM25PUAZRQZBF54OFVKTY3MINPW/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KFC2SPFG5FLCZBYY2K3T5MFW2D22NG6E/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YBSB3SUPQ3VIFYUMHPO3MEQI4BJAXKCZ/
- https://mail.python.org/archives/list/security-announce@python.org/thread/F4PL35U6X4VVHZ5ILJU3PWUWN7H7LZXL/
- https://github.com/pypa/pip/pull/12306
- https://lists.debian.org/debian-lts-announce/2025/10/msg00028.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/622OZXWG72ISQPLM5Y57YCVIMWHD4C3U/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/65UKKF5LBHEFDCUSPBHUN4IHYX7SRMHH/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FXUVMJM25PUAZRQZBF54OFVKTY3MINPW/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KFC2SPFG5FLCZBYY2K3T5MFW2D22NG6E/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YBSB3SUPQ3VIFYUMHPO3MEQI4BJAXKCZ/
- https://mail.python.org/archives/list/security-announce@python.org/thread/F4PL35U6X4VVHZ5ILJU3PWUWN7H7LZXL/
Closed vulnerabilities
Modified: 2025-06-24
BDU:2025-06002
Уязвимость платформы для мониторинга и наблюдения Grafana, связанная с ошибками разграничения доступа, позволяющая нарушителю нарушить работу программы
Modified: 2025-11-26
BDU:2025-06809
Уязвимость компонента Custom Frontend Plugin платформы для мониторинга и наблюдения Grafana, позволяющая нарушителю осуществлять межсайтовые сценарные атаки (XSS)
Modified: 2025-08-01
BDU:2025-08873
Уязвимость службы оповещения Alerts & IRM платформы для мониторинга и наблюдения Grafana, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2025-08-01
BDU:2025-08910
Уязвимость платформы для мониторинга и наблюдения Grafana, связанная с непринятием мер по защите структуры веб-страницы, позволяющая нарушителю осуществлять межсайтовые сценарные атаки (XSS)
BDU:2025-09887
Уязвимость компонента OSS Organization Switching платформы для мониторинга и наблюдения Grafana, позволяющая нарушителю перенаправить пользователя на произвольный сайт
Modified: 2026-04-01
BDU:2026-04159
Уязвимость функции SQL Expressions платформы для мониторинга и наблюдения Grafana, позволяющая нарушителю выполнить произвольный код и получить несанкционированный доступ к платформе
Modified: 2026-04-15
CVE-2025-3415
Grafana is an open-source platform for monitoring and observability. The Grafana Alerting DingDing integration was not properly protected and could be exposed to users with Viewer permission. Fixed in versions 10.4.19+security-01, 11.2.10+security-01, 11.3.7+security-01, 11.4.5+security-01, 11.5.5+security-01, 11.6.2+security-01 and 12.0.1+security-01
Modified: 2026-04-15
CVE-2025-3580
An access control vulnerability was discovered in Grafana OSS where an Organization administrator could permanently delete the Server administrator account. This vulnerability exists in the DELETE /api/org/users/ endpoint. The vulnerability can be exploited when: 1. An Organization administrator exists 2. The Server administrator is either: - Not part of any organization, or - Part of the same organization as the Organization administrator Impact: - Organization administrators can permanently delete Server administrator accounts - If the only Server administrator is deleted, the Grafana instance becomes unmanageable - No super-user permissions remain in the system - Affects all users, organizations, and teams managed in the instance The vulnerability is particularly serious as it can lead to a complete loss of administrative control over the Grafana instance.
Modified: 2026-04-29
CVE-2025-4123
A cross-site scripting (XSS) vulnerability exists in Grafana caused by combining a client path traversal and open redirect. This allows attackers to redirect users to a website that hosts a frontend plugin that will execute arbitrary JavaScript. This vulnerability does not require editor permissions and if anonymous access is enabled, the XSS will work. If the Grafana Image Renderer plugin is installed, it is possible to exploit the open redirect to achieve a full read SSRF. The default Content-Security-Policy (CSP) in Grafana will block the XSS though the `connect-src` directive.
Modified: 2026-04-15
CVE-2025-6023
An open redirect vulnerability has been identified in Grafana OSS that can be exploited to achieve XSS attacks. The vulnerability was introduced in Grafana v11.5.0. The open redirect can be chained with path traversal vulnerabilities to achieve XSS. Fixed in versions 12.0.2+security-01, 11.6.3+security-01, 11.5.6+security-01, 11.4.6+security-01 and 11.3.8+security-01
Modified: 2026-04-15
CVE-2025-6197
An open redirect vulnerability has been identified in Grafana OSS organization switching functionality. Prerequisites for exploitation: - Multiple organizations must exist in the Grafana instance - Victim must be on a different organization than the one specified in the URL
Modified: 2026-04-02
CVE-2026-27876
A chained attack via SQL Expressions and a Grafana Enterprise plugin can lead to a remote arbitrary code execution impact (RCE). This is enabled by a feature in Grafana (OSS), so all users are always recommended to update to avoid future attack vectors going this path. Only instances with the sqlExpressions feature toggle enabled are vulnerable. Only instances in the following version ranges are affected: - 11.6.0 (inclusive) to 11.6.14 (exclusive): 11.6.14 has the fix. 11.5 and below are not affected. - 12.0.0 (inclusive) to 12.1.10 (exclusive): 12.1.10 has the fix. 12.0 did not receive an update, as it is end-of-life. - 12.2.0 (inclusive) to 12.2.8 (exclusive): 12.2.8 has the fix. - 12.3.0 (inclusive) to 12.3.6 (exclusive): 12.3.6 has the fix. - 12.4.0 (inclusive) to 12.4.2 (exclusive): 12.4.2 has the fix. 13.0.0 and above also have the fix: no v13 release is affected.
Modified: 2026-03-31
CVE-2026-27880
The OpenFeature feature toggle evaluation endpoint reads unbounded values into memory, which can cause out-of-memory crashes.
Modified: 2025-07-23
GHSA-46m5-8hpj-p5p5
Grafana's insecure DingDing Alert integration exposes sensitive information
- https://nvd.nist.gov/vuln/detail/CVE-2025-3415
- https://github.com/grafana/grafana/commit/04111e9f2afd95ea3e5b01865cc29d3fc1198e71
- https://github.com/grafana/grafana/commit/0adb869188fa2b9ae26efd424b94e17189538f29
- https://github.com/grafana/grafana/commit/19c912476d4f7a81e8a3562668bc38f31b909e18
- https://github.com/grafana/grafana/commit/4144c636d1a6d0b17fafcf7a2c40fa403542202a
- https://github.com/grafana/grafana/commit/4fc33647a8297d3a0aae04a5fcbac883ceb6a655
- https://github.com/grafana/grafana/commit/910eb1dd9e618014c6b1d2a99a431b99d4268c05
- https://github.com/grafana/grafana/commit/91327938626c9426e481e6294850af7b61415c98
- https://github.com/grafana/grafana/commit/a78de30720b4f33c88d0c1a973e693ebf3831717
- https://github.com/grafana/grafana
- https://grafana.com/security/security-advisories/cve-2025-3415
Modified: 2025-07-21
GHSA-q53q-gxq9-mgrj
Grafana Cross-Site-Scripting (XSS) via custom loaded frontend plugin
- https://nvd.nist.gov/vuln/detail/CVE-2025-4123
- https://github.com/grafana/grafana/commit/c7a690348df761d41b659224cbc50a46a0c0e4cc
- https://github.com/grafana/grafana
- https://grafana.com/blog/2025/05/23/grafana-security-release-medium-and-high-severity-security-fixes-for-cve-2025-4123-and-cve-2025-3580
- https://grafana.com/security/security-advisories/cve-2025-4123
- https://pkg.go.dev/vuln/GO-2025-3702
Modified: 2025-07-20
GHSA-vqph-p5vc-g644
Grafana is vulnerable to XSS attacks through open redirects and path traversal
- https://nvd.nist.gov/vuln/detail/CVE-2025-6023
- https://github.com/grafana/grafana/commit/0ba0b99665a946cd96676ef85ec8bc83028cb1d7
- https://github.com/grafana/grafana/commit/40ed88fe86d347bcde5ddaed6c4a20a95d2f0d55
- https://github.com/grafana/grafana/commit/5b00e21638f565eed46acb4d0b7c009968df4c3b
- https://github.com/grafana/grafana/commit/b6dd2b70c655c61b111b328f1a7dcca6b3954936
- https://github.com/grafana/grafana/commit/e0ba4b480954f8a33aa2cff3229f6bcc05777bd9
- https://github.com/grafana/grafana
- https://grafana.com/blog/2025/07/17/grafana-security-release-medium-and-high-severity-fixes-for-cve-2025-6197-and-cve-2025-6023
- https://grafana.com/security/security-advisories/cve-2025-6023
Package kernel-image-6.12 updated to version 6.12.41-alt0.c10f.2 for branch c10f2 in task 392253.
Closed vulnerabilities
Modified: 2026-03-04
BDU:2025-04823
Уязвимость функций drm_fbdev_dma_helper_fb_dirty(), drm_fbdev_dma_driver_fbdev_probe_tail() и drm_fbdev_dma_driver_fbdev_probe() (drivers/gpu/drm/drm_fbdev_dma.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-08271
Уязвимость функции tb_cfg_request_dequeue() модуля drivers/thunderbolt/ctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-08507
Уязвимость функции dev_loss_tmo_callbk() модуля drivers/scsi/lpfc/lpfc_hbadisc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08508
Уязвимость функции COMP_DUMMY() модуля sound/soc/mediatek/mt8195/mt8195-mt6359.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08509
Уязвимость функции ath11k_core_halt() модуля drivers/net/wireless/ath/ath11k/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08510
Уязвимость функции sun8i_ce_cipher_prepare() модуля drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08622
Уязвимость модуля kernel/trace/bpf_trace.c подсистемы BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08626
Уязвимость функции em_compute_costs() модуля kernel/power/energy_model.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08627
Уязвимость функции smp_processor_id() модуля drivers/perf/amlogic/meson_ddr_pmu_core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08628
Уязвимость функции smp_processor_id() модуля drivers/scsi/smartpqi/smartpqi_init.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08629
Уязвимость функции ath12k_core_halt() модуля drivers/net/wireless/ath/ath12k/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-08630
Уязвимость функции smp_processor_id() модуля drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08632
Уязвимость функции ath12k_dp_rx_msdu_coalesce() модуля drivers/net/wireless/ath/ath12k/dp_rx.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08706
Уязвимость компонента bus ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-13
BDU:2025-08788
Уязвимость функции btrfs_prelim_ref() модуля include/trace/events/btrfs.h ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08789
Уязвимость модуля drivers/net/vxlan/vxlan_core.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации
Modified: 2025-08-27
BDU:2025-08790
Уязвимость модуля arch/x86/power/cpu.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08792
Уязвимость функции virtqueue_enable_cb_delayed() модуля drivers/virtio/virtio_ring.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08793
Уязвимость драйвера TTY ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08794
Уязвимость функции nfs_return_empty_folio() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08795
Уязвимость функции fbnic_mbx_map_msg() модуля drivers/net/ethernet/meta/fbnic/fbnic_fw.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08796
Уязвимость функции software_node_get_reference_args() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
Modified: 2026-03-19
BDU:2025-08802
Уязвимость функции acpi_ps_complete_final_op() модуля drivers/acpi/acpica/psobject.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08803
Уязвимость функции atm_dev_deregister() (net/atm/resources.c) операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-08805
Уязвимость функции smb_extract_folioq_to_rdma() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-08806
Уязвимость функции dev_put() модуля net/atm/lec.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-08807
Уязвимость модуля fs/f2fs/inode.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08915
Уязвимость функции tipc_aead_encrypt_done() модуля net/tipc/crypto.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08916
Уязвимость модуля drivers/media/usb/cx231xx/cx231xx-417.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08917
Уязвимость модуля drivers/firmware/arm_ffa/bus.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-08918
Уязвимость функции set_boost() модуля drivers/cpufreq/amd-pstate.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-27
BDU:2025-08920
Уязвимость функции core::fmt::write() модуля arch/x86/Kconfig ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-08922
Уязвимость функции WARN_ON() модуля drivers/net/ethernet/mellanox/mlx5/core/en_main.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-08923
Уязвимость модуля drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.cc ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-08924
Уязвимость функции regs_get_kernel_stack_nth() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-08926
Уязвимость функции eir_create_adv_data() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08927
Уязвимость функции eir_get_service_data() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-08997
Уязвимость функции __io_uring_show_fdinfo() компонента io_uring ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-08999
Уязвимость функции idr_for_each() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09001
Уязвимость модуля drivers/net/wwan/t7xx/t7xx_netdev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09002
Уязвимость функции ufshcd_err_handling_prepare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09003
Уязвимость функции mgmt_remove_adv_monitor_complete() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09004
Уязвимость функции gve_alloc_pending_packet() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09006
Уязвимость функции queue_work() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09017
Уязвимость функции macb_halt_tx() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09020
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09023
Уязвимость функции smp_store_mb() компонента dma-buf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09024
Уязвимость функции IWL_EXPORT_SYMBOL() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09025
Уязвимость функции io_bitmap_exit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09026
Уязвимость функций ring_buffer_subbuf_order_set(), atomic_dec() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-09029
Уязвимость функции create_validate_stream_for_sink() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09031
Уязвимость компонента espintcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09033
Уязвимость функции init_nfsd() в модуле fs/nfsd/nfsctl.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09034
Уязвимость функции n_channels() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09036
Уязвимость функции bpf_iter_scx_dsq_new() компонента sched_ext ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09037
Уязвимость функции idxd_alloc() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09038
Уязвимость функции uclogic_input_configured() компонента HID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09039
Уязвимость функции mt76_dma_cleanup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09040
Уязвимость функций static_branch_enc(),static_branch_dec() компонента page_alloc ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-09041
Уязвимость функции f2fs_new_node_page() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-09042
Уязвимость функции mctp_dump_addrinfo() компонента net ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-13
BDU:2025-09044
Уязвимость функции reference_count bias_pad_enable() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии в системе
Modified: 2026-03-13
BDU:2025-09045
Уязвимость функции hid_bpf_destroy_device() компонента HID ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-09
BDU:2025-09046
Уязвимость функции amdgpu_unmap_static_csa() в модуле drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c драйвера инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09047
Уязвимость компонента seg6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-19
BDU:2025-09048
Уязвимость функции atomctrl_initialize_mc_reg_table() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09050
Уязвимость функции parse_int_array() компонента ASoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09053
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю повредить память
Modified: 2026-03-19
BDU:2025-09058
Уязвимость функции platform_set_drvdata() компонента perf ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-18
BDU:2025-09059
Уязвимость функции fb_cvt_hperiod() компонента fbdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09063
Уязвимость функции btintel_dsbr() компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09122
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-09123
Уязвимость функции rproc_handle_resources() компонента remoteproc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-09124
Уязвимость функции try_module_get() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-09125
Уязвимость функции rproc_attach() компонента remoteproc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-09127
Уязвимость функции xsk_pool_get_rx_frame_size() компонента virtio-net ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-19
BDU:2025-09128
Уязвимость функции put_unused_fd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09130
Уязвимость функции drm_sched_entity_push_job() компонента msm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09131
Уязвимость функции kzalloc() компонента irq_sim ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-09132
Уязвимость функции pcpu_alloc_noprof() компонента ice ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-09134
Уязвимость функции squashfs_fill_super() компонента Squashfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-16
BDU:2025-09137
Уязвимость функции carl9170_usb_rx_complete() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09139
Уязвимость функции __xa_store() и __xa_erase() модуля drivers/infiniband/hw/mlx5/odp.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09140
Уязвимость функции xdp_linearize_page() модуля drivers/net/virtio_net.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09143
Уязвимость модулей drivers/gpu/drm/v3d/v3d_drv.h, drivers/gpu/drm/v3d/v3d_gem.c и drivers/gpu/drm/v3d/v3d_irq.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-09144
Уязвимость модуля drivers/usb/chipidea/udc.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-09145
Уязвимость функции notif_callback() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09159
Уязвимость функции XDP_REDIRECT() модуля drivers/net/ethernet/broadcom/bnxt/bnxt.c ядра операционных систем Linux, поволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09166
Уязвимость функции userfaultfd_move() модуля mm/userfaultfd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-09171
Уязвимость функции cs40l50_upload_owt() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09172
Уязвимость функции __inode_add_ref() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09174
Уязвимость функции i40e_clear_hw() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09175
Уязвимость функции htb_lookup_leaf() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09176
Уязвимость модуля drivers/net/usb/sierra_net.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09177
Уязвимость функции qfq_aggregate() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09178
Уязвимость функции insn_rw_emulate_bits() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09179
Уязвимость функции COMEDI_INSNLIST() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09180
Уязвимость модуля drivers/comedi/drivers/das6402.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09181
Уязвимость модуля drivers/comedi/drivers/das16m1.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09183
Уязвимость функции raid10_make_request() компонента raid10 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09185
Уязвимость функции devm_kstrdup() компонента ASoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09186
Уязвимость функции rtsn_probe() компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09187
Уязвимость функции gs_start_io() компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09190
Уязвимость функции raid1_reshape() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-19
BDU:2025-09194
Уязвимость функции ksmbd_iov_pin_rsp() компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09199
Уязвимость функции dma_unmap_len_set() компонента bnxt_en ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2026-03-19
BDU:2025-09225
Уязвимость функции nbd_genl_connect() компонента nbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09228
Уязвимость функции nf_flow_pppoe_proto() компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09230
Уязвимость функций mlx5e_dim_rx_change(), mlx5e_dim_tx_change() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09233
Уязвимость функции dma_buf_vmap() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09234
Уязвимость функции __clk_register() компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09235
Уязвимость функции bitmap_get_stats() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09242
Уязвимость модуля drivers/iio/industrialio-backend.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-09244
Уязвимость модуля drivers/infiniband/hw/mlx5/mr.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09245
Уязвимость функции mas_preallocate() модуля lib/maple_tree.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09246
Уязвимость модуля drivers/dma/idxd/cdev.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09250
Уязвимость функции drm_sched_entity_kill() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-09253
Уязвимость функции mhi_ep_ring_add_element() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-09255
Уязвимость файловой системы Btrfs (fs/btrfs/inode.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09314
Уязвимость функции do_change_type() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09521
Уязвимость функции napi_complete() компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09522
Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09576
Уязвимость функции snd_usb_get_audioformat_uac3() (sound/usb/stream.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09577
Уязвимость функции vhci_flush() библиотеки include/linux/skbuff.h компонента Bluetooth ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код, повысить свои привилегии или вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09589
Уязвимость функции cifs_signal_cifsd_for_reconnect() модуля fs/smb/client/cifsglob.h и fs/smb/client/connect.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09603
Уязвимость функции ptp_rate() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09604
Уязвимость функции page_pool_recycle_in_ring() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09605
Уязвимость модуля net/ipv4/udp_offload.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09606
Уязвимость модуля drivers/net/ethernet/intel/ice/ice_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09609
Уязвимость функции key_extract_l3l4 модуля net/openvswitch/flow.c компонента openvswitch ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09610
Уязвимость драйвера mlx5 подсистемы RDMA ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии, выполнить произвольный код или вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09611
Уязвимость функции phy_detach() модуля drivers/net/phy/phy_device.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-09613
Уязвимость функции cma_netevent_callback() модуля drivers/infiniband/core/cma.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09614
Уязвимость функции usbnet_read_cmd() библиотеки include/linux/etherdevice.h ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09615
Уязвимость функции cscfg_csdev_enable_active_config() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09616
Уязвимость функции total_valid_block_count библиотеки fs/f2fs/f2fs.h ядра операционных систем Linux, позволяющая наршителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09617
Уязвимость компонента net_sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-09618
Уязвимость функции v3d_job_update_stats() компонента File Descriptor Handler ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09619
Уязвимость функции CP_RESET_CONTEXT_STATE() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09620
Уязвимость функций bnxt_ulp_stop() и bnxt_ulp_start() драйвера RoCE ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09621
Уязвимость функции atmtcp_c_send() компонента atm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09622
Уязвимость функции netif_rx() файла net/ipv6/ip6_input.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09624
Уязвимость функции atm_account_tx() компонента atm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09626
Уязвимость функции ksmbd_krb5_authenticate() компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09627
Уязвимость функции usb_acpi_add_usb4_devlink() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09628
Уязвимость функции kmem_cache_destroy() модуля dswstate.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09630
Уязвимость функции mlb_usio_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09631
Уязвимость функции usbhs_probe() компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09632
Уязвимость функций udma_probe() и devm_kasprintf() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-09633
Уязвимость модуля drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09634
Уязвимость функции netfs_retry_write_stream() модуля fs/netfs/write_retry.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09635
Уязвимость функции dm_get_live_table() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-09636
Уязвимость функции read_string() компонента hwmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09638
Уязвимость функции wled_configure() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09640
Уязвимость функции txopt_get() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09641
Уязвимость модуля drivers/net/phy/mscc/mscc_ptp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09657
Уязвимость функции p54_rx_eeprom_readback() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09660
Уязвимость виртуального сетевого интерфейса TUN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09665
Уязвимость функции lan743x_ptp_io_event_clock_get() компонента net ядра операционной системы Linux, позволяющая нарушителю оказать влияние на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-16
BDU:2025-09670
Уязвимость функции unix_stream_read_generic() модуля net/unix/af_unix.c ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии, обойти существующие механизмы безопасности и выполнить произвольный код
Modified: 2025-10-24
BDU:2025-09672
Уязвимость компонента ublk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-09674
Уязвимость функций calipso_req_setattr() и calipso_req_delattr() компонента calipso ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09675
Уязвимость функции kernfs_should_drain_open_files() компонента kernfs ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию
Modified: 2026-03-18
BDU:2025-09676
Уязвимость функции tcpm_queue_vdm_unlocked() компонента DisplayPort Alt Mode Driver ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09677
Уязвимость функций backtrack_insn() и check_cond_jmp_op() файла kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09679
Уязвимость компонента octeontx2-pf файла net/core/net-sysfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09681
Уязвимость компонента ring-buffer файла kernel/trace/ring_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09683
Уязвимость функции bpf_prog_select_runtime() файла kernel/bpf/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09684
Уязвимость компонента mdiobus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-09720
Уязвимость функции do_exit() компонента perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09811
Уязвимость функции kvm_vm_ioctl_create_vcpu() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09812
Уязвимость функции ipmi_create_user() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09813
Уязвимость функции clip_push() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09814
Уязвимость функции to_atmarpd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09815
Уязвимость функции vsock_use_local_transport() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09816
Уязвимость функции tcp_bound_to_half_wnd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09817
Уязвимость функции tipc_conn_close() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09818
Уязвимость функции atomic_add_return() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-09819
Уязвимость модуля kernel/events/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09823
Уязвимость модулей drivers/net/ethernet/stmicro/stmmac/stmmac_main.c и drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-09824
Уязвимость функции aspeed_lpc_enable_snoop() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09825
Уязвимость функции taprio_dev_notifier() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09826
Уязвимость модуля arch/powerpc/platforms/powernv/memtrace.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09834
Уязвимость функции mii_nway_restart() ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2026-03-05
BDU:2025-09835
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09917
Уязвимость функции ftrace_mod_get_kallsym() компонента ftrace ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-09918
Уязвимость функции skb_send_sock() компонента BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10125
Уязвимость драйвера hisi_acc_vfio_pci ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-10126
Уязвимость функции skb_linearize() модуля net/core/skmsg.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10128
Уязвимость функции rtw_fw_bt_wifi_control() модуля drivers/net/wireless/realtek/rtw88/coex.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10130
Уязвимость функции mt7915_mmio_wed_init() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10131
Уязвимость функции aspberrypi_clk_register() модуля drivers/clk/bcm/clk-raspberrypi.c ядра операционной системы Linux, позволяющая нарушитею вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-10132
Уязвимость функции ath9k_htc_swba() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10310
Уязвимость компонента mtd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10311
Уязвимость функции at91_gpio_probe() файла drivers/pinctrl/pinctrl-at91.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-10312
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-10313
Уязвимость функции btrfs_convert_extent_bit() компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10314
Уязвимость функции fpga_mgr_test_img_load_sgt() компонента fpga ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-10442
Уязвимость функции kvm_vm_set_mem_attributes модуля virt/kvm/kvm_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-10443
Уязвимость драйвера mwifiex (drivers/net/wireless/marvell/mwifiex/util.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-10444
Уязвимость функции populate_free_space_tree() в модуле fs/btrfs/free-space-tree.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-10445
Уязвимость драйвера HID контроллера Nintendo Joy-Con ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-10560
Уязвимость функции jsm_uart_port_init компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10600
Уязвимость компонента dell-wmi-sysman ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-13
BDU:2025-10609
Уязвимость функции tls_strp_flush_anchor_copy операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10610
Уязвимость функции mlx5e_fix_uplink_rep_features операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-10612
Уязвимость функции ib_device_rename ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10613
Уязвимость функции rxe_create_cq операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10614
Уязвимость функции nfs_get_lock_context операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10735
Уязвимость функции lecd_attach ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10736
Уязвимость компонента smb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10737
Уязвимость функции rcu_dereference_rtnl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10739
Уязвимость функции ptp_vclock_in_use ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10740
Уязвимость функции submit_bio_noacct_nocheck ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10743
Уязвимость функции memcpy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10744
Уязвимость функции arch_memory_failure ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10745
Уязвимость функции gpio_keys_irq_timer ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10746
Уязвимость функции pata_via ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10747
Уязвимость функции jbd2_journal_dirty_metadata ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10749
Уязвимость функции clip_push ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10750
Уязвимость функции wacom_aes_battery_handler ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10751
Уязвимость функции group_cpus_evenly ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10752
Уязвимость функции memdup_user ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10753
Уязвимость функции memcg_path_store ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10754
Уязвимость функции unpin_user_folio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10755
Уязвимость функции megaraid_sas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-10757
Уязвимость функции mutex_unlock() компонента eventpoll ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10759
Уязвимость компонента spectrum_router ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10762
Уязвимость функции nvmet_tcp_set_queue_sock операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-10763
Уязвимость функции dell_rbu операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-10764
Уязвимость функции rcu_read_lock_trace_held ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-10766
Уязвимость функции fbcon_info_from_console ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-10767
Уязвимость функции __kvmalloc_node_noprof ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-10768
Уязвимость ядра операционной системы Linux, связанная с недостаточной проверкой входных данных, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-10769
Уязвимость ядра операционной системы Linux, связанная с недостаточной проверкой входных данных, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10770
Уязвимость функции usb_bulk_msg() операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-10771
Уязвимость функции ext4_dirty_journalled_data операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10772
Уязвимость функции nfs4_state_start_net операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10773
Уязвимость функции sk_is_readable() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-03-18
BDU:2025-10774
Уязвимость функции __red_change() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-18
BDU:2025-10775
Уязвимость функции _pf_vf_vports() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-02-17
BDU:2025-10776
Уязвимость функции mgmt_pending() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-18
BDU:2025-10777
Уязвимость компонента mdiobus ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-03-18
BDU:2025-10778
Уязвимость функции for_each_possible_cpu() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-03-18
BDU:2025-10779
Уязвимость функции usbhid_parse() компонента bNumDescriptors ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10780
Уязвимость компонента net_sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2026-03-18
BDU:2025-10781
Уязвимость функции vmci_host_setup_notify() файла mm/gup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10783
Уязвимость функции ets_qdisc_change() компонента net_sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-10784
Уязвимость функции nf_set_pipapo_avx2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
Modified: 2026-02-17
BDU:2025-10785
Уязвимость функций xe_guc_submit_init() и xe_guc_submit_wedge() файла drivers/gpu/drm/xe/xe_guc_submit.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10786
Уязвимость компонента idpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10787
Уязвимость функции anon_inode_make_secure_inode() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10789
Уязвимость функции core_scsi3_decode_spec_i_port() компонента bnxt_re ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10790
Уязвимость компонента nvmet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10791
Уязвимость функции nfs_fs_proc_net_init() файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10792
Уязвимость функции vmci_transport_packet() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10793
Уязвимость компонента idpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10794
Уязвимость функции obj_event() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10795
Уязвимость функции unregister_vlan_dev() компонента 8021q Module ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10796
Уязвимость функции tls_strp_check_rcv() реализации протокола TLS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10797
Уязвимость функции __nf_conntrack_find_get() компонента Netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10798
Уязвимость функции l2cap_sock_resume_cb() компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10799
Уязвимость функции pnfs_update_layout ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10800
Уязвимость компонента displayport ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-10801
Уязвимость компонента ACPICA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-10802
Уязвимость функции netif_napi_del() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-10803
Уязвимость функции show_numa_info() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации
Modified: 2026-04-13
BDU:2025-10804
Уязвимость функции do_insn_ioctl() компонента comedi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-10805
Уязвимость функции crypt_message() в модуле fs/smb/client/smb2ops.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-13
BDU:2025-10806
Уязвимость функции cipso_v4_sock_setattr() компонента smc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10870
Уязвимость функции handle_posix_cpu_timers ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10952
Уязвимость функции nfsd4_spo_must_allow() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-10953
Уязвимость функции ims_pcu_flash_firmware ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10954
Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-10955
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10956
Уязвимость функции tegra_crtc_reset() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-10957
Уязвимость функции mod_hdcp_hdcp1_enable_encryption() ядра операционной системы Linux , позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-10958
Уязвимость функции msm_devfreq_init() файла drivers/gpu/drm/msm/msm_gpu_devfreq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-11113
Уязвимость модуля drivers/regulator/gpio-regulator.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-11114
Уязвимость функции nanddev_ecc_engine_cleanup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-11343
Уязвимость функций ieee80211_is_valid_amsdu() и ieee80211_amsdu_to_8023s() (net/wireless/util.c.) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-11348
Уязвимость функции zd_mac_tx_to_dev() (drivers/net/wireless/zydas/zd1211rw/zd_mac.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-11349
Уязвимость функции kasan_find_vm_area() (mm/kasan/report.c) компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-11350
Уязвимость функции $software_function() (drivers/gpu/ drm / xe / xe_lmtt.c) компонента LMTT Page Handler ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11385
Уязвимость модуля arch/arm64/boot/dts/qcom/x1e80100.dtsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11389
Уязвимость функции f2fs_gc_range() компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11467
Уязвимость компонента net/sched/sch_prio.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации, нарушить её целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-11502
Уязвимость функции snd_card_ad1816a_pnp() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-11503
Уязвимость функции qdisc_tree_reduce_backlog() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-11504
Уязвимость функции vcc_sendmsg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-11505
Уязвимость функции tps6594_pfsm_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-11506
Уязвимость функции drm_crtc_handle_vblank() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-11509
Уязвимость функции mt7925_sta_set_decap_offload() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-11510
Уязвимость модуля drivers/usb/gadget/configfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-11511
Уязвимость функции devm_regulator_bulk_get() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-11512
Уязвимость функции page_pool_put_full_page() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-11762
Уязвимость функции zynqmp_nvmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-11764
Уязвимость функции max20086_parse_regulators_dt операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11765
Уязвимость функции mt7996_mmio_wed_init() модуля drivers/net/wireless/mediatek/mt76/mt7996/mmio.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-11766
Уязвимость компонента AMD Display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11767
Уязвимость функции fpsimd_thread_switch() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11768
Уязвимость компонента sunrpc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11769
Уязвимость функции taprio_dev_notifier() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11770
Уязвимость функции arm_ni_init() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-11792
Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11793
Уязвимость компонента ip_vs_xmit.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11800
Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-11833
Уязвимость функции current_password_store() драйвера dell-wmi-sysman ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-11834
Уязвимость модулей crypto, lzo ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-11835
Уязвимость функции pktgen_thread_write() компонента net/core/pktgen.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
BDU:2025-11861
Уязвимость компонента drivers/gpio/gpio-virtuser.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-11862
Уязвимость компонента net/can/bcm.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-11864
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11865
Уязвимость компонента vfs.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-13
BDU:2025-11927
Уязвимость компонента fs/orangefs/inode.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11928
Уязвимость компонента bpf_jit_comp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11929
Уязвимость компонентов arm64 ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11970
Уязвимость функции output_userspace() компонента net/openvswitch/actions.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-11972
Уязвимость компонента x86/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11974
Уязвимость функции dequeue_entities() компонента kernel/sched/fair.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11985
Уязвимость ядра операционной системы Linux, связанная с недостаточной проверкой подлинности данных, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-11988
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12000
Уязвимость функции nd_label_data_init() компонента drivers/nvdimm/label.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12014
Уязвимость компонента drivers/dma/ti/k3-udma.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12020
Уязвимость компонента arch/x86/mm/tlb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12030
Уязвимость компонента oplock.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12031
Уязвимость компонента virtio-net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12032
Уязвимость компонента v3d_sched.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12058
Уязвимость функции hash_accept() компонента crypto/algif_hash.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12064
Уязвимость компонента sound/soc/sof/intel/hda.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-12065
Уязвимость компонента net/can/bcm.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12066
Уязвимость функции hfsc_enqueue() компонента net/sched/sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-12067
Уязвимость компонента s390/pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12107
Уязвимость функции find_cifs_entry() в модуле fs/smb/client/readdir.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-13
BDU:2025-12119
Уязвимость компонента iscsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12120
Уязвимость компонента arch/x86/events/intel/ds.c ядра операционной системы Linux, озволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12121
Уязвимость драйвера idpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12123
Уязвимость компонента ucsi/displayport.c ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12124
Уязвимость компонентов net/sched/ ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12125
Уязвимость компонента s390/pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12126
Уязвимость функции mtk_pmic_keys_lp_reset_setup() компонента mtk-pmic-keys.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12127
Уязвимость компонента bcm2835-camera ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12128
Уязвимость компонента sch_htb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12241
Уязвимость компонента drivers/md/dm-cache-target.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12242
Уязвимость компонента m_can ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12254
Уязвимость ядра операционной системы Linux, связанная с ошибками инициализации памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12256
Уязвимость компонентов xenbus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12272
Уязвимость компонента filter.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12277
Уязвимость функции __legitimize_mnt() компонента fs/namespace.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12288
Уязвимость компонента genirq/msi ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-12289
Уязвимость компонента fs/erofs/fileio.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12291
Уязвимость компонента memblock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12309
Уязвимость функции __send_empty_flush() драйвера dm ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12326
Уязвимость компонента drivers/ptp/ptp_ocp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12331
Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12334
Уязвимость ядра операционной системы Linux, связанная с доступом к неинициализированному указателю, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12336
Уязвимость компонентов drivers/usb/typec/ucsi/ ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12349
Уязвимость компонента net/sched/sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12350
Уязвимость функции st_lsm6dsx_read_fifo() компонента st_lsm6dsx_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12351
Уязвимость функции st_lsm6dsx_read_tagged_fifo() компонента st_lsm6dsx_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-13170
Уязвимость функции ath12k_service_ready_ext_event() модуля drivers/net/wireless/ath/ath12k/wmi.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-13454
Уязвимость функции adxl_put ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
Modified: 2026-03-19
BDU:2025-13456
Уязвимость функции aoedev_downdev ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-13459
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13460
Уязвимость функции get_new_segment ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-13461
Уязвимость функции free_transport ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-13463
Уязвимость функции jffs2_prealloc_raw_node_refs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-13465
Уязвимость функции wcd9335_parse_dt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13466
Уязвимость функции load_global_roots_objectid ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13467
Уязвимость функции uart_register_driver ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13472
Уязвимость подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-13473
Уязвимость функции huge_pte_offset операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-13475
Уязвимость функции jffs2_link_node_ref операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-13477
Уязвимость функции build_sit_entries операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-13479
Уязвимость операционной системы Linux, связанная с ошибкой разыменования указателей, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-13480
Уязвимость функции e5010_probe ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-13481
Уязвимость функции fts_read операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-13482
Уязвимость ядра операционной системы Linux, связанная с недостаточной проверкой входных данных, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-13484
Уязвимость функции v4l2_rect_map_inside операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
Modified: 2026-03-18
BDU:2025-13485
Уязвимость компонента media операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-13486
Уязвимость функции dbMount операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации
Modified: 2026-03-19
BDU:2025-13493
Уязвимость функции msdc_prepare_data() компонента mtk-sd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-13494
Уязвимость компонента ath6kl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13495
Уязвимость функции sbi_hsm_hart_start() компонента boot_data ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-11-26
BDU:2025-13497
Уязвимость функции in_atomic() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-13498
Уязвимость функции __kmem_cache_shutdown ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-13509
Уязвимость функции kmalloc_array() компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-26
BDU:2025-13510
Уязвимость компонента arm_ffa ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13511
Уязвимость функции rpl_do_srh_inline() компонента rpl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13512
Уязвимость функции rose_rt_device_down() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13513
Уязвимость функции fxls8962af_fifo_flush() компонента iio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13514
Уязвимость функции misc_deregister() компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13515
Уязвимость функции bpf_arch_text_poke() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13517
Уязвимость драйвера Low Level Transport ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-13519
Уязвимость функции pcibios_bus_to_resource ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13520
Уязвимость функции __mptcp_do_fallback() компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13521
Уязвимость функции timerlat_dump_stack() модуля lib/string_helpers.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13522
Уязвимость функции hid_hw_raw_request() драйвера Low Level Transport ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13523
Уязвимость функции in_atomic() модуля drivers/md/dm-bufio.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13561
Уязвимость функций nvme_tcp_fetch_request(), nvme_tcp_init_request(), nvme_tcp_handle_r2t() и nvme_tcp_submit_async_event() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-13563
Уязвимость функции do_register_framebuffer() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-13564
Уязвимость функции automount_fullpath() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-13565
Уязвимость функции cache_set_flush() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-19
BDU:2025-14090
Уязвимость функции vsock_find_cid() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14091
Уязвимость функции __access_ok() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-14095
Уязвимость функции cm_chan_msg_send() модуля drivers/rapidio/rio_cm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14096
Уязвимость функции opinfo_get_list() компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14097
Уязвимость функции check_mul_overflow() компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-14098
Уязвимость функции hdr_first_de() компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-14099
Уязвимость функции bpf_exec_tx_verdict() компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-14100
Уязвимость функции do_sme_acc() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-14933
Уязвимость компонента rseq.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2026-04-13
BDU:2025-14968
Уязвимость компонента drm/amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-14969
Уязвимость компонента /net/phy/phy_device.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-14971
Уязвимость компонента scsi.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-14978
Уязвимость компонента dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-14979
Уязвимость компонента huge_memory.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15019
Уязвимость компонента virtio-net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15022
Уязвимость ядра операционной системы Linux, связанная с недостатком использования функции assert(), позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-15113
Уязвимость функции ath12k_pci_free_irq() компонента pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-15114
Уязвимость компонента cfg80211 подсистемы Wi-Fi ядра операционной системы Linux,позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15160
Уязвимость функции clone_private_mnt() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищамой информации
Modified: 2026-04-13
BDU:2025-15162
Уязвимость компонента net/xfrm ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-15163
Уязвимость компонента lib/alloc_tag ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15164
Уязвимость ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15165
Уязвимость компонента libwx ядра операционной системы Linux, позволяющая нарушителю нарушить оказать воздействие на целостность и доступность защищаемой информации
Modified: 2026-04-13
BDU:2025-15166
Уязвимость компонента quirks ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15167
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15168
Уязвимость компонента hwmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15169
Уязвимость компонента efivarfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15186
Уязвимость компонента net/appletalk/aarp.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-15215
Уязвимость компонента drm/xe/guc ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-10
BDU:2025-15216
Уязвимость функций EXPORT_SYMBOL(), destroy_cm_id() и cm_work_handler() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2026-02-17
BDU:2025-15217
Уязвимость функций dev_fini_ggtt() и xe_ggtt_init_early() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-15232
Уязвимость сетевого драйвера bnxt ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2025-15233
Уязвимость компонента libwx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-15450
Уязвимость функции automount_fullpath() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-15461
Уязвимость модуля drivers/virt/coco/tsm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-10
BDU:2025-15484
Уязвимость модулей drivers/iommu/intel/iommu.c, rivers/iommu/intel/iommu.h и drivers/iommu/intel/nested.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15554
Уязвимость ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-15556
Уязвимость компонента jfs_imap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-15707
Уязвимость компонентов mm/memory-failure.c, mm/vmscan.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15768
Уязвимость компонента net/xfrm/xfrm_state.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15769
Уязвимость компонента drivers/i2c/busses/i2c-qup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15770
Уязвимость компонента arm64/entry ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15771
Уязвимость компонента drivers/regulator/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15772
Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15773
Уязвимость компонента ice/ice_ddp.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-04-14
BDU:2025-15774
Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15803
Уязвимость компонентов tmptcp ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15804
Уязвимость компонента mcast ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15805
Уязвимость компонента warning. Add ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15806
Уязвимость компонента atm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15807
Уязвимость компонента am65-cpsw-nuss ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15808
Уязвимость компонента drm/tegra ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15809
Уязвимость компонента appletalk ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15810
Уязвимость ядра операционной системы Linux, связанная с одновременным выполнением с использованием общего ресурса с неправильной синхронизацией, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15811
Уязвимость компонента xusb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15813
Уязвимость компонента libwx ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15814
Уязвимость ядра операционной системы Linux, связанная с чтением за границами буфера данных, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15815
Уязвимость ядра операционной системы Linux, связанная с чтением за допустимыми границами буфера данных, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15816
Уязвимость компонента smb ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15817
Уязвимость функции ice_lag_is_switchdev_running() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15819
Уязвимость компонента drm/imagination ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15820
Уязвимость компонента pinctrl-msm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15821
Уязвимость компонента drm/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-15822
Уязвимость ядра операционной системы Linux, связанная с неправильной проверкой возвращаемого значения функции, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-15824
Уязвимость компонента hugetlb.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-15825
Уязвимость компонентов mm ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-15826
Уязвимость компонентов crypto ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-16076
Уязвимость модуля drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01382
Уязвимость функции st_sensors_power_enable() модуля drivers/iio/accel/st_accel_core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01385
Уязвимость функции smb2_get_name() модуля fs/smb/server/smb2pdu.c поддержки сервера SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01387
Уязвимость функции find_or_create_cached_dir() модуля fs/smb/client/cached_dir.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01411
Уязвимость функции cow_file_range() модуля fs/btrfs/inode.c поддержки файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02238
Уязвимость функции __close_file_table_ids() в модуле fs/smb/server/vfs_cache.c поддержки сервера SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02239
Уязвимость функций pci_epf_test_set_bar() и pci_epf_test_free_space() в модуле drivers/pci/endpoint/functions/pci-epf-test.c драйвера уcтройств PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2026-02375
Уязвимость функции stmmac_request_irq_multi_msi() в модуле drivers/net/ethernet/stmicro/stmmac/stmmac_main.c драйвера сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2026-02397
Уязвимость функции opt3001_irq() в модуле drivers/iio/light/opt3001.c драйвера фотодатчиков ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03065
Уязвимость функции scrub_find_fill_first_stripe() модуля fs/btrfs/scrub.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03083
Уязвимость функций copy_verifier_state() и do_check() модуля kernel/bpf/verifier.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03113
Уязвимость функции rxrpc_service_prealloc_one() модуля net/rxrpc/call_accept.c поддержки сокетов сеанса RxRPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03117
Уязвимость функции shutdown_interception() модуля arch/x86/kvm/svm/svm.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04366
Уязвимость функции btrfs_create_pending_block_groups() модуля fs/btrfs/block-group.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2026-04400
Уязвимость функций esp_output_tcp_finish() (net/ipv4/esp4.c) и esp_output_tcp_finish() (net/ipv6/esp6.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05192
Уязвимость функции amdgpu_virt_rlcg_reg_rw() в модуле drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05759
Уязвимость функции fsl_qspi_probe() в модуле drivers/spi/spi-fsl-qspi.c драйвера устройств SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06105
Уязвимость функции rxrpc_recvmsg() в модуле net/rxrpc/recvmsg.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06106
Уязвимость функций ism_cmd() и ism_probe() в модуле drivers/s390/net/ism_drv.c драйвера сети на платформе S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-23
CVE-2024-57976
In the Linux kernel, the following vulnerability has been resolved: btrfs: do proper folio cleanup when cow_file_range() failed [BUG] When testing with COW fixup marked as BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path. This BUG_ON() happens just after a failed btrfs_run_delalloc_range(): BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC. Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling. For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size: 0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################| Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag. - Enter extent_writepage() for page 0 - Enter btrfs_run_delalloc_range() for range [0, 64K) - Enter cow_file_range() for range [0, 64K) - Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K) 0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################| And range [0, 16K) has its delalloc flag cleared. But since we haven't yet submit any bio, involved 4 pages are still dirty. - Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges: 0 16K 32K 48K 64K |////////| | | | | Note that range [0, 16K) still has its pages dirty. - Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags. - btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag. - extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON(). Unfortunately this error handling bug dates back to the introduction of btrfs. Thankfully with the abuse of COW fixup, at least it won't crash the kernel. [FIX] Instead of immediately unlocking the extent and folios, we keep the extent and folios locked until either erroring out or the whole delalloc range finished. When the whole delalloc range finished without error, we just unlock the whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked cases) ---truncated---
Modified: 2025-10-31
CVE-2024-58091
In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Add shadow buffering for deferred I/O DMA areas are not necessarily backed by struct page, so we cannot rely on it for deferred I/O. Allocate a shadow buffer for drivers that require deferred I/O and use it as framebuffer memory. Fixes driver errors about being "Unable to handle kernel NULL pointer dereference at virtual address" or "Unable to handle kernel paging request at virtual address". The patch splits drm_fbdev_dma_driver_fbdev_probe() in an initial allocation, which creates the DMA-backed buffer object, and a tail that sets up the fbdev data structures. There is a tail function for direct memory mappings and a tail function for deferred I/O with the shadow buffer. It is no longer possible to use deferred I/O without shadow buffer. It can be re-added if there exists a reliably test for usable struct page in the allocated DMA-backed buffer object.
Modified: 2025-11-04
CVE-2025-22101
In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix Tx L4 checksum The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol. There was a bug to set Tx checksum flag for the other protocol that results in Tx ring hang. Fix to compute software checksum for these packets.
Modified: 2025-11-04
CVE-2025-22102
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix kernel panic during FW release This fixes a kernel panic seen during release FW in a stress test scenario where WLAN and BT FW download occurs simultaneously, and due to a HW bug, chip sends out only 1 bootloader signatures. When driver receives the bootloader signature, it enters FW download mode, but since no consequtive bootloader signatures seen, FW file is not requested. After 60 seconds, when FW download times out, release_firmware causes a kernel panic. [ 2601.949184] Unable to handle kernel paging request at virtual address 0000312e6f006573 [ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000 [ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000 [ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP [ 2601.992091] Modules linked in: algif_hash algif_skcipher af_alg btnxpuart(O) pciexxx(O) mlan(O) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce snd_soc_fsl_easrc snd_soc_fsl_asoc_card imx8_media_dev(C) snd_soc_fsl_micfil polyval_generic snd_soc_fsl_xcvr snd_soc_fsl_sai snd_soc_imx_audmux snd_soc_fsl_asrc snd_soc_imx_card snd_soc_imx_hdmi snd_soc_fsl_aud2htx snd_soc_fsl_utils imx_pcm_dma dw_hdmi_cec flexcan can_dev [ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G C O 6.6.23-lts-next-06236-gb586a521770e #1 [ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2602.010191] pc : _raw_spin_lock+0x34/0x68 [ 2602.010201] lr : free_fw_priv+0x20/0xfc [ 2602.020561] sp : ffff800089363b30 [ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000 [ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000 [ 2602.020577] x23: ffff0000dc856f38 [ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000 [ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000 [ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480 [ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002 [ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30 [ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000 [ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001 [ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573 [ 2602.083354] Call trace: [ 2602.083356] _raw_spin_lock+0x34/0x68 [ 2602.083364] release_firmware+0x48/0x6c [ 2602.083370] nxp_setup+0x3c4/0x540 [btnxpuart] [ 2602.083383] hci_dev_open_sync+0xf0/0xa34 [ 2602.083391] hci_dev_open+0xd8/0x178 [ 2602.083399] hci_sock_ioctl+0x3b0/0x590 [ 2602.083405] sock_do_ioctl+0x60/0x118 [ 2602.083413] sock_ioctl+0x2f4/0x374 [ 2602.091430] __arm64_sys_ioctl+0xac/0xf0 [ 2602.091437] invoke_syscall+0x48/0x110 [ 2602.091445] el0_svc_common.constprop.0+0xc0/0xe0 [ 2602.091452] do_el0_svc+0x1c/0x28 [ 2602.091457] el0_svc+0x40/0xe4 [ 2602.091465] el0t_64_sync_handler+0x120/0x12c [ 2602.091470] el0t_64_sync+0x190/0x194
Modified: 2025-11-03
CVE-2025-22112
In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: fix out-of-range access of vnic_info array The bnxt_queue_{start | stop}() access vnic_info as much as allocated, which indicates bp->nr_vnics. So, it should not reach bp->vnic_info[bp->nr_vnics].
Modified: 2025-11-03
CVE-2025-22115
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix block group refcount race in btrfs_create_pending_block_groups()
Block group creation is done in two phases, which results in a slightly
unintuitive property: a block group can be allocated/deallocated from
after btrfs_make_block_group() adds it to the space_info with
btrfs_add_bg_to_space_info(), but before creation is completely completed
in btrfs_create_pending_block_groups(). As a result, it is possible for a
block group to go unused and have 'btrfs_mark_bg_unused' called on it
concurrently with 'btrfs_create_pending_block_groups'. This causes a
number of issues, which were fixed with the block group flag
'BLOCK_GROUP_FLAG_NEW'.
However, this fix is not quite complete. Since it does not use the
unused_bg_lock, it is possible for the following race to occur:
btrfs_create_pending_block_groups btrfs_mark_bg_unused
if list_empty // false
list_del_init
clear_bit
else if (test_bit) // true
list_move_tail
And we get into the exact same broken ref count and invalid new_bgs
state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to
prevent.
The broken refcount aspect will result in a warning like:
[1272.943527] refcount_t: underflow; use-after-free.
[1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
[1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs]
[1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108
[1272.946368] Tainted: [W]=WARN
[1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
[1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs]
[1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110
[1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282
[1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000
[1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff
[1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268
[1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0
[1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0
[1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000
[1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0
[1272.954474] Call Trace:
[1272.954655]
Modified: 2026-03-17
CVE-2025-22119
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: init wiphy_work before allocating rfkill fails
syzbort reported a uninitialize wiphy_work_lock in cfg80211_dev_free. [1]
After rfkill allocation fails, the wiphy release process will be performed,
which will cause cfg80211_dev_free to access the uninitialized wiphy_work
related data.
Move the initialization of wiphy_work to before rfkill initialization to
avoid this issue.
[1]
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 UID: 0 PID: 5935 Comm: syz-executor550 Not tainted 6.14.0-rc6-syzkaller-00103-g4003c9e78778 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/2617f60c3613ef105b8db2d514d2cac2a1836f7d
- https://git.kernel.org/stable/c/60606efbf52582c0ab93e99789fddced6b47297a
- https://git.kernel.org/stable/c/7e6040853f5b5f067a18c52286e676bc298fe6a2
- https://git.kernel.org/stable/c/b679fe84cd5cc6f3481b7131fd28676191ad2615
- https://git.kernel.org/stable/c/eeacfbab984200dcdcd68fcf4c6e91e2c6b38792
- https://git.kernel.org/stable/c/fc88dee89d7b63eeb17699393eb659aadf9d9b7c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-03
CVE-2025-22122
In the Linux kernel, the following vulnerability has been resolved: block: fix adding folio to bio >4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage is supported, then 'offset' of folio can't be held in 'unsigned int', cause warning in bio_add_folio_nofail() and IO failure. Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't be overflow, and folio can be added to bio successfully.
Modified: 2025-11-03
CVE-2025-22123
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid accessing uninitialized curseg
syzbot reports a f2fs bug as below:
F2FS-fs (loop3): Stopped filesystem due to reason: 7
kworker/u8:7: attempt to access beyond end of device
BUG: unable to handle page fault for address: ffffed1604ea3dfa
RIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline]
RIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline]
RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline]
RIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline]
RIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649
Modified: 2025-11-03
CVE-2025-22128
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath12k_pci_msi_alloc(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This may end up with a warning from the IRQ core that is expecting the affinity hint to be cleared before freeing the IRQ: kernel/irq/manage.c: /* make sure affinity_hint is cleaned up */ if (WARN_ON_ONCE(desc->affinity_hint)) desc->affinity_hint = NULL; So to fix this issue, clear the IRQ affinity hint before calling ath12k_pci_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm.
Modified: 2026-03-17
CVE-2025-23155
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix accessing freed irq affinity_hint In stmmac_request_irq_multi_msi(), a pointer to the stack variable cpu_mask is passed to irq_set_affinity_hint(). This value is stored in irq_desc->affinity_hint, but once stmmac_request_irq_multi_msi() returns, the pointer becomes dangling. The affinity_hint is exposed via procfs with S_IRUGO permissions, allowing any unprivileged process to read it. Accessing this stale pointer can lead to: - a kernel oops or panic if the referenced memory has been released and unmapped, or - leakage of kernel data into userspace if the memory is re-used for other purposes. All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are affected.
- https://git.kernel.org/stable/c/2fbf67ddb8a0d0efc00d2df496a9843ec318d48b
- https://git.kernel.org/stable/c/442312c2a90d60c7a5197246583fa91d9e579985
- https://git.kernel.org/stable/c/960dab23f6d405740c537d095f90a4ee9ddd9285
- https://git.kernel.org/stable/c/9e51a6a44e2c4de780a26e8fe110d708e806a8cd
- https://git.kernel.org/stable/c/c60d101a226f18e9a8f01bb4c6ca2b47dfcb15ef
- https://git.kernel.org/stable/c/e148266e104fce396ad624079a6812ac3a9982ef
Modified: 2025-11-12
CVE-2025-37821
In the Linux kernel, the following vulnerability has been resolved: sched/eevdf: Fix se->slice being set to U64_MAX and resulting crash There is a code path in dequeue_entities() that can set the slice of a sched_entity to U64_MAX, which sometimes results in a crash. The offending case is when dequeue_entities() is called to dequeue a delayed group entity, and then the entity's parent's dequeue is delayed. In that case: 1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX. 2. The first for_each_sched_entity() loop dequeues the entity. 3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent. 4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_. 5. The second for_each_sched_entity() loop sets the parent's ->slice to the saved slice, which is still U64_MAX. This throws off subsequent calculations with potentially catastrophic results. A manifestation we saw in production was: 6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number. 7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit is negative, vlag > limit, so se->vlag is set to the same huge negative number. 8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number. 9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number. 10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which incorrectly returns false because the vruntime is so far from the other vruntimes on the queue, causing the (vruntime - cfs_rq->min_vruntime) * load calulation to overflow. 11. Nothing appears to be eligible, so pick_eevdf() returns NULL. 12. pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes. Dumping the cfs_rq states from the core dumps with drgn showed tell-tale huge vruntime ranges and bogus vlag values, and I also traced se->slice being set to U64_MAX on live systems (which was usually "benign" since the rest of the runqueue needed to be in a particular state to crash). Fix it in dequeue_entities() by always setting slice from the first non-empty cfs_rq.
Modified: 2025-11-17
CVE-2025-37842
In the Linux kernel, the following vulnerability has been resolved: spi: fsl-qspi: use devm function instead of driver remove Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence. Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind
- https://git.kernel.org/stable/c/40369bfe717e96e26650eeecfa5a6363563df6e4
- https://git.kernel.org/stable/c/439688dbe82baa10d4430dc3252bb5ef1183a171
- https://git.kernel.org/stable/c/50ae352c1848cab408fb4f7d7f50c71f818bbdbf
- https://git.kernel.org/stable/c/f68b27d82a749117d9c7d7f33fa53f46373e38e2
- https://git.kernel.org/stable/c/f9bfb3a5f6f616f3eb7665c8ff3bcb9760ae33c8
Modified: 2025-11-03
CVE-2025-37925
In the Linux kernel, the following vulnerability has been resolved:
jfs: reject on-disk inodes of an unsupported type
Syzbot has reported the following BUG:
kernel BUG at fs/inode.c:668!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
RIP: 0010:clear_inode+0x168/0x190
Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7
0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f
RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093
RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38
R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000
R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80
FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/28419a4f3a1eeee33472a1b3856ae62aaa5a649b
- https://git.kernel.org/stable/c/45fd8421081ec79e661e5f3ead2934fdbddb4287
- https://git.kernel.org/stable/c/8987891c4653874d5e3f5d11f063912f4e0b58eb
- https://git.kernel.org/stable/c/8c3f9a70d2d4dd6c640afe294b05c6a0a45434d9
- https://git.kernel.org/stable/c/afc08b0b5587b553799bc375957706936a3e0088
- https://git.kernel.org/stable/c/fa6ce4a9cc9fcc8150b80db6f65186c0ed2b3143
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-17
CVE-2025-37946
In the Linux kernel, the following vulnerability has been resolved: s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs With commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state of zpci_dev's") the code to ignore power off of a PF that has child VFs was changed from a direct return to a goto to the unlock and pci_dev_put() section. The change however left the existing pci_dev_put() untouched resulting in a doubple put. This can subsequently cause a use after free if the struct pci_dev is released in an unexpected state. Fix this by removing the extra pci_dev_put().
Modified: 2026-03-17
CVE-2025-37947
In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds stream writes by validating *pos ksmbd_vfs_stream_write() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (v_len). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write. This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.
- https://git.kernel.org/stable/c/04c8a38c60346bb5a7c49b276de7233f703ce9cb
- https://git.kernel.org/stable/c/0ca6df4f40cf4c32487944aaf48319cb6c25accc
- https://git.kernel.org/stable/c/7f61da79df86fd140c7768e668ad846bfa7ec8e1
- https://git.kernel.org/stable/c/d62ba16563a86aae052f96d270b3b6f78fca154c
- https://git.kernel.org/stable/c/e6356499fd216ed6343ae0363f4c9303f02c5034
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://github.com/doyensec/KSMBD-CVE-2025-37947/blob/main/CVE-2025-37947.c
Modified: 2025-12-18
CVE-2025-37948
In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp.
- https://git.kernel.org/stable/c/0dfefc2ea2f29ced2416017d7e5b1253a54c2735
- https://git.kernel.org/stable/c/38c345fd54afd9d6ed8d3fcddf3f6ea23887bf78
- https://git.kernel.org/stable/c/42a20cf51011788f04cf2adbcd7681f02bdb6c27
- https://git.kernel.org/stable/c/852b8ae934b5cbdc62496fa56ce9969aa2edda7f
- https://git.kernel.org/stable/c/8fe5c37b0e08a97cf0210bb75970e945aaaeebab
- https://git.kernel.org/stable/c/993f63239c219696aef8887a4e7d3a16bf5a8ece
- https://git.kernel.org/stable/c/c6a8735d841bcb7649734bb3a787bb174c67c0d8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-37949
In the Linux kernel, the following vulnerability has been resolved:
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
- https://git.kernel.org/stable/c/0e94a246bb6d9538010b6c02d2b1d4717a97b2e5
- https://git.kernel.org/stable/c/1f0304dfd9d217c2f8b04a9ef4b3258a66eedd27
- https://git.kernel.org/stable/c/2466b0f66795c3c426cacc8998499f38031dbb59
- https://git.kernel.org/stable/c/4d260a5558df4650eb87bc41b2c9ac2d6b2ba447
- https://git.kernel.org/stable/c/8b02f85e84dc6f7c150cef40ddb69af5a25659e5
- https://git.kernel.org/stable/c/8e9c8a0393b5f85f1820c565ab8105660f4e8f92
- https://git.kernel.org/stable/c/cbfaf46b88a4c01b64c4186cdccd766c19ae644c
- https://git.kernel.org/stable/c/f1bcac367bc95631afbb918348f30dec887d0e1b
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-37951
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Add job to pending list if the reset was skipped When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1] and [2]. Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout.
- https://git.kernel.org/stable/c/12125f7d9c15e6d8ac91d10373b2db2f17dcf767
- https://git.kernel.org/stable/c/35e4079bf1a2570abffce6ababa631afcf8ea0e5
- https://git.kernel.org/stable/c/422a8b10ba42097a704d6909ada2956f880246f2
- https://git.kernel.org/stable/c/5235b56b7e5449d990d21d78723b1a5e7bb5738e
- https://git.kernel.org/stable/c/a5f162727b91e480656da1876247a91f651f76de
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-37952
In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix UAF in __close_file_table_ids A use-after-free is possible if one thread destroys the file via __ksmbd_close_fd while another thread holds a reference to it. The existing checks on fp->refcount are not sufficient to prevent this. The fix takes ft->lock around the section which removes the file from the file table. This prevents two threads acquiring the same file pointer via __close_file_table_ids, as well as the other functions which retrieve a file from the IDR and which already use this same lock.
Modified: 2025-12-17
CVE-2025-37953
In the Linux kernel, the following vulnerability has been resolved: sch_htb: make htb_deactivate() idempotent Alan reported a NULL pointer dereference in htb_next_rb_node() after we made htb_qlen_notify() idempotent. It turns out in the following case it introduced some regression: htb_dequeue_tree(): |-> fq_codel_dequeue() |-> qdisc_tree_reduce_backlog() |-> htb_qlen_notify() |-> htb_deactivate() |-> htb_next_rb_node() |-> htb_deactivate() For htb_next_rb_node(), after calling the 1st htb_deactivate(), the clprio[prio]->ptr could be already set to NULL, which means htb_next_rb_node() is vulnerable here. For htb_deactivate(), although we checked qlen before calling it, in case of qlen==0 after qdisc_tree_reduce_backlog(), we may call it again which triggers the warning inside. To fix the issues here, we need to: 1) Make htb_deactivate() idempotent, that is, simply return if we already call it before. 2) Make htb_next_rb_node() safe against ptr==NULL. Many thanks to Alan for testing and for the reproducer.
- https://git.kernel.org/stable/c/31ff70ad39485698cf779f2078132d80b57f6c07
- https://git.kernel.org/stable/c/3769478610135e82b262640252d90f6efb05be71
- https://git.kernel.org/stable/c/98cd7ed92753090a714f0802d4434314526fe61d
- https://git.kernel.org/stable/c/99ff8a20fd61315bf9ae627440a5ff07d22ee153
- https://git.kernel.org/stable/c/a9945f7cf1709adc5d2d31cb6cfc85627ce299a8
- https://git.kernel.org/stable/c/c2d25fddd867ce20a266806634eeeb5c30cb520c
- https://git.kernel.org/stable/c/c4792b9e38d2f61b07eac72f10909fa76130314b
- https://git.kernel.org/stable/c/c928dd4f6bf0c25c72b11824a1e9ac9bd37296a0
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-37954
In the Linux kernel, the following vulnerability has been resolved: smb: client: Avoid race in open_cached_dir with lease breaks A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs. Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked.
Modified: 2025-11-14
CVE-2025-37955
In the Linux kernel, the following vulnerability has been resolved: virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable() The selftests added to our CI by Bui Quang Minh recently reveals that there is a mem leak on the error path of virtnet_xsk_pool_enable(): unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Modified: 2025-11-14
CVE-2025-37956
In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent rename with empty string Client can send empty newname string to ksmbd server. It will cause a kernel oops from d_alloc. This patch return the error when attempting to rename a file or directory with an empty new name string.
Modified: 2025-11-14
CVE-2025-37957
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception
Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode
on vCPU reset") addressed an issue where a triple fault occurring in
nested mode could lead to use-after-free scenarios. However, the commit
did not handle the analogous situation for System Management Mode (SMM).
This omission results in triggering a WARN when KVM forces a vCPU INIT
after SHUTDOWN interception while the vCPU is in SMM. This situation was
reprodused using Syzkaller by:
1) Creating a KVM VM and vCPU
2) Sending a KVM_SMI ioctl to explicitly enter SMM
3) Executing invalid instructions causing consecutive exceptions and
eventually a triple fault
The issue manifests as follows:
WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112
kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112
Modules linked in:
CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted
6.1.130-syzkaller-00157-g164fe5dde9b6 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.12.0-1 04/01/2014
RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112
Call Trace:
Modified: 2025-12-16
CVE-2025-37958
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: fix dereferencing invalid pmd migration entry
When migrating a THP, concurrent access to the PMD migration entry during
a deferred split scan can lead to an invalid address access, as
illustrated below. To prevent this invalid access, it is necessary to
check the PMD migration entry and return early. In this context, there is
no need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the
equality of the target folio. Since the PMD migration entry is locked, it
cannot be served as the target.
Mailing list discussion and explanation from Hugh Dickins: "An anon_vma
lookup points to a location which may contain the folio of interest, but
might instead contain another folio: and weeding out those other folios is
precisely what the "folio != pmd_folio((*pmd)" check (and the "risk of
replacing the wrong folio" comment a few lines above it) is for."
BUG: unable to handle page fault for address: ffffea60001db008
CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60
Call Trace:
- https://git.kernel.org/stable/c/22f6368768340260e862f35151d2e1c55cb1dc75
- https://git.kernel.org/stable/c/3977946f61cdba87b6b5aaf7d7094e96089583a5
- https://git.kernel.org/stable/c/6166c3cf405441f7147b322980144feb3cefc617
- https://git.kernel.org/stable/c/753f142f7ff7d2223a47105b61e1efd91587d711
- https://git.kernel.org/stable/c/9468afbda3fbfcec21ac8132364dff3dab945faf
- https://git.kernel.org/stable/c/be6e843fc51a584672dfd9c4a6a24c8cb81d5fb7
- https://git.kernel.org/stable/c/ef5706bed97e240b4abf4233ceb03da7336bc775
- https://git.kernel.org/stable/c/fbab262b0c8226c697af1851a424896ed47dedcc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-37959
In the Linux kernel, the following vulnerability has been resolved: bpf: Scrub packet on bpf_redirect_peer When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace. As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2, In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption. This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.
- https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763
- https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a
- https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e
- https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503
- https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-37960
In the Linux kernel, the following vulnerability has been resolved: memblock: Accept allocated memory before use in memblock_double_array() When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest: RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b Mitigate this by calling accept_memory() on the memory range returned before the slab is available. Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.
Modified: 2025-12-16
CVE-2025-37961
In the Linux kernel, the following vulnerability has been resolved: ipvs: fix uninit-value for saddr in do_output_route4 syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---
- https://git.kernel.org/stable/c/0160ac84fb03a0bd8dce8a42cb25bfaeedd110f4
- https://git.kernel.org/stable/c/7d0032112a0380d0b8d7c9005f621928a9b9fc76
- https://git.kernel.org/stable/c/a3a1b784791a3cbfc6e05c4d8a3c321ac5136e25
- https://git.kernel.org/stable/c/adbc8cc1162951cb152ed7f147d5fbd35ce3e62f
- https://git.kernel.org/stable/c/e34090d7214e0516eb8722aee295cb2507317c07
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37962
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix memory leak in parse_lease_state() The previous patch that added bounds check for create lease context introduced a memory leak. When the bounds check fails, the function returns NULL without freeing the previously allocated lease_ctx_info structure. This patch fixes the issue by adding kfree(lreq) before returning NULL in both boundary check cases.
- https://git.kernel.org/stable/c/2148d34371b06dac696c0497a98a6bf905a51650
- https://git.kernel.org/stable/c/829e19ef741d9e9932abdc3bee5466195e0852cf
- https://git.kernel.org/stable/c/af9e2d4732a548db8f6f5a90c2c20a789a3d7240
- https://git.kernel.org/stable/c/eb4447bcce915b43b691123118893fca4f372a8f
- https://git.kernel.org/stable/c/facf22c1a394c1e023dab5daf9a494f722771e1c
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37963
In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.
- https://git.kernel.org/stable/c/038866e01ea5e5a3d948898ac216e531e7848669
- https://git.kernel.org/stable/c/477481c4348268136227348984b6699d6370b685
- https://git.kernel.org/stable/c/6e52d043f7dbf1839a24a3fab2b12b0d3839de7a
- https://git.kernel.org/stable/c/80251f62028f1ab2e09be5ca3123f84e8b00389a
- https://git.kernel.org/stable/c/df53d418709205450a02bb4d71cbfb4ff86f2c1e
- https://git.kernel.org/stable/c/e5f5100f1c64ac6c72671b2cf6b46542fce93706
- https://git.kernel.org/stable/c/f300769ead032513a68e4a02e806393402e626f8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37964
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: // Turn on IPIs for this CPU/mm combination, but only // if should_flush_tlb() agrees: cpumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); load_new_mm_cr3(need_flush); // ^ After 'need_flush' is set to false, IPIs *MUST* // be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); // ^ Not until this point does should_flush_tlb() // become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy "just about to write CR3" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.
- https://git.kernel.org/stable/c/02ad4ce144bd27f71f583f667fdf3b3ba0753477
- https://git.kernel.org/stable/c/12f703811af043d32b1c8a30001b2fa04d5cd0ac
- https://git.kernel.org/stable/c/399ec9ca8fc4999e676ff89a90184ec40031cf59
- https://git.kernel.org/stable/c/d41072906abec8bb8e01ed16afefbaa558908c89
- https://git.kernel.org/stable/c/d87392094f96e162fa5fa5a8640d70cc0952806f
- https://git.kernel.org/stable/c/fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-37965
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix invalid context error in dml helper [Why] "BUG: sleeping function called from invalid context" error. after: "drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()" The populate_dml_plane_cfg_from_plane_state() uses the GFP_KERNEL flag for memory allocation, which shouldn't be used in atomic contexts. The allocation is needed only for using another helper function get_scaler_data_for_plane(). [How] Modify helpers to pass a pointer to scaler_data within existing context, eliminating the need for dynamic memory allocation/deallocation and copying. (cherry picked from commit bd3e84bc98f81b44f2c43936bdadc3241d654259)
Modified: 2025-12-16
CVE-2025-37967
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix deadlock This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it.
- https://git.kernel.org/stable/c/364618c89d4c57c85e5fc51a2446cd939bf57802
- https://git.kernel.org/stable/c/5924b324468845fc795bd76f588f51d7ab4f202d
- https://git.kernel.org/stable/c/61fc1a8e1e10cc784cab5829930838aaf1d37af5
- https://git.kernel.org/stable/c/962ce9028ca6eb450d5c205238a3ee27de9d214d
- https://git.kernel.org/stable/c/f32451ca4cb7dc53f2a0e2e66b84d34162747eb7
- https://git.kernel.org/stable/c/f4bd982563c2fd41ec9ca6c517c392d759db801c
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37968
In the Linux kernel, the following vulnerability has been resolved: iio: light: opt3001: fix deadlock due to concurrent flag access The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.
- https://git.kernel.org/stable/c/1d7def97e7eb65865ccc01bbdf4eb9e6bbe8a5b5
- https://git.kernel.org/stable/c/2c95c8f0959d0a72575eabf2ff888f47ed6d8b77
- https://git.kernel.org/stable/c/748ebd8e61d0bc182c331b8df3887af7285c8a8f
- https://git.kernel.org/stable/c/7ca84f6a22d50bf8b31efe9eb05f9859947266d7
- https://git.kernel.org/stable/c/957e8be112636d9bc692917286e81e54bd87decc
- https://git.kernel.org/stable/c/a9c56ccb7cddfca754291fb24b108a5350a5fbe9
- https://git.kernel.org/stable/c/e791bf216c9e236b34dabf514ec0ede140cca719
- https://git.kernel.org/stable/c/f063a28002e3350088b4577c5640882bf4ea17ea
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-37969
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
- https://git.kernel.org/stable/c/16857370b3a30663515956b3bd27f3def6a2cf06
- https://git.kernel.org/stable/c/35b8c0a284983b71d92d082c54b7eb655ed4194f
- https://git.kernel.org/stable/c/4db7d923a8c298788181b796f71adf6ca499f966
- https://git.kernel.org/stable/c/76727a1d81afde77d21ea8feaeb12d34605be6f4
- https://git.kernel.org/stable/c/8114ef86e2058e2554111b793596f17bee23fa15
- https://git.kernel.org/stable/c/9ce662851380fe2018e36e15c0bdcb1ad177ed95
- https://git.kernel.org/stable/c/9ddb4cf2192c213e4dba1733bbcdc94cf6d85bf7
- https://git.kernel.org/stable/c/dadf9116108315f2eb14c7415c7805f392c476b4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37970
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
- https://git.kernel.org/stable/c/159ca7f18129834b6f4c7eae67de48e96c752fc9
- https://git.kernel.org/stable/c/3bb6c02d6fe8347ce1785016d135ff539c20043c
- https://git.kernel.org/stable/c/6c4a5000618a8c44200d455c92e2f2a4db264717
- https://git.kernel.org/stable/c/84e39f628a3a3333add99076e4d6c8b42b12d3a0
- https://git.kernel.org/stable/c/a1cad8a3bca41dead9980615d35efc7bff1fd534
- https://git.kernel.org/stable/c/da33c4167b9cc1266a97215114cb74679f881d0c
- https://git.kernel.org/stable/c/f06a1a1954527cc4ed086d926c81ff236b2adde9
- https://git.kernel.org/stable/c/f3cf233c946531a92fe651ff2bd15ebbe60630a7
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-14
CVE-2025-37971
In the Linux kernel, the following vulnerability has been resolved: staging: bcm2835-camera: Initialise dev in v4l2_dev Commit 42a2f6664e18 ("staging: vc04_services: Move global g_state to vchiq_state") changed mmal_init to pass dev->v4l2_dev.dev to vchiq_mmal_init, however nothing iniitialised dev->v4l2_dev, so we got a NULL pointer dereference. Set dev->v4l2_dev.dev during bcm2835_mmal_probe. The device pointer could be passed into v4l2_device_register to set it, however that also has other effects that would need additional changes.
Modified: 2025-12-16
CVE-2025-37972
In the Linux kernel, the following vulnerability has been resolved: Input: mtk-pmic-keys - fix possible null pointer dereference In mtk_pmic_keys_probe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer. Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.
- https://git.kernel.org/stable/c/09429ddb5a91e9e8f72cd18c012ec4171c2f85ec
- https://git.kernel.org/stable/c/11cdb506d0fbf5ac05bf55f5afcb3a215c316490
- https://git.kernel.org/stable/c/334d74a798463ceec02a41eb0e2354aaac0d6249
- https://git.kernel.org/stable/c/619c05fb176c272ac6cecf723446b39723ee6d97
- https://git.kernel.org/stable/c/90fa6015ff83ef1c373cc61b7c924ab2bcbe1801
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-37973
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation Currently during the multi-link element defragmentation process, the multi-link element length added to the total IEs length when calculating the length of remaining IEs after the multi-link element in cfg80211_defrag_mle(). This could lead to out-of-bounds access if the multi-link element or its corresponding fragment elements are the last elements in the IEs buffer. To address this issue, correctly calculate the remaining IEs length by deducting the multi-link element end offset from total IEs end offset.
Modified: 2025-11-14
CVE-2025-37974
In the Linux kernel, the following vulnerability has been resolved: s390/pci: Fix missing check for zpci_create_device() error return The zpci_create_device() function returns an error pointer that needs to be checked before dereferencing it as a struct zpci_dev pointer. Add the missing check in __clp_add() where it was missed when adding the scan_list in the fixed commit. Simply not adding the device to the scan list results in the previous behavior.
Modified: 2025-11-14
CVE-2025-37984
In the Linux kernel, the following vulnerability has been resolved: crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8): X / 8 + !!(X & 7) Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values. Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs().
Modified: 2025-12-16
CVE-2025-37992
In the Linux kernel, the following vulnerability has been resolved: net_sched: Flush gso_skb list too during ->change() Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.
- https://git.kernel.org/stable/c/2d3cbfd6d54a2c39ce3244f33f85c595844bd7b8
- https://git.kernel.org/stable/c/a7d6e0ac0a8861f6b1027488062251a8e28150fd
- https://git.kernel.org/stable/c/d1365ca80b012d8a7863e45949e413fb61fa4861
- https://git.kernel.org/stable/c/d3336f746f196c6a53e0480923ae93939f047b6c
- https://git.kernel.org/stable/c/d38939ebe0d992d581acb6885c1723fa83c1fb2c
- https://git.kernel.org/stable/c/ea1132ccb112f51ba749c56a912f67970c2cd542
- https://git.kernel.org/stable/c/fe88c7e4fc2c1cd75a278a15ffbf1689efad4e76
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-14
CVE-2025-37993
In the Linux kernel, the following vulnerability has been resolved:
can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probe
The spin lock tx_handling_spinlock in struct m_can_classdev is not
being initialized. This leads the following spinlock bad magic
complaint from the kernel, eg. when trying to send CAN frames with
cansend from can-utils:
| BUG: spinlock bad magic on CPU#0, cansend/95
| lock: 0xff60000002ec1010, .magic: 00000000, .owner:
Modified: 2025-12-16
CVE-2025-37994
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix NULL pointer access This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.
- https://git.kernel.org/stable/c/076ab0631ed4928905736f1701e25f1e722bc086
- https://git.kernel.org/stable/c/14f298c52188c34acde9760bf5abc669c5c36fdb
- https://git.kernel.org/stable/c/312d79669e71283d05c05cc49a1a31e59e3d9e0e
- https://git.kernel.org/stable/c/5ad298d6d4aebe1229adba6427e417e89a5208d8
- https://git.kernel.org/stable/c/7804c4d63edfdd5105926cc291e806e8f4ce01b5
- https://git.kernel.org/stable/c/9dda1e2a666a8a32ce0f153b5dee05c7351f1020
- https://git.kernel.org/stable/c/a9931f1b52b2d0bf3952e003fd5901ea7eb851ed
- https://git.kernel.org/stable/c/e9b63faf5c97deb43fc39a52edbc39d626cc14bf
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37995
In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.
- https://git.kernel.org/stable/c/31d8df3f303c3ae9115230820977ef8c35c88808
- https://git.kernel.org/stable/c/93799fb988757cdacf19acba57807746c00378e6
- https://git.kernel.org/stable/c/9e7b49ce4f9d0cb5b6e87db9e07a2fb9e754b0dd
- https://git.kernel.org/stable/c/a63d99873547d8b39eb2f6db79dd235761e7098a
- https://git.kernel.org/stable/c/a6aeb739974ec73e5217c75a7c008a688d3d5cf1
- https://git.kernel.org/stable/c/d63851049f412cdfadaeef7a7eaef5031d11c1e9
- https://git.kernel.org/stable/c/f1c71b4bd721a4ea21da408806964b10468623f2
- https://git.kernel.org/stable/c/faa9059631d3491d699c69ecf512de9e1a3d6649
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37997
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix region locking in hash types Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.
- https://git.kernel.org/stable/c/00cfc5fad1491796942a948808afb968a0a3f35b
- https://git.kernel.org/stable/c/226ce0ec38316d9e3739e73a64b6b8304646c658
- https://git.kernel.org/stable/c/6e002ecc1c8cfdfc866b9104ab7888da54613e59
- https://git.kernel.org/stable/c/82c1eb32693bc48251d92532975e19160987e5b9
- https://git.kernel.org/stable/c/8478a729c0462273188263136880480729e9efca
- https://git.kernel.org/stable/c/a3dfec485401943e315c394c29afe2db8f9481d6
- https://git.kernel.org/stable/c/aa77294b0f73bb8265987591460cd25b8722c3df
- https://git.kernel.org/stable/c/e2ab67672b2288521a6146034a971f9a82ffc5c5
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37998
In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.
- https://git.kernel.org/stable/c/0236742bd959332181c1fcc41a05b7b709180501
- https://git.kernel.org/stable/c/06b4f110c79716c181a8c5da007c259807840232
- https://git.kernel.org/stable/c/47f7f00cf2fa3137d5c0416ef1a71bdf77901395
- https://git.kernel.org/stable/c/4fa672cbce9c86c3efb8621df1ae580d47813430
- https://git.kernel.org/stable/c/6712dc21506738f5f22b4f68b7c0d9e0df819dbd
- https://git.kernel.org/stable/c/6beb6835c1fbb3f676aebb51a5fee6b77fed9308
- https://git.kernel.org/stable/c/bca8df998cce1fead8cbc69144862eadc2e34c87
- https://git.kernel.org/stable/c/ec334aaab74705cc515205e1da3cb369fdfd93cd
- https://www.zerodayinitiative.com/advisories/ZDI-25-307/
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-14
CVE-2025-37999
In the Linux kernel, the following vulnerability has been resolved: fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio() If bio_add_folio() fails (because it is full), erofs_fileio_scan_folio() needs to submit the I/O request via erofs_fileio_rq_submit() and allocate a new I/O request with an empty `struct bio`. Then it retries the bio_add_folio() call. However, at this point, erofs_onlinefolio_split() has already been called which increments `folio->private`; the retry will call erofs_onlinefolio_split() again, but there will never be a matching erofs_onlinefolio_end() call. This leaves the folio locked forever and all waiters will be stuck in folio_wait_bit_common(). This bug has been added by commit ce63cb62d794 ("erofs: support unencoded inodes for fileio"), but was practically unreachable because there was room for 256 folios in the `struct bio` - until commit 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") which reduced the array capacity to 16 folios. It was now trivial to trigger the bug by manually invoking readahead from userspace, e.g.: posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED); This should be fixed by invoking erofs_onlinefolio_split() only after bio_add_folio() has succeeded. This is safe: asynchronous completions invoking erofs_onlinefolio_end() will not unlock the folio because erofs_fileio_scan_folio() is still holding a reference to be released by erofs_onlinefolio_end() at the end.
Modified: 2025-12-16
CVE-2025-38000
In the Linux kernel, the following vulnerability has been resolved: sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue() When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free. This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.
- https://git.kernel.org/stable/c/1034e3310752e8675e313f7271b348914008719a
- https://git.kernel.org/stable/c/3f3a22eebbc32b4fa8ce9c1d5f9db214b45b9335
- https://git.kernel.org/stable/c/3f981138109f63232a5fb7165938d4c945cc1b9d
- https://git.kernel.org/stable/c/49b21795b8e5654a7df3d910a12e1060da4c04cf
- https://git.kernel.org/stable/c/89c301e929a0db14ebd94b4d97764ce1d6981653
- https://git.kernel.org/stable/c/93c276942e75de0e5bc91576300d292e968f5a02
- https://git.kernel.org/stable/c/f1dde3eb17dc1b8bd07aed00004b1e05fc87a3d4
- https://git.kernel.org/stable/c/f9f593e34d2fb67644372c8f7b033bdc622ad228
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-07
CVE-2025-38001
In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Address reentrant enqueue adding class to eltree twice Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM. The patch only checks the cl->cl_nactive field to determine whether it is the first insertion or not [2], but this field is only incremented by init_vf [3]. By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the check and insert the class twice in the eltree. Under normal conditions, this would lead to an infinite loop in hfsc_dequeue for the reasons we already explained in this report [5]. However, if TBF is added as root qdisc and it is configured with a very low rate, it can be utilized to prevent packets from being dequeued. This behavior can be exploited to perform subsequent insertions in the HFSC eltree and cause a UAF." To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set. [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u
- https://git.kernel.org/stable/c/295f7c579b07b5b7cf2dffe485f71cc2f27647cb
- https://git.kernel.org/stable/c/2c928b3a0b04a431ffcd6c8b7d88a267124a3a28
- https://git.kernel.org/stable/c/2f2190ce4ca972051cac6a8d7937448f8cb9673c
- https://git.kernel.org/stable/c/39ed887b1dd2d6b720f87e86692ac3006cc111c8
- https://git.kernel.org/stable/c/4e38eaaabfb7fffbb371a51150203e19eee5d70e
- https://git.kernel.org/stable/c/6672e6c00810056acaac019fe26cdc26fee8a66c
- https://git.kernel.org/stable/c/a0ec22fa20b252edbe070a9de8501eef63c17ef5
- https://git.kernel.org/stable/c/ac9fe7dd8e730a103ae4481147395cc73492d786
- https://git.kernel.org/stable/c/e5bee633cc276410337d54b99f77fbc1ad8801e5
- https://syst3mfailure.io/rbtree-family-drama/
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
- https://syst3mfailure.io/rbtree-family-drama/
Modified: 2025-12-17
CVE-2025-38003
In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu read protection for procfs content When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF). As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.
- https://git.kernel.org/stable/c/0622846db728a5332b917c797c733e202c4620ae
- https://git.kernel.org/stable/c/19f553a1ddf260da6570ed8f8d91a8c87f49b63a
- https://git.kernel.org/stable/c/1f912f8484e9c4396378c39460bbea0af681f319
- https://git.kernel.org/stable/c/63567ecd99a24495208dc860d50fb17440043006
- https://git.kernel.org/stable/c/659701c0b954ccdb4a916a4ad59bbc16e726d42c
- https://git.kernel.org/stable/c/6d7d458c41b98a5c1670cbd36f2923c37de51cf5
- https://git.kernel.org/stable/c/7c9db92d5f0eadca30884af75c53d601edc512ee
- https://git.kernel.org/stable/c/dac5e6249159ac255dad9781793dbe5908ac9ddb
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38004
In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.
- https://git.kernel.org/stable/c/2a437b86ac5a9893c902f30ef66815bf13587bf6
- https://git.kernel.org/stable/c/7595de7bc56e0e52b74e56c90f7e247bf626d628
- https://git.kernel.org/stable/c/76c84c3728178b2d38d5604e399dfe8b0752645e
- https://git.kernel.org/stable/c/8f1c022541bf5a923c8d6fa483112c15250f30a4
- https://git.kernel.org/stable/c/c2aba69d0c36a496ab4f2e81e9c2b271f2693fd7
- https://git.kernel.org/stable/c/c4e8a172501e677ebd8ea9d9161d97dc4df56fbd
- https://git.kernel.org/stable/c/cc55dd28c20a6611e30596019b3b2f636819a4c0
- https://git.kernel.org/stable/c/fbd8fdc2b218e979cfe422b139b8f74c12419d1f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38005
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma: Add missing locking
Recent kernels complain about a missing lock in k3-udma.c when the lock
validator is enabled:
[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238
[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28
[ 4.144867] Hardware name: pp-v12 (DT)
[ 4.148648] Workqueue: events udma_check_tx_completion
[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4.160834] pc : udma_start.isra.0+0x34/0x238
[ 4.165227] lr : udma_start.isra.0+0x30/0x238
[ 4.169618] sp : ffffffc083cabcf0
[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005
[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000
[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670
[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030
[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048
[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001
[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68
[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8
[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000
[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000
[ 4.244986] Call trace:
[ 4.247463] udma_start.isra.0+0x34/0x238
[ 4.251509] udma_check_tx_completion+0xd0/0xdc
[ 4.256076] process_one_work+0x244/0x3fc
[ 4.260129] process_scheduled_works+0x6c/0x74
[ 4.264610] worker_thread+0x150/0x1dc
[ 4.268398] kthread+0xd8/0xe8
[ 4.271492] ret_from_fork+0x10/0x20
[ 4.275107] irq event stamp: 220
[ 4.278363] hardirqs last enabled at (219): [
- https://git.kernel.org/stable/c/0ea0433f822ed0549715f7044c9cd1cf132ff7fa
- https://git.kernel.org/stable/c/26e63b2fe30c61bd25981c6084f67a8af79945d0
- https://git.kernel.org/stable/c/27e71fa08711e09d81e06a54007b362a5426fd22
- https://git.kernel.org/stable/c/99df1edf17493cb49a8c01f6bde55c3abb6a2a6c
- https://git.kernel.org/stable/c/d87f1cddc592387359fde157cc4296556f6403c2
- https://git.kernel.org/stable/c/df5987e76a4ae4cbd705d81ab4b15ed232250a4a
- https://git.kernel.org/stable/c/fca280992af8c2fbd511bc43f65abb4a17363f2f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2026-04-18
CVE-2025-38006
In the Linux kernel, the following vulnerability has been resolved: net: mctp: Don't access ifa_index when missing In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox "ip addr show". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309
- https://git.kernel.org/stable/c/24fa213dffa470166ec014f979f36c6ff44afb45
- https://git.kernel.org/stable/c/8ef7b3f0db69e2f4a80be351f6aee9a4c2332ef9
- https://git.kernel.org/stable/c/acab78ae12c7fefb4f3bfe22e00770a5faa42724
- https://git.kernel.org/stable/c/d4d1561d17eb72908e4489c0900d96e0484fac20
- https://git.kernel.org/stable/c/f11cf946c0a92c560a890d68e4775723353599e1
Modified: 2026-03-17
CVE-2025-38007
In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: Add NULL check in uclogic_input_configured() devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.
- https://git.kernel.org/stable/c/00d52b2fa6083dd0f5c44f3604cd1bad1f9177dc
- https://git.kernel.org/stable/c/01b76cc8ca243fc3376b035aa326bbc4f03d384b
- https://git.kernel.org/stable/c/94e7272b636a0677082e0604609e4c471e0a2caf
- https://git.kernel.org/stable/c/a9f58479a1a2c6f72907679c4df2f4ed92b05b39
- https://git.kernel.org/stable/c/ad6caaf29bc26a48b1241ce82561fcbcf0a75aa9
- https://git.kernel.org/stable/c/b616453d719ee1b8bf2ea6f6cc6c6258a572a590
- https://git.kernel.org/stable/c/bd07f751208ba190f9b0db5e5b7f35d5bb4a8a1e
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-38008
In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix race condition in unaccepted memory handling The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machinery detects it: WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */ The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether.
Modified: 2025-12-17
CVE-2025-38009
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: disable napi on driver removal
A warning on driver removal started occurring after commit 9dd05df8403b
("net: warn if NAPI instance wasn't shut down"). Disable tx napi before
deleting it in mt76_dma_cleanup().
WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100
CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy)
Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024
RIP: 0010:__netif_napi_del_locked+0xf0/0x100
Call Trace:
- https://git.kernel.org/stable/c/2b81e76db3667d1f7f2ad44e9835cdaf8dea95a8
- https://git.kernel.org/stable/c/5e700b06b970fc19e3a1ecb244e14785f3fbb8e3
- https://git.kernel.org/stable/c/78ab4be549533432d97ea8989d2f00b508fa68d8
- https://git.kernel.org/stable/c/b892e830d1ea8c5475254b98827771f7366f1039
- https://git.kernel.org/stable/c/ca5b213bf4b4224335a8131a26805d16503fca5f
- https://git.kernel.org/stable/c/e7bfbda5fddd27f3158e723d641c0fcdfb0552a7
- https://git.kernel.org/stable/c/ff0f820fa5b99035b3c654dd531226d8d83aec5f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-38010
In the Linux kernel, the following vulnerability has been resolved: phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as: [ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270 The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count. To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually. With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles. The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask.
Modified: 2026-03-17
CVE-2025-38011
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: csa unmap use uninterruptible lock
After process exit to unmap csa and free GPU vm, if signal is accepted
and then waiting to take vm lock is interrupted and return, it causes
memory leaking and below warning backtrace.
Change to use uninterruptible wait lock fix the issue.
WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525
amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]
Call Trace:
Modified: 2025-11-17
CVE-2025-38012
In the Linux kernel, the following vulnerability has been resolved: sched_ext: bpf_iter_scx_dsq_new() should always initialize iterator BPF programs may call next() and destroy() on BPF iterators even after new() returns an error value (e.g. bpf_for_each() macro ignores error returns from new()). bpf_iter_scx_dsq_new() could leave the iterator in an uninitialized state after an error return causing bpf_iter_scx_dsq_next() to dereference garbage data. Make bpf_iter_scx_dsq_new() always clear $kit->dsq so that next() and destroy() become noops.
Modified: 2025-11-17
CVE-2025-38013
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request Make sure that n_channels is set after allocating the struct cfg80211_registered_device::int_scan_req member. Seen with syzkaller: UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]') This was missed in the initial conversions because I failed to locate the allocation likely due to the "sizeof(void *)" not matching the "channels" array type.
Modified: 2025-11-14
CVE-2025-38014
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Refactor remove call with idxd_cleanup() helper The idxd_cleanup() helper cleans up perfmon, interrupts, internals and so on. Refactor remove call with the idxd_cleanup() helper to avoid code duplication. Note, this also fixes the missing put_device() for idxd groups, enginces and wqs.
Modified: 2025-12-17
CVE-2025-38015
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix memory leak in error handling path of idxd_alloc Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error.
- https://git.kernel.org/stable/c/46a5cca76c76c86063000a12936f8e7875295838
- https://git.kernel.org/stable/c/4f005eb68890698e5abc6a3af04dab76f175c50c
- https://git.kernel.org/stable/c/64afd9a1f644b27661420257dcc007d5009c99dd
- https://git.kernel.org/stable/c/6e94a2c3e4c166cd2736ac225fba5889fb1e8ac0
- https://git.kernel.org/stable/c/868dbce755ec92855362d213f47e045a8388361a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-38016
In the Linux kernel, the following vulnerability has been resolved: HID: bpf: abort dispatch if device destroyed The current HID bpf implementation assumes no output report/request will go through it after hid_bpf_destroy_device() has been called. This leads to a bug that unplugging certain types of HID devices causes a cleaned- up SRCU to be accessed. The bug was previously a hidden failure until a recent x86 percpu change [1] made it access not-present pages. The bug will be triggered if the conditions below are met: A) a device under the driver has some LEDs on B) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver) If condition A is met, hidinput_led_worker() is always scheduled *after* hid_bpf_destroy_device(). hid_destroy_device ` hid_bpf_destroy_device ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device ` ... ` led_classdev_unregister ` led_trigger_set(led_cdev, NULL) ` led_set_brightness(led_cdev, LED_OFF) ` ... ` input_inject_event ` input_event_dispose ` hidinput_input_event ` schedule_work(&hid->led_work) [hidinput_led_worker] This is fine when condition B is not met, where hidinput_led_worker() calls hid_ll_driver->request(). This is the case for most HID drivers, which implement it or use the generic one from usbhid. The driver itself or an underlying driver will then abort processing the request. Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads to the bug. hidinput_led_worker ` hid_hw_output_report ` dispatch_hid_bpf_output_report ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) The bug has existed since the introduction [2] of dispatch_hid_bpf_output_report(). However, the same bug also exists in dispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect because of the lack of [1], but confirmed bpf.destroyed == 1) the bug against the commit (i.e., the Fixes:) introducing the function. This is because hidinput_led_worker() falls back to hid_hw_raw_request() when hid_ll_driver->output_report() is uninplemented (e.g., logitech- djreceiver). hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request ` dispatch_hid_bpf_raw_requests ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) Fix the issue by returning early in the two mentioned functions if hid_bpf has been marked as destroyed. Though dispatch_hid_bpf_device_event() handles input events, and there is no evidence that it may be called after the destruction, the same check, as a safety net, is also added to it to maintain the consistency among all dispatch functions. The impact of the bug on other architectures is unclear. Even if it acts as a hidden failure, this is still dangerous because it corrupts whatever is on the address calculated by SRCU. Thus, CC'ing the stable list. [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets") [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for hid_hw_output_report")
Modified: 2025-12-17
CVE-2025-38018
In the Linux kernel, the following vulnerability has been resolved: net/tls: fix kernel panic when alloc_page failed We cannot set frag_list to NULL pointer when alloc_page failed. It will be used in tls_strp_check_queue_ok when the next time tls_strp_read_sock is called. This is because we don't reset full_len in tls_strp_flush_anchor_copy() so the recv path will try to continue handling the partial record on the next call but we dettached the rcvq from the frag list. Alternative fix would be to reset full_len. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Call trace: tls_strp_check_rcv+0x128/0x27c tls_strp_data_ready+0x34/0x44 tls_data_ready+0x3c/0x1f0 tcp_data_ready+0x9c/0xe4 tcp_data_queue+0xf6c/0x12d0 tcp_rcv_established+0x52c/0x798
- https://git.kernel.org/stable/c/406d05da26835943568e61bb751c569efae071d4
- https://git.kernel.org/stable/c/491deb9b8c4ad12fe51d554a69b8165b9ef9429f
- https://git.kernel.org/stable/c/5f1f833cb388592bb46104463a1ec1b7c41975b6
- https://git.kernel.org/stable/c/8f7f96549bc55e4ef3a6b499bc5011e5de2f46c4
- https://git.kernel.org/stable/c/a11b8c0be6acd0505a58ff40d474bd778b25b93a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-38019
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices
The driver only offloads neighbors that are constructed on top of net
devices registered by it or their uppers (which are all Ethernet). The
device supports GRE encapsulation and decapsulation of forwarded
traffic, but the driver will not offload dummy neighbors constructed on
top of GRE net devices as they are not uppers of its net devices:
# ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1
# ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1
$ ip neigh show dev gre1 nud noarp
0.0.0.0 lladdr 0.0.0.0 NOARP
(Note that the neighbor is not marked with 'offload')
When the driver is reloaded and the existing configuration is replayed,
the driver does not perform the same check regarding existing neighbors
and offloads the previously added one:
# devlink dev reload pci/0000:01:00.0
$ ip neigh show dev gre1 nud noarp
0.0.0.0 lladdr 0.0.0.0 offload NOARP
If the neighbor is later deleted, the driver will ignore the
notification (given the GRE net device is not its upper) and will
therefore keep referencing freed memory, resulting in a use-after-free
[1] when the net device is deleted:
# ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1
# ip link del dev gre1
Fix by skipping neighbor replay if the net device for which the replay
is performed is not our upper.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200
Read of size 8 at addr ffff888155b0e420 by task ip/2282
[...]
Call Trace:
Modified: 2025-12-17
CVE-2025-38020
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Disable MACsec offload for uplink representor profile
MACsec offload is not supported in switchdev mode for uplink
representors. When switching to the uplink representor profile, the
MACsec offload feature must be cleared from the netdevice's features.
If left enabled, attempts to add offloads result in a null pointer
dereference, as the uplink representor does not support MACsec offload
even though the feature bit remains set.
Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().
Kernel log:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]
CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:__mutex_lock+0x128/0x1dd0
Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff
RSP: 0018:ffff888147a4f160 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078
RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000
FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1a69d53922c1221351739f17837d38e317234e5d
- https://git.kernel.org/stable/c/1e577aeb51e9deba4f2c10edfcb07cb3cb406598
- https://git.kernel.org/stable/c/1f80e6ff026041721d8089da8c269b1963628325
- https://git.kernel.org/stable/c/588431474eb7572e57a927fa8558c9ba2f8af143
- https://git.kernel.org/stable/c/b48a47e137cedfd79655accaeeea6b296ad0b9e1
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2026-01-19
CVE-2025-38022
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes. The root cause is: the function ib_device_rename() renames the name with lock. But in the function kobject_uevent(), this name is accessed without lock protection at the same time. The solution is to add the lock protection when this name is accessed in the function kobject_uevent().
- https://git.kernel.org/stable/c/03df57ad4b0ff9c5a93ff981aba0b42578ad1571
- https://git.kernel.org/stable/c/10c7f1c647da3b77ef8827d974a97b6530b64df0
- https://git.kernel.org/stable/c/17d3103325e891e10994e7aa28d12bea04dc2c60
- https://git.kernel.org/stable/c/312dae3499106ec8cb7442ada12be080aa9fbc3b
- https://git.kernel.org/stable/c/5629064f92f0de6d6b3572055cd35361c3ad953c
- https://git.kernel.org/stable/c/ba467b6870ea2a73590478d9612d6ea1dcdd68b7
- https://git.kernel.org/stable/c/d0706bfd3ee40923c001c6827b786a309e2a8713
Modified: 2025-12-17
CVE-2025-38023
In the Linux kernel, the following vulnerability has been resolved:
nfs: handle failure of nfs_get_lock_context in unlock path
When memory is insufficient, the allocation of nfs_lock_context in
nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat
an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)
as valid and proceed to execute rpc_run_task(), this will trigger a NULL
pointer dereference in nfs4_locku_prepare. For example:
BUG: kernel NULL pointer dereference, address: 000000000000000c
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40
Workqueue: rpciod rpc_async_schedule
RIP: 0010:nfs4_locku_prepare+0x35/0xc2
Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3
RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246
RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40
RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38
R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030
R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30
FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/4c189fd40a09a03f9a900bedb2d9064f1734d72a
- https://git.kernel.org/stable/c/72f552e00c50f265896d3c19edc6696aa2910081
- https://git.kernel.org/stable/c/85fb7f8ca5f8c138579fdfc9b97b3083e6077d40
- https://git.kernel.org/stable/c/a6879a076b98c99c9fe747816fe1c29543442441
- https://git.kernel.org/stable/c/c457dc1ec770a22636b473ce5d35614adfe97636
- https://git.kernel.org/stable/c/da824f1271633bcb515ca8084cda3eda4b3ace51
- https://git.kernel.org/stable/c/db6f5ee1fc8f54d079d0751292c2fc2d78e3aad1
- https://git.kernel.org/stable/c/f601960af04d2ecb007c928ba153d34051acd9c1
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-38024
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug
Call Trace:
- https://git.kernel.org/stable/c/16c45ced0b3839d3eee72a86bb172bef6cf58980
- https://git.kernel.org/stable/c/336edd6b0f5b7fbffc3e065285610624f59e88df
- https://git.kernel.org/stable/c/3a3b73e135e3bd18423d0baa72571319c7feb759
- https://git.kernel.org/stable/c/52daccfc3fa68ee1902d52124921453d7a335591
- https://git.kernel.org/stable/c/7c7c80c32e00665234e373ab03fe82f5c5c2c230
- https://git.kernel.org/stable/c/ee4c5a2a38596d548566560c0c022ab797e6f71a
- https://git.kernel.org/stable/c/f81b33582f9339d2dc17c69b92040d3650bb4bae
- https://git.kernel.org/stable/c/f8f470e3a757425a8f98fb9a5991e3cf62fc7134
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-18
CVE-2025-38027
In the Linux kernel, the following vulnerability has been resolved: regulator: max20086: fix invalid memory access max20086_parse_regulators_dt() calls of_regulator_match() using an array of struct of_regulator_match allocated on the stack for the matches argument. of_regulator_match() calls devm_of_regulator_put_matches(), which calls devres_alloc() to allocate a struct devm_of_regulator_matches which will be de-allocated using devm_of_regulator_put_matches(). struct devm_of_regulator_matches is populated with the stack allocated matches array. If the device fails to probe, devm_of_regulator_put_matches() will be called and will try to call of_node_put() on that stack pointer, generating the following dmesg entries: max20086 6-0028: Failed to read DEVICE_ID reg: -121 kobject: '\xc0$\xa5\x03' (000000002cebcb7a): is not initialized, yet kobject_put() is being called. Followed by a stack trace matching the call flow described above. Switch to allocating the matches array using devm_kcalloc() to avoid accessing the stack pointer long after it's out of scope. This also has the advantage of allowing multiple max20086 to probe without overriding the data stored inside the global of_regulator_match.
- https://git.kernel.org/stable/c/5578ab04bd7732f470fc614bbc0a924900399fb8
- https://git.kernel.org/stable/c/6b0cd72757c69bc2d45da42b41023e288d02e772
- https://git.kernel.org/stable/c/6ba30f7aa2c550b2ac04f16b81a19a8c045b8660
- https://git.kernel.org/stable/c/7bddac8603d4e396872c2fbf4403ec08e7b1d7c8
- https://git.kernel.org/stable/c/d2a9a92bb4cc7568cff68241b0051dc7268bdc68
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-18
CVE-2025-38031
In the Linux kernel, the following vulnerability has been resolved: padata: do not leak refcount in reorder_work A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented. Fix this by checking the return value of queue_work() and decrementing the refcount when necessary. Resolves: Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30
- https://git.kernel.org/stable/c/1a426abdf1c86882c9203dd8182f3b8274b89938
- https://git.kernel.org/stable/c/1c65ae4988714716101555fe2b9830e33136d6fb
- https://git.kernel.org/stable/c/5300e487487d7a2e3e1e6e9d8f03ed9452e4019e
- https://git.kernel.org/stable/c/584a729615fa92f4de45480efb7e569d14be1516
- https://git.kernel.org/stable/c/b9ad8e50e8589607e68e6c4cefa7f72bf35a2cb1
- https://git.kernel.org/stable/c/cceb15864e1612ebfbc10ec4e4dcd19a10c0056c
- https://git.kernel.org/stable/c/d6ebcde6d4ecf34f8495fb30516645db3aea8993
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-14
CVE-2025-38033
In the Linux kernel, the following vulnerability has been resolved: x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST or Rust >= 1.88 Calling core::fmt::write() from rust code while FineIBT is enabled results in a kernel panic: [ 4614.199779] kernel BUG at arch/x86/kernel/cet.c:132! [ 4614.205343] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 4614.211781] CPU: 2 UID: 0 PID: 6057 Comm: dmabuf_dump Tainted: G U O 6.12.17-android16-0-g6ab38c534a43 #1 9da040f27673ec3945e23b998a0f8bd64c846599 [ 4614.227832] Tainted: [U]=USER, [O]=OOT_MODULE [ 4614.241247] RIP: 0010:do_kernel_cp_fault+0xea/0xf0 ... [ 4614.398144] RIP: 0010:_RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x0/0x20 [ 4614.407792] Code: 48 f7 df 48 0f 48 f9 48 89 f2 89 c6 5d e9 18 fd ff ff 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 41 81 ea 14 61 af 2c 74 03 0f 0b 90 <66> 0f 1f 00 55 48 89 e5 48 89 f2 48 8b 3f be 01 00 00 00 5d e9 e7 [ 4614.428775] RSP: 0018:ffffb95acfa4ba68 EFLAGS: 00010246 [ 4614.434609] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 0000000000000000 [ 4614.442587] RDX: 0000000000000007 RSI: ffffb95acfa4ba70 RDI: ffffb95acfa4bc88 [ 4614.450557] RBP: ffffb95acfa4bae0 R08: ffff0a00ffffff05 R09: 0000000000000070 [ 4614.458527] R10: 0000000000000000 R11: ffffffffab67eaf0 R12: ffffb95acfa4bcc8 [ 4614.466493] R13: ffffffffac5d50f0 R14: 0000000000000000 R15: 0000000000000000 [ 4614.474473] ? __cfi__RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x10/0x10 [ 4614.484118] ? _RNvNtCs3o2tGsuHyou_4core3fmt5write+0x1d2/0x250 This happens because core::fmt::write() calls core::fmt::rt::Argument::fmt(), which currently has CFI disabled: library/core/src/fmt/rt.rs: 171 // FIXME: Transmuting formatter in new and indirectly branching to/calling 172 // it here is an explicit CFI violation. 173 #[allow(inline_no_sanitize)] 174 #[no_sanitize(cfi, kcfi)] 175 #[inline] 176 pub(super) unsafe fn fmt(&self, f: &mut Formatter<'_>) -> Result { This causes a Control Protection exception, because FineIBT has sealed off the original function's endbr64. This makes rust currently incompatible with FineIBT. Add a Kconfig dependency that prevents FineIBT from getting turned on by default if rust is enabled. [ Rust 1.88.0 (scheduled for 2025-06-26) should have this fixed [1], and thus we relaxed the condition with Rust >= 1.88. When `objtool` lands checking for this with e.g. [2], the plan is to ideally run that in upstream Rust's CI to prevent regressions early [3], since we do not control `core`'s source code. Alice tested the Rust PR backported to an older compiler. Peter would like that Rust provides a stable `core` which can be pulled into the kernel: "Relying on that much out of tree code is 'unfortunate'". - Miguel ] [ Reduced splat. - Miguel ]
Modified: 2025-12-17
CVE-2025-38034
In the Linux kernel, the following vulnerability has been resolved:
btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref
btrfs_prelim_ref() calls the old and new reference variables in the
incorrect order. This causes a NULL pointer dereference because oldref
is passed as NULL to trace_btrfs_prelim_ref_insert().
Note, trace_btrfs_prelim_ref_insert() is being called with newref as
oldref (and oldref as NULL) on purpose in order to print out
the values of newref.
To reproduce:
echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable
Perform some writeback operations.
Backtrace:
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130
Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88
RSP: 0018:ffffce44820077a0 EFLAGS: 00010286
RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b
RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010
R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000
R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540
FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/0528bba48dce7820d2da72e1a114e1c4552367eb
- https://git.kernel.org/stable/c/137bfa08c6441f324d00692d1e9d22cfd773329b
- https://git.kernel.org/stable/c/5755b6731655e248c4f1d52a2e1b18795b4a2a3a
- https://git.kernel.org/stable/c/7a97f961a568a8f72472dc804af02a0f73152c5f
- https://git.kernel.org/stable/c/7f7c8c03feba5f2454792fab3bb8bd45bd6883f9
- https://git.kernel.org/stable/c/a641154cedf9d69730f8af5d0a901fe86e6486bd
- https://git.kernel.org/stable/c/a876703894a6dd6e8c04b0635d86e9f7a7c81b79
- https://git.kernel.org/stable/c/bc7e0975093567f51be8e1bdf4aa5900a3cf0b1e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38035
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: don't restore null sk_state_change
queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if
the TCP connection isn't established when nvmet_tcp_set_queue_sock() is
called then queue->state_change isn't set and sock->sk->sk_state_change
isn't replaced.
As such we don't need to restore sock->sk->sk_state_change if
queue->state_change is NULL.
This avoids NULL pointer dereferences such as this:
[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode
[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page
[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0
[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI
[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)
[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[ 286.467147][ C0] RIP: 0010:0x0
[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246
[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43
[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100
[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c
[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3
[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268
[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000
[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0
[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400
[ 286.475453][ C0] Call Trace:
[ 286.476102][ C0]
- https://git.kernel.org/stable/c/17e58be5b49f58bf17799a504f55c2d05ab2ecdc
- https://git.kernel.org/stable/c/3a982ada411b8c52695f1784c3f4784771f30209
- https://git.kernel.org/stable/c/46d22b47df2741996af277a2838b95f130436c13
- https://git.kernel.org/stable/c/6265538446e2426f4bf3b57e91d7680b2047ddd9
- https://git.kernel.org/stable/c/a21cb31642ffc84ca4ce55028212a96f72f54d30
- https://git.kernel.org/stable/c/c240375587ddcc80e1022f52ee32b946bbc3a639
- https://git.kernel.org/stable/c/ec462449f4cf616b0aa2ed119f5f44b5fdfcefab
- https://git.kernel.org/stable/c/fc01b547c3f8bfa6e1d23cd5a2c63c736e8c3e4e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38037
In the Linux kernel, the following vulnerability has been resolved: vxlan: Annotate FDB data races The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2]. Suppress these reports by annotating these accesses using READ_ONCE() / WRITE_ONCE(). [1] BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f Reported by Kernel Concurrency Sanitizer on: CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
- https://git.kernel.org/stable/c/02a33b1035a307453a1da6ce0a1bf3676be287d7
- https://git.kernel.org/stable/c/13cba3f837903f7184d6e9b6137d5165ffe82a8f
- https://git.kernel.org/stable/c/4eceb7eae6ea7c950384c34e6dbbe872c981935f
- https://git.kernel.org/stable/c/784b78295a3a58bf052339dd669e6e03710220d3
- https://git.kernel.org/stable/c/87d076987a9ba106c83412fcd113656f71af05a1
- https://git.kernel.org/stable/c/a6644aeb8ddf196dec5f8e782293c36f065df4d7
- https://git.kernel.org/stable/c/e033da39fc6abbddab6c29624acef80757f273fa
- https://git.kernel.org/stable/c/f6205f8215f12a96518ac9469ff76294ae7bd612
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-14
CVE-2025-38038
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boost set_boost is a per-policy function call, hence a driver wide lock is unnecessary. Also this mutex_acquire can collide with the mutex_acquire from the mode-switch path in status_store(), which can lead to a deadlock. So, remove it.
Modified: 2025-11-14
CVE-2025-38039
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled When attempting to enable MQPRIO while HTB offload is already configured, the driver currently returns `-EINVAL` and triggers a `WARN_ON`, leading to an unnecessary call trace. Update the code to handle this case more gracefully by returning `-EOPNOTSUPP` instead, while also providing a helpful user message.
Modified: 2025-12-18
CVE-2025-38040
In the Linux kernel, the following vulnerability has been resolved:
serial: mctrl_gpio: split disable_ms into sync and no_sync APIs
The following splat has been observed on a SAMA5D27 platform using
atmel_serial:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:738
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0
preempt_count: 1, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [
- https://git.kernel.org/stable/c/1bd2aad57da95f7f2d2bb52f7ad15c0f4993a685
- https://git.kernel.org/stable/c/68435c1fa3db696db4f480385db9e50e26691d0d
- https://git.kernel.org/stable/c/7187ec6b0b9ff22ebac2c3bb4178b7dbbdc0a55a
- https://git.kernel.org/stable/c/c504c11b94d6e4ad818ca5578dffa8ff29ad0f20
- https://git.kernel.org/stable/c/e6a46719a2369eb5186d4f7e6c0478720ca1ec3d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38043
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Set dma_mask for ffa devices Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning: WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124
- https://git.kernel.org/stable/c/2e62c803feec1ef5847d8fa47dd0de039abfa378
- https://git.kernel.org/stable/c/3a3efeef64364c2a028cf0d03d68c831813a97fd
- https://git.kernel.org/stable/c/97bab02f0b64ba6bcdf6a8fae561db07f509aee9
- https://git.kernel.org/stable/c/c6aa1d6bd6ccff4ecdf064d288817657ec8532f0
- https://git.kernel.org/stable/c/cc0aac7ca17e0ea3ca84b552fc79f3e86fd07f53
- https://git.kernel.org/stable/c/e2de76c34a8a925efe80fccae4810427bc144ed0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38044
In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: set device_caps for 417 The video_device for the MPEG encoder did not set device_caps. Add this, otherwise the video device can't be registered (you get a WARN_ON instead). Not seen before since currently 417 support is disabled, but I found this while experimenting with it.
- https://git.kernel.org/stable/c/0884dd3abbe80307a2d4cbdbe5e312be164f8adb
- https://git.kernel.org/stable/c/2ad41beb7df3bd63b209842d16765ec59dafe6e4
- https://git.kernel.org/stable/c/4731d5328f507ae8fd8a57abbca9119ec7a8d665
- https://git.kernel.org/stable/c/5c9eca180a4235abd56cc7f7308ca72128d93dce
- https://git.kernel.org/stable/c/9d1a5be86dbe074bd8dd6bdd63a99d6bb66d5930
- https://git.kernel.org/stable/c/a79efc44b51432490538a55b9753a721f7d3ea42
- https://git.kernel.org/stable/c/c91447e35b9bea60bda4408c48e7891d14351021
- https://git.kernel.org/stable/c/e43fd82bb2110bf9d13d800cdc49cceddfd0ede5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-14
CVE-2025-38045
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix debug actions order The order of actions taken for debug was implemented incorrectly. Now we implemented the dump split and do the FW reset only in the middle of the dump (rather than the FW killing itself on error.) As a result, some of the actions taken when applying the config will now crash the device, so we need to fix the order.
Modified: 2025-11-14
CVE-2025-38047
In the Linux kernel, the following vulnerability has been resolved: x86/fred: Fix system hang during S4 resume with FRED enabled Upon a wakeup from S4, the restore kernel starts and initializes the FRED MSRs as needed from its perspective. It then loads a hibernation image, including the image kernel, and attempts to load image pages directly into their original page frames used before hibernation unless those frames are currently in use. Once all pages are moved to their original locations, it jumps to a "trampoline" page in the image kernel. At this point, the image kernel takes control, but the FRED MSRs still contain values set by the restore kernel, which may differ from those set by the image kernel before hibernation. Therefore, the image kernel must ensure the FRED MSRs have the same values as before hibernation. Since these values depend only on the location of the kernel text and data, they can be recomputed from scratch.
Modified: 2025-12-17
CVE-2025-38048
In the Linux kernel, the following vulnerability has been resolved: virtio_ring: Fix data race by tagging event_triggered as racy for KCSAN syzbot reports a data-race when accessing the event_triggered, here is the simplified stack when the issue occurred: ================================================================== BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayed write to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3800 [inline] read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline] value changed: 0x01 -> 0x00 ================================================================== When the data race occurs, the function virtqueue_enable_cb_delayed() sets event_triggered to false, and virtqueue_disable_cb_split/packed() reads it as false due to the race condition. Since event_triggered is an unreliable hint used for optimization, this should only cause the driver temporarily suggest that the device not send an interrupt notification when the event index is used. Fix this KCSAN reported data-race issue by explicitly tagging the access as data_racy.
- https://git.kernel.org/stable/c/02d2d6caee3abc9335cfca35f8eb4492173ae6f2
- https://git.kernel.org/stable/c/2e2f925fe737576df2373931c95e1a2b66efdfef
- https://git.kernel.org/stable/c/4ed8f0e808b3fcc71c5b8be7902d8738ed595b17
- https://git.kernel.org/stable/c/b49b5132e4c7307599492aee1cdc6d89f7f2a7da
- https://git.kernel.org/stable/c/b6d6419548286b2b9d2b90df824d3cab797f6ae8
- https://git.kernel.org/stable/c/b730cb109633c455ce8a7cd6934986c6a16d88d8
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-12
CVE-2025-38051
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free in cifs_fill_dirent
There is a race condition in the readdir concurrency process, which may
access the rsp buffer after it has been released, triggering the
following KASAN warning.
==================================================================
BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]
Read of size 4 at addr ffff8880099b819c by task a.out/342975
CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1b197931fbc821bc7e9e91bf619400db563e3338
- https://git.kernel.org/stable/c/73cadde98f67f76c5eba00ac0b72c453383cec8b
- https://git.kernel.org/stable/c/9bea368648ac46f8593a780760362e40291d22a9
- https://git.kernel.org/stable/c/9c9aafbacc183598f064902365e107b5e856531f
- https://git.kernel.org/stable/c/a24c2f05ac3c5b0aaa539d9d913826d2643dfd0e
- https://git.kernel.org/stable/c/a7a8fe56e932a36f43e031b398aef92341bf5ea0
- https://git.kernel.org/stable/c/aee067e88d61eb72e966f094e4749c6b14e7008f
- https://git.kernel.org/stable/c/c8623231e0edfcccb7cc6add0288fa0f0594282f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38052
In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt.
- https://git.kernel.org/stable/c/4a0fddc2c0d5c28aec8c262ad4603be0bef1938c
- https://git.kernel.org/stable/c/689a205cd968a1572ab561b0c4c2d50a10e9d3b0
- https://git.kernel.org/stable/c/b19fc1d0be3c3397e5968fe2627f22e7f84673b1
- https://git.kernel.org/stable/c/b8fcae6d2e93c54cacb8f579a77d827c1c643eb5
- https://git.kernel.org/stable/c/d42ed4de6aba232d946d20653a70f79158a6535b
- https://git.kernel.org/stable/c/e279024617134c94fd3e37470156534d5f2b3472
- https://git.kernel.org/stable/c/f5c2c4eaaa5a8e7e0685ec031d480e588e263e59
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-14
CVE-2025-38053
In the Linux kernel, the following vulnerability has been resolved:
idpf: fix null-ptr-deref in idpf_features_check
idpf_features_check is used to validate the TX packet. skb header
length is compared with the hardware supported value received from
the device control plane. The value is stored in the adapter structure
and to access it, vport pointer is used. During reset all the vports
are released and the vport pointer that the netdev private structure
points to is NULL.
To avoid null-ptr-deref, store the max header length value in netdev
private structure. This also helps to cache the value and avoid
accessing adapter pointer in hot path.
BUG: kernel NULL pointer dereference, address: 0000000000000068
...
RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]
Call Trace:
Modified: 2025-11-14
CVE-2025-38054
In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: Limit signal/freq counts in summary output functions The debugfs summary output could access uninitialized elements in the freq_in[] and signal_out[] arrays, causing NULL pointer dereferences and triggering a kernel Oops (page_fault_oops). This patch adds u8 fields (nr_freq_in, nr_signal_out) to track the number of initialized elements, with a maximum of 4 per array. The summary output functions are updated to respect these limits, preventing out-of-bounds access and ensuring safe array handling. Widen the label variables because the change confuses GCC about max length of the strings.
Modified: 2025-11-14
CVE-2025-38055
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq
Currently, using PEBS-via-PT with a sample frequency instead of a sample
period, causes a segfault. For example:
BUG: kernel NULL pointer dereference, address: 0000000000000195
Modified: 2025-11-14
CVE-2025-38056
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: Fix UAF when reloading module hda_generic_machine_select() appends -idisp to the tplg filename by allocating a new string with devm_kasprintf(), then stores the string right back into the global variable snd_soc_acpi_intel_hda_machines. When the module is unloaded, this memory is freed, resulting in a global variable pointing to freed memory. Reloading the module then triggers a use-after-free: BUG: KFENCE: use-after-free read in string+0x48/0xe0 Use-after-free read at 0x00000000967e0109 (in kfence-#99): string+0x48/0xe0 vsnprintf+0x329/0x6e0 devm_kvasprintf+0x54/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): devm_kmalloc+0x52/0x120 devm_kvasprintf+0x66/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): release_nodes+0x43/0xb0 devres_release_all+0x90/0xf0 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x42/0xb0 __do_sys_delete_module+0x1d1/0x310 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it by copying the match array with devm_kmemdup_array() before we modify it.
Modified: 2026-03-17
CVE-2025-38057
In the Linux kernel, the following vulnerability has been resolved: espintcp: fix skb leaks A few error paths are missing a kfree_skb.
- https://git.kernel.org/stable/c/05db2b850a2b8b17f3d1799f563ea1d550e05ed5
- https://git.kernel.org/stable/c/28756f22de48d25256ed89234b66b9037a3f0157
- https://git.kernel.org/stable/c/63c1f19a3be3169e51a5812d22a6d0c879414076
- https://git.kernel.org/stable/c/d8d79cf8c2b7475c22f9874eb844bcc80f858b13
- https://git.kernel.org/stable/c/e2e1f50fc5ebd2826c4e8c558dc65434382d0c0b
- https://git.kernel.org/stable/c/eb058693dfc93ed7a9c365adb899fedd648b9d9f
Modified: 2025-12-18
CVE-2025-38058
In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.
- https://git.kernel.org/stable/c/250cf3693060a5f803c5f1ddc082bb06b16112a9
- https://git.kernel.org/stable/c/628fb00195ce21a90cf9e4e3d105cd9e58f77b40
- https://git.kernel.org/stable/c/8cafd7266fa02e0863bacbf872fe635c0b9725eb
- https://git.kernel.org/stable/c/9b0915e72b3cf52474dcee0b24a2f99d93e604a3
- https://git.kernel.org/stable/c/b55996939c71a3e1a38f3cdc6a8859797efc9083
- https://git.kernel.org/stable/c/b89eb56a378b7b2c1176787fc228d0a57172bdd5
- https://git.kernel.org/stable/c/d8ece4ced3b051e656c77180df2e69e19e24edc1
- https://git.kernel.org/stable/c/f6d45fd92f62845cbd1eb5128fd8f0ed7d0c5a42
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-14
CVE-2025-38059
In the Linux kernel, the following vulnerability has been resolved:
btrfs: avoid NULL pointer dereference if no valid csum tree
[BUG]
When trying read-only scrub on a btrfs with rescue=idatacsums mount
option, it will crash with the following call trace:
BUG: kernel NULL pointer dereference, address: 0000000000000208
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs]
Call Trace:
Modified: 2025-11-14
CVE-2025-38060
In the Linux kernel, the following vulnerability has been resolved: bpf: copy_verifier_state() should copy 'loop_entry' field The bpf_verifier_state.loop_entry state should be copied by copy_verifier_state(). Otherwise, .loop_entry values from unrelated states would poison env->cur_state. Additionally, env->stack should not contain any states with .loop_entry != NULL. The states in env->stack are yet to be verified, while .loop_entry is set for states that reached an equivalent state. This means that env->cur_state->loop_entry should always be NULL after pop_stack(). See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix. This change has some verification performance impact for selftests: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- ------------- arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%) And significant negative impact for sched_ext: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------ bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scx_qmap.bpf.o qmap_dispatch ---truncated---
Modified: 2025-12-18
CVE-2025-38061
In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix access outside of user given buffer in pktgen_thread_write() Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer).
- https://git.kernel.org/stable/c/128cdb617a87767c29be43e4431129942fce41df
- https://git.kernel.org/stable/c/425e64440ad0a2f03bdaf04be0ae53dededbaa77
- https://git.kernel.org/stable/c/5bfa81539e22af4c40ae5d43d7212253462383a6
- https://git.kernel.org/stable/c/6b1d3e9db82d01a88de1795b879df67c2116b4f4
- https://git.kernel.org/stable/c/8fef258b555c75a467a6b4b7e3a3cbc46d5f4102
- https://git.kernel.org/stable/c/a3d89f1cfe1e6d4bb164db2595511fd33db21900
- https://git.kernel.org/stable/c/c81c2ee1c3b050ed5c4e92876590cc7a259183f6
- https://git.kernel.org/stable/c/ef1158a6a650ecee72ab40851b1d52e04d3f9cb5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38062
In the Linux kernel, the following vulnerability has been resolved: genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie The IOMMU translation for MSI message addresses has been a 2-step process, separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address. This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached. Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up. However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()). This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs. Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor. The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex.
- https://git.kernel.org/stable/c/1f7df3a691740a7736bbc99dc4ed536120eb4746
- https://git.kernel.org/stable/c/53f42776e435f63e5f8e61955e4c205dbfeaf524
- https://git.kernel.org/stable/c/856152eb91e67858a09e30a7149a1f29b04b7384
- https://git.kernel.org/stable/c/ba41e4e627db51d914444aee0b93eb67f31fa330
- https://git.kernel.org/stable/c/e4d3763223c7b72ded53425207075e7453b4e3d5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38063
In the Linux kernel, the following vulnerability has been resolved: dm: fix unconditional IO throttle caused by REQ_PREFLUSH When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush() generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, which causes the flush_bio to be throttled by wbt_wait(). An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4 After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"), the metadata submitted by xlog_write_iclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled. Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes wbt_should_throttle() return false to avoid wbt_wait().
- https://git.kernel.org/stable/c/2858cda9a8d95e6deee7e3b0a26adde696a9a4f5
- https://git.kernel.org/stable/c/52aa28f7b1708d76e315d78b5ed397932a1a97c3
- https://git.kernel.org/stable/c/88f7f56d16f568f19e1a695af34a7f4a6ce537a6
- https://git.kernel.org/stable/c/95d08924335f3b6f4ea0b92ebfe4fe0731c502d9
- https://git.kernel.org/stable/c/b55a97d1bd4083729a60d19beffe85d4c96680de
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38065
In the Linux kernel, the following vulnerability has been resolved: orangefs: Do not truncate file size 'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.
- https://git.kernel.org/stable/c/062e8093592fb866b8e016641a8b27feb6ac509d
- https://git.kernel.org/stable/c/121f0335d91e46369bf55b5da4167d82b099a166
- https://git.kernel.org/stable/c/15602508ad2f923e228b9521960b4addcd27d9c4
- https://git.kernel.org/stable/c/2323b806221e6268a4e17711bc72e2fc87c191a3
- https://git.kernel.org/stable/c/341e3a5984cf5761f3dab16029d7e9fb1641d5ff
- https://git.kernel.org/stable/c/5111227d7f1f57f6804666b3abf780a23f44fc1d
- https://git.kernel.org/stable/c/cd918ec24168fe08c6aafc077dd3b6d88364c5cf
- https://git.kernel.org/stable/c/ceaf195ed285b77791e29016ee6344b3ded609b3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38066
In the Linux kernel, the following vulnerability has been resolved:
dm cache: prevent BUG_ON by blocking retries on failed device resumes
A cache device failing to resume due to mapping errors should not be
retried, as the failure leaves a partially initialized policy object.
Repeating the resume operation risks triggering BUG_ON when reloading
cache mappings into the incomplete policy object.
Reproduce steps:
1. create a cache metadata consisting of 512 or more cache blocks,
with some mappings stored in the first array block of the mapping
array. Here we use cache_restore v1.0 to build the metadata.
cat <
- https://git.kernel.org/stable/c/00586b78eeb7c626a14ca13453a1631f88a7cf36
- https://git.kernel.org/stable/c/025c8f477625eb39006ded650e7d027bcfb20e79
- https://git.kernel.org/stable/c/3986ef4a9b6a0d9c28bc325d8713beba5e67586f
- https://git.kernel.org/stable/c/5da692e2262b8f81993baa9592f57d12c2703dea
- https://git.kernel.org/stable/c/c5356a5e80442131e2714d0d26bb110590e4e568
- https://git.kernel.org/stable/c/c614584c2a66b538f469089ac089457a34590c14
- https://git.kernel.org/stable/c/cc80a5cc520939d0a7d071cc4ae4b3c55ef171d0
- https://git.kernel.org/stable/c/f3128e3074e8af565cc6a66fe3384a56df87f803
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38067
In the Linux kernel, the following vulnerability has been resolved: rseq: Fix segfault on registration when rseq_cs is non-zero The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs. The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs. What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation.
- https://git.kernel.org/stable/c/2df285dab00fa03a3ef939b6cb0d0d0aeb0791db
- https://git.kernel.org/stable/c/3e4028ef31b69286c9d4878cee0330235f53f218
- https://git.kernel.org/stable/c/48900d839a3454050fd5822e34be8d54c4ec9b86
- https://git.kernel.org/stable/c/b2b05d0dc2f4f0646922068af435aed5763d16ba
- https://git.kernel.org/stable/c/eaf112069a904b6207b4106ff083e0208232a2eb
- https://git.kernel.org/stable/c/f004f58d18a2d3dc761cf973ad27b4a5997bd876
- https://git.kernel.org/stable/c/fd881d0a085fc54354414aed990ccf05f282ba53
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38068
In the Linux kernel, the following vulnerability has been resolved: crypto: lzo - Fix compression buffer overrun Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller. Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo.
- https://git.kernel.org/stable/c/0acdc4d6e679ba31d01e3e7e2e4124b76d6d8e2a
- https://git.kernel.org/stable/c/167373d77c70c2b558aae3e327b115249bb2652c
- https://git.kernel.org/stable/c/4b173bb2c4665c23f8fcf5241c7b06dfa6b5b111
- https://git.kernel.org/stable/c/7caad075acb634a74911830d6386c50ea12566cd
- https://git.kernel.org/stable/c/a98bd864e16f91c70b2469adf013d713d04d1d13
- https://git.kernel.org/stable/c/cc47f07234f72cbd8e2c973cdbf2a6730660a463
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-14
CVE-2025-38069
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]
Modified: 2025-12-17
CVE-2025-38071
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Check return value from memblock_phys_alloc_range() At least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of contiguous free memory available at this point, the kernel will crash and burn because memblock_phys_alloc_range() returns 0 on failure, which leads memblock_phys_free() to throw the first 4 MiB of physical memory to the wolves. At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine without the weird reserve allocation.
- https://git.kernel.org/stable/c/631ca8909fd5c62b9fda9edda93924311a78a9c4
- https://git.kernel.org/stable/c/8c18c904d301ffeb33b071eadc55cd6131e1e9be
- https://git.kernel.org/stable/c/bffd5f2815c5234d609725cd0dc2f4bc5de2fc67
- https://git.kernel.org/stable/c/c6f2694c580c27dca0cf7546ee9b4bfa6b940e38
- https://git.kernel.org/stable/c/dde4800d2b0f68b945fd81d4fc2d4a10ae25f743
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38072
In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Fix divide error in nd_label_data_init() If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Code and flow: 1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer is set to zero (nvdimm driver): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) A subsequent DIV_ROUND_UP() causes a division by zero: drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Fix this by checking the config size parameter by extending an existing check.
- https://git.kernel.org/stable/c/1d1e1efad1cf049e888bf175a5c6be85d792620c
- https://git.kernel.org/stable/c/2bd4a938d2eda96ab7288b8fa5aae84a1de8c4ca
- https://git.kernel.org/stable/c/396c46d3f59a18ebcc500640e749f16e197d472b
- https://git.kernel.org/stable/c/db1aef51b8e66a77f76b1250b914589c31a0a0ed
- https://git.kernel.org/stable/c/e14347f647ca6d76fe1509b6703e340f2d5e2716
- https://git.kernel.org/stable/c/ea3d95e05e97ea20fd6513f647393add16fce3b2
- https://git.kernel.org/stable/c/ef1d3455bbc1922f94a91ed58d3d7db440652959
- https://git.kernel.org/stable/c/f49c337037df029440a8390380dd35d2cf5924d3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38074
In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: protect vq->log_used with vq->mutex The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue.
- https://git.kernel.org/stable/c/59614c5acf6688f7af3c245d359082c0e9e53117
- https://git.kernel.org/stable/c/80cf68489681c165ded460930e391b1eb37b5f6f
- https://git.kernel.org/stable/c/8312a1ccff1566f375191a89b9ba71b6eb48a8cd
- https://git.kernel.org/stable/c/bd8c9404e44adb9f6219c09b3409a61ab7ce3427
- https://git.kernel.org/stable/c/c0039e3afda29be469d29b3013d7f9bdee136834
- https://git.kernel.org/stable/c/ca85c2d0db5f8309832be45858b960d933c2131c
- https://git.kernel.org/stable/c/f591cf9fce724e5075cc67488c43c6e39e8cbe27
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38075
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix timeout on deleted connection NOPIN response timer may expire on a deleted connection and crash with such logs: Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 That is because nopin response timer may be re-started on nopin timer expiration. Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started.
- https://git.kernel.org/stable/c/019ca2804f3fb49a7f8e56ea6aeaa1ff32724c27
- https://git.kernel.org/stable/c/2c5081439c7ab8da08427befe427f0d732ebc9f9
- https://git.kernel.org/stable/c/3e6429e3707943078240a2c0c0b3ee99ea9b0d9c
- https://git.kernel.org/stable/c/571ce6b6f5cbaf7d24af03cad592fc0e2a54de35
- https://git.kernel.org/stable/c/6815846e0c3a62116a7da9740e3a7c10edc5c7e9
- https://git.kernel.org/stable/c/7f533cc5ee4c4436cee51dc58e81dfd9c3384418
- https://git.kernel.org/stable/c/87389bff743c55b6b85282de91109391f43e0814
- https://git.kernel.org/stable/c/fe8421e853ef289e1324fcda004751c89dd9c18a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38077
In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store() If the 'buf' array received from the user contains an empty string, the 'length' variable will be zero. Accessing the 'buf' array element with index 'length - 1' will result in a buffer overflow. Add a check for an empty string. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/4e89a4077490f52cde652d17e32519b666abf3a6
- https://git.kernel.org/stable/c/60bd13f8c4b3de2c910ae1cdbef85b9bbc9685f5
- https://git.kernel.org/stable/c/8594a123cfa23d708582dc6fb36da34479ef8a5b
- https://git.kernel.org/stable/c/97066373ffd55bd9af0b512ff3dd1f647620a3dc
- https://git.kernel.org/stable/c/f86465626917df3b8bdd2756ec0cc9d179c5af0f
- https://git.kernel.org/stable/c/fb7cde625872709b8cedad9b241e0ec3d82fa7d3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38078
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race of buffer access at PCM OSS layer The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.
- https://git.kernel.org/stable/c/10217da9644ae75cea7330f902c35fc5ba78bbbf
- https://git.kernel.org/stable/c/74d90875f3d43f3eff0e9861c4701418795d3455
- https://git.kernel.org/stable/c/8170d8ec4efd0be352c14cb61f374e30fb0c2a25
- https://git.kernel.org/stable/c/93a81ca0657758b607c3f4ba889ae806be9beb73
- https://git.kernel.org/stable/c/afa56c960fcb4db37f2e3399f28e9402e4e1f470
- https://git.kernel.org/stable/c/bf85e49aaf3a3c5775ea87369ea5f159c2148db4
- https://git.kernel.org/stable/c/c0e05a76fc727929524ef24a19c302e6dd40233f
- https://git.kernel.org/stable/c/f3e14d706ec18faf19f5a6e75060e140fea05d4a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38079
In the Linux kernel, the following vulnerability has been resolved: crypto: algif_hash - fix double free in hash_accept If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error.
- https://git.kernel.org/stable/c/0346f4b742345d1c733c977f3a7aef5a6419a967
- https://git.kernel.org/stable/c/134daaba93193df9e988524b5cd2f52d15eb1993
- https://git.kernel.org/stable/c/2f45a8d64fb4ed4830a4b3273834ecd6ca504896
- https://git.kernel.org/stable/c/5bff312b59b3f2a54ff504e4f4e47272b64f3633
- https://git.kernel.org/stable/c/b2df03ed4052e97126267e8c13ad4204ea6ba9b6
- https://git.kernel.org/stable/c/bf7bba75b91539e93615f560893a599c1e1c98bf
- https://git.kernel.org/stable/c/c3059d58f79fdfb2201249c2741514e34562b547
- https://git.kernel.org/stable/c/f0f3d09f53534ea385d55ced408f2b67059b16e4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-14
CVE-2025-38080
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase block_sequence array size [Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash. [How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.
Modified: 2025-11-14
CVE-2025-38081
In the Linux kernel, the following vulnerability has been resolved: spi-rockchip: Fix register out of bounds access Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense.
Modified: 2025-11-14
CVE-2025-38082
In the Linux kernel, the following vulnerability has been resolved: gpio: virtuser: fix potential out-of-bound write If the caller wrote more characters, count is truncated to the max available space in "simple_write_to_buffer". Check that the input size does not exceed the buffer size. Write a zero termination afterwards.
Modified: 2025-12-17
CVE-2025-38083
In the Linux kernel, the following vulnerability has been resolved: net_sched: prio: fix a race in prio_tune() Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
- https://git.kernel.org/stable/c/20f68e6a9e41693cb0e55e5b9ebbcb40983a4b8f
- https://git.kernel.org/stable/c/3aaa7c01cf19d9b9bb64b88b65c3a6fd05da2eb4
- https://git.kernel.org/stable/c/4483d8b9127591c60c4eb789d6cab953bc4522a9
- https://git.kernel.org/stable/c/46c15c9d0f65c9ba857d63f53264f4b17e8a715f
- https://git.kernel.org/stable/c/53d11560e957d53ee87a0653d258038ce12361b7
- https://git.kernel.org/stable/c/93f9eeb678d4c9c1abf720b3615fa8299a490845
- https://git.kernel.org/stable/c/d35acc1be3480505b5931f17e4ea9b7617fea4d3
- https://git.kernel.org/stable/c/e3f6745006dc9423d2b065b90f191cfa11b1b584
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38084
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2]
- https://git.kernel.org/stable/c/081056dc00a27bccb55ccc3c6f230a3d5fd3f7e0
- https://git.kernel.org/stable/c/2511ac64bc1617ca716d3ba8464e481a647c1902
- https://git.kernel.org/stable/c/366298f2b04d2bf1f2f2b7078405bdf9df9bd5d0
- https://git.kernel.org/stable/c/8a21d5584826f4880f45bbf8f72375f4e6c0ff2a
- https://git.kernel.org/stable/c/9cf5b2a3b72c23fb7b84736d5d19ee6ea718762b
- https://git.kernel.org/stable/c/af6cfcd0efb7f051af221c418ec8b37a10211947
- https://git.kernel.org/stable/c/e8847d18cd9fff1edbb45e963d9141273c3b539c
- https://project-zero.issues.chromium.org/issues/420715744
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38085
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.
- https://git.kernel.org/stable/c/034a52b5ef57c9c8225d94e9067f3390bb33922f
- https://git.kernel.org/stable/c/1013af4f585fccc4d3e5c5824d174de2257f7d6d
- https://git.kernel.org/stable/c/952596b08c74e8fe9e2883d1dc8a8f54a37384ec
- https://git.kernel.org/stable/c/a3d864c901a300c295692d129159fc3001a56185
- https://git.kernel.org/stable/c/a6bfeb97941a9187833b526bc6cc4ff5706d0ce9
- https://git.kernel.org/stable/c/b7754d3aa7bf9f62218d096c0c8f6c13698fac8b
- https://git.kernel.org/stable/c/fe684290418ef9ef76630072086ee530b92f02b8
- https://project-zero.issues.chromium.org/issues/420715744
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38086
In the Linux kernel, the following vulnerability has been resolved: net: ch9200: fix uninitialised access during mii_nway_restart In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff". To fix this we should check the return value of control_read() and return early on error.
- https://git.kernel.org/stable/c/119766de4930ff40db9f36b960cb53b0c400e81b
- https://git.kernel.org/stable/c/33163c68d2e3061fa3935b5f0a1867958b1cdbd2
- https://git.kernel.org/stable/c/4da7fcc098218ff92b2e83a43f545c02f714cedd
- https://git.kernel.org/stable/c/6bd2569d0b2f918e9581f744df0263caf73ee76c
- https://git.kernel.org/stable/c/9a350f30d65197354706b7759b5c89d6c267b1a9
- https://git.kernel.org/stable/c/9ad0452c0277b816a435433cca601304cfac7c21
- https://git.kernel.org/stable/c/9da3e442714f7f4393ff01c265c4959c03e88c2f
- https://git.kernel.org/stable/c/cdaa6d1cb2ff1219c6c822b27655dd170ffb0f72
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38087
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.
Modified: 2025-12-17
CVE-2025-38088
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size.
- https://git.kernel.org/stable/c/620b77b23c41a6546e5548ffe2ea3ad71880dde4
- https://git.kernel.org/stable/c/81260c41b518b6f32c701425f1427562fa92f293
- https://git.kernel.org/stable/c/8635e325b85dfb9ddebdfaa6b5605d40d16cd147
- https://git.kernel.org/stable/c/9c340b56d60545e4a159e41523dd8b23f81d3261
- https://git.kernel.org/stable/c/bbd5a9ddb0f9750783a48a871c9e12c0b68c5f39
- https://git.kernel.org/stable/c/cd097df4596f3a1e9d75eb8520162de1eb8485b2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38089
In the Linux kernel, the following vulnerability has been resolved: sunrpc: handle SVC_GARBAGE during svc auth processing as auth error tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble. The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR. Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash.
- https://git.kernel.org/stable/c/353e75b55e583635bf71cde6abcec274dba05edd
- https://git.kernel.org/stable/c/599c489eea793821232a2f69a00fa57d82b0ac98
- https://git.kernel.org/stable/c/94d10a4dba0bc482f2b01e39f06d5513d0f75742
- https://git.kernel.org/stable/c/c90459cd58bb421d275337093d8e901e0ba748dd
- https://github.com/keymaker-arch/NFSundown
- https://www.openwall.com/lists/oss-security/2025/07/02/2
- http://www.openwall.com/lists/oss-security/2025/07/02/2
Modified: 2025-12-17
CVE-2025-38090
In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace.
- https://git.kernel.org/stable/c/1921781ec4a8824bd0c520bf9363e28a880d14ec
- https://git.kernel.org/stable/c/1cce6ac47f4a2ac1766b8a188dc8c8f6d8df2a53
- https://git.kernel.org/stable/c/50695153d7ddde3b1696dbf0085be0033bf3ddb3
- https://git.kernel.org/stable/c/58f664614f8c3d6142ab81ae551e466dc6e092e8
- https://git.kernel.org/stable/c/6d5c6711a55c35ce09b90705546050408d9d4b61
- https://git.kernel.org/stable/c/a8b5ea2e302aa5cd00fc7addd8df53c9bde7b5f6
- https://git.kernel.org/stable/c/c03ddc183249f03fc7e057e02cae6f89144d0123
- https://git.kernel.org/stable/c/ecf5ee280b702270afb02f61b299d3dfe3ec7730
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38091
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: check stream id dml21 wrapper to get plane_id
[Why & How]
Fix a false positive warning which occurs due to lack of correct checks
when querying plane_id in DML21. This fixes the warning when performing a
mode1 reset (cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover):
[ 35.751250] WARNING: CPU: 11 PID: 326 at /tmp/amd.PHpyAl7v/amd/amdgpu/../display/dc/dml2/dml2_dc_resource_mgmt.c:91 dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
[ 35.751434] Modules linked in: amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_ttm_helper ttm drm_display_helper cec rc_core i2c_algo_bit rfcomm qrtr cmac algif_hash algif_skcipher af_alg bnep amd_atl intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi snd_hda_intel edac_mce_amd snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm_amd snd_hda_core snd_hwdep snd_pcm kvm snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul polyval_clmulni polyval_generic btusb ghash_clmulni_intel sha256_ssse3 btrtl sha1_ssse3 snd_seq btintel aesni_intel btbcm btmtk snd_seq_device crypto_simd sunrpc cryptd bluetooth snd_timer ccp binfmt_misc rapl snd i2c_piix4 wmi_bmof gigabyte_wmi k10temp i2c_smbus soundcore gpio_amdpt mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 hid_generic usbhid hid crc32_pclmul igc ahci xhci_pci libahci xhci_pci_renesas video wmi
[ 35.751501] CPU: 11 UID: 0 PID: 326 Comm: kworker/u64:9 Tainted: G OE 6.11.0-21-generic #21~24.04.1-Ubuntu
[ 35.751504] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[ 35.751505] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F30 05/22/2024
[ 35.751506] Workqueue: amdgpu-reset-dev amdgpu_debugfs_reset_work [amdgpu]
[ 35.751638] RIP: 0010:dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu]
[ 35.751794] Code: 6d 0c 00 00 8b 84 24 88 00 00 00 41 3b 44 9c 20 0f 84 fc 07 00 00 48 83 c3 01 48 83 fb 06 75 b3 4c 8b 64 24 68 4c 8b 6c 24 40 <0f> 0b b8 06 00 00 00 49 8b 94 24 a0 49 00 00 89 c3 83 f8 07 0f 87
[ 35.751796] RSP: 0018:ffffbfa3805d7680 EFLAGS: 00010246
[ 35.751798] RAX: 0000000000010000 RBX: 0000000000000006 RCX: 0000000000000000
[ 35.751799] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000
[ 35.751800] RBP: ffffbfa3805d78f0 R08: 0000000000000000 R09: 0000000000000000
[ 35.751801] R10: 0000000000000000 R11: 0000000000000000 R12: ffffbfa383249000
[ 35.751802] R13: ffffa0e68f280000 R14: ffffbfa383249658 R15: 0000000000000000
[ 35.751803] FS: 0000000000000000(0000) GS:ffffa0edbe580000(0000) knlGS:0000000000000000
[ 35.751804] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.751805] CR2: 00005d847ef96c58 CR3: 000000041de3e000 CR4: 0000000000f50ef0
[ 35.751806] PKRU: 55555554
[ 35.751807] Call Trace:
[ 35.751810]
Modified: 2025-11-20
CVE-2025-38092
In the Linux kernel, the following vulnerability has been resolved: ksmbd: use list_first_entry_or_null for opinfo_get_list() The list_first_entry() macro never returns NULL. If the list is empty then it returns an invalid pointer. Use list_first_entry_or_null() to check if the list is empty.
Modified: 2025-11-20
CVE-2025-38093
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: x1e80100: Add GPU cooling Unlike the CPU, the GPU does not throttle its speed automatically when it reaches high temperatures. With certain high GPU loads it is possible to reach the critical hardware shutdown temperature of 120°C, endangering the hardware and making it impossible to run certain applications. Set up GPU cooling similar to the ACPI tables, by throttling the GPU speed when reaching 95°C and polling every 200ms.
Modified: 2025-12-16
CVE-2025-38094
In the Linux kernel, the following vulnerability has been resolved: net: cadence: macb: Fix a possible deadlock in macb_halt_tx. There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.
- https://git.kernel.org/stable/c/0772a608d799ac0d127c0a36047a2725777aba9d
- https://git.kernel.org/stable/c/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4
- https://git.kernel.org/stable/c/3e64d35475aa21d13dab71da51de51923c1a3a48
- https://git.kernel.org/stable/c/64675a9c00443b2e8af42af08c38fc1b78b68ba2
- https://git.kernel.org/stable/c/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37
- https://git.kernel.org/stable/c/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7
- https://git.kernel.org/stable/c/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-38095
In the Linux kernel, the following vulnerability has been resolved: dma-buf: insert memory barrier before updating num_fences smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered.
- https://git.kernel.org/stable/c/08680c4dadc6e736c75bc2409d833f03f9003c51
- https://git.kernel.org/stable/c/3becc659f9cb76b481ad1fb71f54d5c8d6332d3f
- https://git.kernel.org/stable/c/72c7d62583ebce7baeb61acce6057c361f73be4a
- https://git.kernel.org/stable/c/90eb79c4ed98a4e24a62ccf61c199ab0f680fa8f
- https://git.kernel.org/stable/c/c9d2b9a80d06a58f37e0dc8c827075639b443927
- https://git.kernel.org/stable/c/d0b7f11dd68b593bd970e5735be00e8d89bace30
- https://git.kernel.org/stable/c/fe1bebd0edb22e3536cbc920ec713331d1367ad4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-20
CVE-2025-38096
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: don't warn when if there is a FW error iwl_trans_reclaim is warning if it is called when the FW is not alive. But if it is called when there is a pending restart, i.e. after a FW error, there is no need to warn, instead - return silently.
Modified: 2025-12-16
CVE-2025-38097
In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.
- https://git.kernel.org/stable/c/028363685bd0b7a19b4a820f82dd905b1dc83999
- https://git.kernel.org/stable/c/74fd327767fb784c5875cf7c4ba1217f26020943
- https://git.kernel.org/stable/c/9cbca30102028f9ad3d2098f935c4368f581fd07
- https://git.kernel.org/stable/c/b58a295d10065960bcb9d60cb8ca6ead9837cd27
- https://git.kernel.org/stable/c/e4cde54b46a87231c77256a633be1bef62687d69
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38098
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Don't treat wb connector as physical in create_validate_stream_for_sink Don't try to operate on a drm_wb_connector as an amdgpu_dm_connector. While dereferencing aconnector->base will "work" it's wrong and might lead to unknown bad things. Just... don't.
Modified: 2025-11-20
CVE-2025-38099
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken A SCO connection without the proper voice_setting can cause the controller to lock up.
Modified: 2025-12-16
CVE-2025-38100
In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.
- https://git.kernel.org/stable/c/2cfcbe1554c119402e7382de974c26b0549899fe
- https://git.kernel.org/stable/c/2dace5e016c991424a3dc6e83b1ae5dca8992d08
- https://git.kernel.org/stable/c/73cfcc8445585b8af7e18be3c9246b851fdf336c
- https://git.kernel.org/stable/c/8b68e978718f14fdcb080c2a7791c52a0d09bc6d
- https://git.kernel.org/stable/c/aa5ce1485562f20235b4c759eee5ab0c41d2c220
- https://git.kernel.org/stable/c/b3b3b6366dc8eb5b22edba9adc4bff3cdacfd64c
- https://git.kernel.org/stable/c/d64b7b05a827f98d068f412969eef65489b0cf03
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38101
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set() Enlarge the critical section in ring_buffer_subbuf_order_set() to ensure that error handling takes place with per-buffer mutex held, thus preventing list corruption and other concurrency-related issues.
Modified: 2025-12-16
CVE-2025-38102
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio
as follow:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130
Modules linked in:
CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)
RIP: 0010:try_grab_folio+0x106/0x130
Call Trace:
- https://git.kernel.org/stable/c/00ddc7dad55b7bbb78df80d6e174d0c4764dea0c
- https://git.kernel.org/stable/c/1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4
- https://git.kernel.org/stable/c/468aec888f838ce5174b96e0cb4396790d6f60ca
- https://git.kernel.org/stable/c/58a90db70aa6616411e5f69d1982d9b1dd97d774
- https://git.kernel.org/stable/c/6e3af836805ed1d7a699f76ec798626198917aa4
- https://git.kernel.org/stable/c/74095bbbb19ca74a0368d857603a2438c88ca86c
- https://git.kernel.org/stable/c/75b5313c80c39a26d27cbb602f968a05576c36f9
- https://git.kernel.org/stable/c/b4209e4b778e4e57d0636e1c9fc07a924dbc6043
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38103
In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors.
- https://git.kernel.org/stable/c/1df80d748f984290c895e843401824215dcfbfb0
- https://git.kernel.org/stable/c/41827a2dbdd7880df9881506dee13bc88d4230bb
- https://git.kernel.org/stable/c/485e1b741eb838cbe1d6b0e81e5ab62ae6c095cf
- https://git.kernel.org/stable/c/4fa7831cf0ac71a0a345369d1a6084f2b096e55e
- https://git.kernel.org/stable/c/74388368927e9c52a69524af5bbd6c55eb4690de
- https://git.kernel.org/stable/c/7a6d6b68db128da2078ccd9a751dfa3f75c9cf5b
- https://git.kernel.org/stable/c/a8f842534807985d3a676006d140541b87044345
- https://git.kernel.org/stable/c/fe7f7ac8e0c708446ff017453add769ffc15deed
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38104
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV
RLCG Register Access is a way for virtual functions to safely access GPU
registers in a virtualized environment., including TLB flushes and
register reads. When multiple threads or VFs try to access the same
registers simultaneously, it can lead to race conditions. By using the
RLCG interface, the driver can serialize access to the registers. This
means that only one thread can access the registers at a time,
preventing conflicts and ensuring that operations are performed
correctly. Additionally, when a low-priority task holds a mutex that a
high-priority task needs, ie., If a thread holding a spinlock tries to
acquire a mutex, it can lead to priority inversion. register access in
amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical.
The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being
called, which attempts to acquire the mutex. This function is invoked
from amdgpu_sriov_wreg, which in turn is called from
gmc_v11_0_flush_gpu_tlb.
The [ BUG: Invalid wait context ] indicates that a thread is trying to
acquire a mutex while it is in a context that does not allow it to sleep
(like holding a spinlock).
Fixes the below:
[ 253.013423] =============================
[ 253.013434] [ BUG: Invalid wait context ]
[ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE
[ 253.013464] -----------------------------
[ 253.013475] kworker/0:1/10 is trying to lock:
[ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]
[ 253.013815] other info that might help us debug this:
[ 253.013827] context-{4:4}
[ 253.013835] 3 locks held by kworker/0:1/10:
[ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680
[ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680
[ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu]
[ 253.014154] stack backtrace:
[ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14
[ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024
[ 253.014224] Workqueue: events work_for_cpu_fn
[ 253.014241] Call Trace:
[ 253.014250]
- https://git.kernel.org/stable/c/07ed75bfa7ede8bfcfa303fd6efc85db1c8684c7
- https://git.kernel.org/stable/c/1c0378830e42c98acd69e0289882c8637d92f285
- https://git.kernel.org/stable/c/5c1741a0c176ae11675a64cb7f2dd21d72db6b91
- https://git.kernel.org/stable/c/d1bda2ab0cf956a16dd369a473a6c43dfbed5855
- https://git.kernel.org/stable/c/dc0297f3198bd60108ccbd167ee5d9fa4af31ed0
- https://git.kernel.org/stable/c/dd450b513718dfeb4c637c9335d51a55ebcd4320
Modified: 2025-11-20
CVE-2025-38106
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo()
syzbot reports:
BUG: KASAN: slab-use-after-free in getrusage+0x1109/0x1a60
Read of size 8 at addr ffff88810de2d2c8 by task a.out/304
CPU: 0 UID: 0 PID: 304 Comm: a.out Not tainted 6.16.0-rc1 #1 PREEMPT(voluntary)
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
Modified: 2025-12-16
CVE-2025-38107
In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: fix a race in ets_qdisc_change() Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
- https://git.kernel.org/stable/c/0383b25488a545be168744336847549d4a2d3d6c
- https://git.kernel.org/stable/c/073f64c03516bcfaf790f8edc772e0cfb8a84ec3
- https://git.kernel.org/stable/c/0b479d0aa488cb478eb2e1d8868be946ac8afb4f
- https://git.kernel.org/stable/c/347867cb424edae5fec1622712c8dd0a2c42918f
- https://git.kernel.org/stable/c/d92adacdd8c2960be856e0b82acc5b7c5395fddb
- https://git.kernel.org/stable/c/eb7b74e9754e1ba2088f914ad1f57a778b11894b
- https://git.kernel.org/stable/c/fed94bd51d62d2e0e006aa61480e94e5cd0582b0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38108
In the Linux kernel, the following vulnerability has been resolved: net_sched: red: fix a race in __red_change() Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
- https://git.kernel.org/stable/c/110a47efcf23438ff8d31dbd9c854fae2a48bf98
- https://git.kernel.org/stable/c/2790c4ec481be45a80948d059cd7c9a06bc37493
- https://git.kernel.org/stable/c/2a71924ca4af59ffc00f0444732b6cd54b153d0e
- https://git.kernel.org/stable/c/444ad445df5496a785705019268a8a84b84484bb
- https://git.kernel.org/stable/c/4b755305b2b0618e857fdadb499365b5f2e478d1
- https://git.kernel.org/stable/c/85a3e0ede38450ea3053b8c45d28cf55208409b8
- https://git.kernel.org/stable/c/a1bf6a4e9264a685b0e642994031f9c5aad72414
- https://git.kernel.org/stable/c/f569984417a4e12c67366e69bdcb752970de921d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38109
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix ECVF vports unload on shutdown flow Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed. ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports. kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220 ---------------- [] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]---
Modified: 2025-11-20
CVE-2025-38110
In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds clause 45 read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.
Modified: 2025-12-16
CVE-2025-38111
In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.
- https://git.kernel.org/stable/c/014ad9210373d2104f6ef10e6bb999a7a0a4c50e
- https://git.kernel.org/stable/c/049af7ac45a6b407748ee0995278fd861e36df8f
- https://git.kernel.org/stable/c/0e629694126ca388916f059453a1c36adde219c4
- https://git.kernel.org/stable/c/19c5875e26c4ed5686d82a7d8f7051385461b9eb
- https://git.kernel.org/stable/c/73d478234a619f3476028cb02dee699c30ae8262
- https://git.kernel.org/stable/c/b02d9d2732483e670bc34cb233d28e1d43b15da4
- https://git.kernel.org/stable/c/bab6bca0834cbb5be2a7cfe59ec6ad016ec72608
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38112
In the Linux kernel, the following vulnerability has been resolved: net: Fix TOCTOU issue in sk_is_readable() sk->sk_prot->sock_is_readable is a valid function pointer when sk resides in a sockmap. After the last sk_psock_put() (which usually happens when socket is removed from sockmap), sk->sk_prot gets restored and sk->sk_prot->sock_is_readable becomes NULL. This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded after the initial check. Which in turn may lead to a null pointer dereference. Ensure the function pointer does not turn NULL after the check.
- https://git.kernel.org/stable/c/1b367ba2f94251822577daed031d6b9a9e11ba91
- https://git.kernel.org/stable/c/1e0de7582ceccbdbb227d4e0ddf65732f92526da
- https://git.kernel.org/stable/c/2660a544fdc0940bba15f70508a46cf9a6491230
- https://git.kernel.org/stable/c/6fa68d7eab34d448a61aa24ea31e68b3231ed20d
- https://git.kernel.org/stable/c/8926a7ef1977a832dd6bf702f1a99303dbf15b15
- https://git.kernel.org/stable/c/c2b26638476baee154920bb587fc94ff1bf04336
- https://git.kernel.org/stable/c/ff55c85a923e043d59d26b20a673a1b4a219c310
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38113
In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Fix NULL pointer dereference when nosmp is used
With nosmp in cmdline, other CPUs are not brought up, leaving
their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu()
dereferences these NULL pointers, causing panic.
Panic backtrace:
[ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8
...
[ 0.403255] [
- https://git.kernel.org/stable/c/15eece6c5b05e5f9db0711978c3e3b7f1a2cfe12
- https://git.kernel.org/stable/c/1a677d0ceb4a5d62117b711a8b2e0aee80d33015
- https://git.kernel.org/stable/c/32a48db4cf28ea087214c261da8476db218d08bd
- https://git.kernel.org/stable/c/356d09c7f5bf525086002a34f8bae40b134d1611
- https://git.kernel.org/stable/c/c6dad167aade4bf0bef9130f2f149f4249fc4ad0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38115
In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: fix a potential crash on gso_skb handling SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 &
- https://git.kernel.org/stable/c/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72
- https://git.kernel.org/stable/c/82448d4dcd8406dec688632a405fdcf7f170ec69
- https://git.kernel.org/stable/c/82ffbe7776d0ac084031f114167712269bf3d832
- https://git.kernel.org/stable/c/9c19498bdd7cb9d854bd3c54260f71cf7408495e
- https://git.kernel.org/stable/c/b44f791f27b14c9eb6b907fbe51f2ba8bec32085
- https://git.kernel.org/stable/c/b4e9bab6011b9559b7c157b16b91ae46d4d8c533
- https://git.kernel.org/stable/c/c337efb20d6d9f9bbb4746f6b119917af5c886dc
- https://git.kernel.org/stable/c/d1bc80da75c789f2f6830df89d91fb2f7a509943
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38117
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Protect mgmt_pending list with its own lock This uses a mutex to protect from concurrent access of mgmt_pending list which can cause crashes like: ================================================================== BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318 CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline ---truncated---
Modified: 2025-12-17
CVE-2025-38118
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete
This reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to
avoid crashes like bellow:
==================================================================
BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406
Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341
CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
- https://git.kernel.org/stable/c/32aa2fbe319f33b0318ec6f4fceb63879771a286
- https://git.kernel.org/stable/c/3c9aba9cbdf163e2654be9f82d43ff8a04273962
- https://git.kernel.org/stable/c/9df3e5e7f7e4653fd9802878cedc36defc5ef42d
- https://git.kernel.org/stable/c/9f66b6531c2b4e996bb61720ee94adb4b2e8d1be
- https://git.kernel.org/stable/c/e6ed54e86aae9e4f7286ce8d5c73780f91b48d1c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-19
CVE-2025-38119
In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before. Backtrace: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 [ bvanassche: rewrote patch description ]
- https://git.kernel.org/stable/c/21f071261f946c5ca1adf378f818082a112b34d2
- https://git.kernel.org/stable/c/3464a707d137efc8aea1d4ae234d26a28d82b78c
- https://git.kernel.org/stable/c/8a3514d348de87a9d5e2ac00fbac4faae0b97996
- https://git.kernel.org/stable/c/bb37f795d01961286b8f768a6d7152f32b589067
- https://git.kernel.org/stable/c/ded80255c59a57cd3270d98461f6508730f9767c
- https://git.kernel.org/stable/c/f210ea4e7a790c9f5e613e5302175abd539fe9d5
- https://git.kernel.org/stable/c/f592eb12b43f21dbc972cbe583a12d256901e569
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38120
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo_avx2: fix initial map fill If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map. The early fix was incomplete and did only fix up the generic C implementation. A followup patch adds a test case to nft_concat_range.sh.
- https://git.kernel.org/stable/c/251496ce1728c9fd47bd2b20a7b21b20b9a020ca
- https://git.kernel.org/stable/c/39bab2d3517b5b50c609b4f8c66129bf619fffa0
- https://git.kernel.org/stable/c/8068e1e42b46518ce680dc6470bcd710efc3fa0a
- https://git.kernel.org/stable/c/8164d0efaf370c425dc69a1e8216940d09e7de0c
- https://git.kernel.org/stable/c/90bc7f5a244aadee4292b28098b7c98aadd4b3aa
- https://git.kernel.org/stable/c/b5ad58285f9217d68cd5ea2ad86ce254a3fe7c4d
- https://git.kernel.org/stable/c/ea77c397bff8b6d59f6d83dae1425b08f465e8b5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38122
In the Linux kernel, the following vulnerability has been resolved: gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo() did not check for this case before dereferencing the returned pointer. Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails. This improves robustness in low-memory scenarios.
- https://git.kernel.org/stable/c/12c331b29c7397ac3b03584e12902990693bc248
- https://git.kernel.org/stable/c/2e5ead9e4e91fbe7799bd38afd8904543be1cb51
- https://git.kernel.org/stable/c/7f6265fce3bd424ded666481b37f106d7915fb6b
- https://git.kernel.org/stable/c/a0319c9b1648a67511e947a596ca86888451c0a7
- https://git.kernel.org/stable/c/ae98a1787fdcb0096d122bc80d93c3c7d812c04b
- https://git.kernel.org/stable/c/c741a7ef68023ac800054e2131c3e22e647fd7e3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38123
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: t7xx: Fix napi rx poll issue
When driver handles the napi rx polling requests, the netdev might
have been released by the dellink logic triggered by the disconnect
operation on user plane. However, in the logic of processing skb in
polling, an invalid netdev is still being used, which causes a panic.
BUG: kernel NULL pointer dereference, address: 00000000000000f1
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:dev_gro_receive+0x3a/0x620
[...]
Call Trace:
Modified: 2025-12-17
CVE-2025-38124
In the Linux kernel, the following vulnerability has been resolved: net: fix udp gso skb_segment after pull from frag_list Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from frag_list") detected invalid geometry in frag_list skbs and redirects them from skb_segment_list to more robust skb_segment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skb_segment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust. If only part of the fraglist payload is pulled into head_skb, it will always cause exception when splitting skbs by skb_segment. For detailed call stack information, see below. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify fraglist skbs, breaking these invariants. In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes. The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because payload was pulled into head_skb, it needs to be linearized before pass to regular skb_segment. skb_segment+0xcd0/0xd14 __udp_gso_segment+0x334/0x5f4 udp4_ufo_fragment+0x118/0x15c inet_gso_segment+0x164/0x338 skb_mac_gso_segment+0xc4/0x13c __skb_gso_segment+0xc4/0x124 validate_xmit_skb+0x9c/0x2c0 validate_xmit_skb_list+0x4c/0x80 sch_direct_xmit+0x70/0x404 __dev_queue_xmit+0x64c/0xe5c neigh_resolve_output+0x178/0x1c4 ip_finish_output2+0x37c/0x47c __ip_finish_output+0x194/0x240 ip_finish_output+0x20/0xf4 ip_output+0x100/0x1a0 NF_HOOK+0xc4/0x16c ip_forward+0x314/0x32c ip_rcv+0x90/0x118 __netif_receive_skb+0x74/0x124 process_backlog+0xe8/0x1a4 __napi_poll+0x5c/0x1f8 net_rx_action+0x154/0x314 handle_softirqs+0x154/0x4b8 [118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000 [118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14 [118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14 [118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770
- https://git.kernel.org/stable/c/0e65f38bd1aa14ea86e221b7bb814d38278d86c3
- https://git.kernel.org/stable/c/3382a1ed7f778db841063f5d7e317ac55f9e7f72
- https://git.kernel.org/stable/c/4399f59a9467a324ed46657555f0e1f209a14acb
- https://git.kernel.org/stable/c/85eef1748c024da1a191aed56b30a3a65958c50c
- https://git.kernel.org/stable/c/a04302867094bdc6efac1b598370fc47cf3f2388
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38125
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring EST If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0. Prevent this division by 0 by adding the corresponding check and error code.
- https://git.kernel.org/stable/c/451ee661d0f6272017fa012f99617101aa8ddf2c
- https://git.kernel.org/stable/c/b15c9a21950e1af6d440ce5a8edfa8a94b9acb9b
- https://git.kernel.org/stable/c/b92ec4a848728460f181def33735605f154d438f
- https://git.kernel.org/stable/c/cbefe2ffa7784525ec5d008ba87c7add19ec631a
- https://git.kernel.org/stable/c/d5e3bfdba0dc419499b801937128957f77503761
- https://git.kernel.org/stable/c/d6b0f7ed3e9b6c5e2e3a006c8f72c95aa4ac4b74
Modified: 2025-12-17
CVE-2025-38126
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping The stmmac platform drivers that do not open-code the clk_ptp_rate value after having retrieved the default one from the device-tree can end up with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8) Prevent this division by 0 by adding an explicit check and error log about the actual issue. While at it, remove the same check from stmmac_ptp_register, which then becomes duplicate
- https://git.kernel.org/stable/c/030ce919e114a111e83b7976ecb3597cefd33f26
- https://git.kernel.org/stable/c/32af9c289234990752281c805500dfe03c5b2b8f
- https://git.kernel.org/stable/c/379cd990dfe752b38fcf46034698a9a150626c7a
- https://git.kernel.org/stable/c/b263088ee8ab14563817a8be3519af8e25225793
- https://git.kernel.org/stable/c/bb033c6781ce1b0264c3993b767b4aa9021959c2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38127
In the Linux kernel, the following vulnerability has been resolved:
ice: fix Tx scheduler error handling in XDP callback
When the XDP program is loaded, the XDP callback adds new Tx queues.
This means that the callback must update the Tx scheduler with the new
queue number. In the event of a Tx scheduler failure, the XDP callback
should also fail and roll back any changes previously made for XDP
preparation.
The previous implementation had a bug that not all changes made by the
XDP callback were rolled back. This caused the crash with the following
call trace:
[ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5
[ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI
[ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)
[ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022
[ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice]
[...]
[ +0.002715] Call Trace:
[ +0.002452]
Modified: 2026-01-19
CVE-2025-38129
In the Linux kernel, the following vulnerability has been resolved:
page_pool: Fix use-after-free in page_pool_recycle_in_ring
syzbot reported a uaf in page_pool_recycle_in_ring:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862
Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943
CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
- https://git.kernel.org/stable/c/1a8c0b61d4cb55c5440583ec9e7f86a730369e32
- https://git.kernel.org/stable/c/271683bb2cf32e5126c592b5d5e6a756fa374fd9
- https://git.kernel.org/stable/c/4914c0a166540e534a0c1d43affd329d95fb56fd
- https://git.kernel.org/stable/c/4ab8c0f8905c9c4d05e7f437e65a9a365573ff02
- https://git.kernel.org/stable/c/d69f28ef7cdafdcf37ee310f38b1399e7d05f9a8
- https://git.kernel.org/stable/c/e869a85acc2e60dc554579b910826a4919d8cd98
Modified: 2025-12-17
CVE-2025-38131
In the Linux kernel, the following vulnerability has been resolved: coresight: prevent deactivate active config while enabling the config While enable active config via cscfg_csdev_enable_active_config(), active config could be deactivated via configfs' sysfs interface. This could make UAF issue in below scenario: CPU0 CPU1 (sysfs enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() unload module // access to config_desc which freed // while unloading module. cscfg_csdev_enable_config To address this, use cscfg_config_desc's active_cnt as a reference count which will be holded when - activate the config. - enable the activated config. and put the module reference when config_active_cnt == 0.
- https://git.kernel.org/stable/c/31028812724cef7bd57a51525ce58a32a6d73b22
- https://git.kernel.org/stable/c/408c97c4a5e0b634dcd15bf8b8808b382e888164
- https://git.kernel.org/stable/c/b3b4efa2e623aecaebd7c9b9e4171f5c659e9724
- https://git.kernel.org/stable/c/dfe8224c9c7a43d356eb9f74b06868aa05f90223
- https://git.kernel.org/stable/c/ed42ee1ed05ff2f4c36938379057413a40c56680
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38134
In the Linux kernel, the following vulnerability has been resolved: usb: acpi: Prevent null pointer dereference in usb_acpi_add_usb4_devlink() As demonstrated by the fix for update_port_device_state, commit 12783c0b9e2c ("usb: core: Prevent null pointer dereference in update_port_device_state"), usb_hub_to_struct_hub() can return NULL in certain scenarios, such as during hub driver unbind or teardown race conditions, even if the underlying usb_device structure exists. Plus, all other places that call usb_hub_to_struct_hub() in the same file do check for NULL return values. If usb_hub_to_struct_hub() returns NULL, the subsequent access to hub->ports[udev->portnum - 1] will cause a null pointer dereference.
Modified: 2025-12-17
CVE-2025-38135
In the Linux kernel, the following vulnerability has been resolved: serial: Fix potential null-ptr-deref in mlb_usio_probe() devm_ioremap() can return NULL on error. Currently, mlb_usio_probe() does not check for this case, which could result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue.
- https://git.kernel.org/stable/c/19fd9f5a69363d33079097d866eb6082d61bf31d
- https://git.kernel.org/stable/c/548b0e81b9a0902a8bc8259430ed965663baadfc
- https://git.kernel.org/stable/c/81159a6b064142b993f2f39828b77e199c77872a
- https://git.kernel.org/stable/c/86bcae88c9209e334b2f8c252f4cc66beb261886
- https://git.kernel.org/stable/c/a05ebe384c7ca75476453f3070c67d9cf1d1a89f
- https://git.kernel.org/stable/c/a6c7c365734cd0fa1c5aa225a6294fdf80cad2ea
- https://git.kernel.org/stable/c/c23d87b43f7dba5eb12820f6cf21a1cd4f63eb3d
- https://git.kernel.org/stable/c/e1b144aebe6fb898d96ced8c990d7aa38fda4a7a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38136
In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Reorder clock handling and power management in probe Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access before enabling clocks Since `iowrite16()` is performed without ensuring the required clocks are enabled, this can lead to access errors. To fix this, enable PM runtime early in the probe function and ensure clocks are acquired before register access, preventing crashes like the following on RZ/V2H: [13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP [13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750 [13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Call trace: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/095cc0b5888acc228f12344e85b17539b9ce9367
- https://git.kernel.org/stable/c/0a1e16a6cbf4452b46f20b862d6141a1e90844ee
- https://git.kernel.org/stable/c/155453ada562c450a4ff5fcf4852b9fa5b6b793a
- https://git.kernel.org/stable/c/1637623ad6205162b17804d07512e6f4cbd2a050
- https://git.kernel.org/stable/c/6bab152e817fd41b9e178fa6b275354795c9703d
- https://git.kernel.org/stable/c/d4c368e4a638ddf4a9d6d687b0ff691aa46cce53
- https://git.kernel.org/stable/c/db96a4fd8614d47c0def265e0e6c996b0ee52a38
- https://git.kernel.org/stable/c/ffb34a60ce86656ba12d46e91f1ccc71dd221251
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38138
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Add NULL check in udma_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, udma_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.
- https://git.kernel.org/stable/c/643db430f4cbd91dd2b63c49d62d0abb6debc13b
- https://git.kernel.org/stable/c/9f133e04c62246353b8b1f0a679535c65161ebcf
- https://git.kernel.org/stable/c/b79e10050d9d1e200541d25751dd5cb8ec58483c
- https://git.kernel.org/stable/c/bc6ddff79835f71310a21645d8fcf08ec473e969
- https://git.kernel.org/stable/c/d61d5ba5bd5b0e39e30b34dcd92946e084bca0d0
- https://git.kernel.org/stable/c/ec1ea394c40523835bbedd8fc4934b77b461b6fe
- https://git.kernel.org/stable/c/fd447415e74bccd7362f760d4ea727f8e1ebfe91
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38139
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix oops in write-retry from mis-resetting the subreq iterator
Fix the resetting of the subrequest iterator in netfs_retry_write_stream()
to use the iterator-reset function as the iterator may have been shortened
by a previous retry. In such a case, the amount of data to be written by
the subrequest is not "subreq->len" but "subreq->len -
subreq->transferred".
Without this, KASAN may see an error in iov_iter_revert():
BUG: KASAN: slab-out-of-bounds in iov_iter_revert lib/iov_iter.c:633 [inline]
BUG: KASAN: slab-out-of-bounds in iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611
Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147
CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: events_unbound netfs_write_collection_worker
Call Trace:
Modified: 2025-11-20
CVE-2025-38141
In the Linux kernel, the following vulnerability has been resolved: dm: fix dm_blk_report_zones If dm_get_live_table() returned NULL, dm_put_live_table() was never called. Also, it is possible that md->zone_revalidate_map will change while calling this function. Only read it once, so that we are always using the same value. Otherwise we might miss a call to dm_put_live_table(). Finally, while md->zone_revalidate_map is set and a process is calling blk_revalidate_disk_zones() to set up the zone append emulation resources, it is possible that another process, perhaps triggered by blkdev_report_zones_ioctl(), will call dm_blk_report_zones(). If blk_revalidate_disk_zones() fails, these resources can be freed while the other process is still using them, causing a use-after-free error. blk_revalidate_disk_zones() will only ever be called when initially setting up the zone append emulation resources, such as when setting up a zoned dm-crypt table for the first time. Further table swaps will not set md->zone_revalidate_map or call blk_revalidate_disk_zones(). However it must be called using the new table (referenced by md->zone_revalidate_map) and the new queue limits while the DM device is suspended. dm_blk_report_zones() needs some way to distinguish between a call from blk_revalidate_disk_zones(), which must be allowed to use md->zone_revalidate_map to access this not yet activated table, and all other calls to dm_blk_report_zones(), which should not be allowed while the device is suspended and cannot use md->zone_revalidate_map, since the zone resources might be freed by the process currently calling blk_revalidate_disk_zones(). Solve this by tracking the process that sets md->zone_revalidate_map in dm_revalidate_zones() and only allowing that process to make use of it in dm_blk_report_zones().
Modified: 2025-12-18
CVE-2025-38142
In the Linux kernel, the following vulnerability has been resolved: hwmon: (asus-ec-sensors) check sensor index in read_string() Prevent a potential invalid memory access when the requested sensor is not found. find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info(). Add a proper check to return -EINVAL if sensor_index is negative. Found by Linux Verification Center (linuxtesting.org) with SVACE. [groeck: Return error code returned from find_ec_sensor_index]
- https://git.kernel.org/stable/c/19bd9cde38dd4ca1771aed7afba623e7f4247c8e
- https://git.kernel.org/stable/c/25be318324563c63cbd9cb53186203a08d2f83a1
- https://git.kernel.org/stable/c/4e9e45746b861ebd54c03ef301da2cb8fc990536
- https://git.kernel.org/stable/c/6bf529ce84dccc0074dbc704e70aee4aa545057e
- https://git.kernel.org/stable/c/7eeb3df6f07a886bdfd52757ede127a59a8784dc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38143
In the Linux kernel, the following vulnerability has been resolved: backlight: pm8941: Add NULL check in wled_configure() devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.
- https://git.kernel.org/stable/c/1be2000b703b02e149f8f2061054489f6c18c972
- https://git.kernel.org/stable/c/21528806560510458378ea52c37e35b0773afaea
- https://git.kernel.org/stable/c/4a715be3fe80b68fa55cb3569af3d294be101626
- https://git.kernel.org/stable/c/6a56446595730a5e3f06a30902e23cb037d28146
- https://git.kernel.org/stable/c/9d06ac32c202142da40904180f2669ed4f5073ac
- https://git.kernel.org/stable/c/e12d3e1624a02706cdd3628bbf5668827214fa33
- https://git.kernel.org/stable/c/fde314445332015273c8f51d2659885c606fe135
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38145
In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop() devm_kasprintf() returns NULL when memory allocation fails. Currently, aspeed_lpc_enable_snoop() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. [arj: Fix Fixes: tag to use subject from 3772e5da4454]
- https://git.kernel.org/stable/c/1fd889c145722579aa038c31cbc07cfdd4d75166
- https://git.kernel.org/stable/c/2beee9cf833374550e673d428ad8b6ab37c175b3
- https://git.kernel.org/stable/c/45b2e8b0fdd280aba04c3cc869e9ae500c44e4b7
- https://git.kernel.org/stable/c/8312b1f776f71979bf33bda7acc05b348e8792c7
- https://git.kernel.org/stable/c/c550999f939b529d28a914d5034cc4290066aea6
- https://git.kernel.org/stable/c/d62a589eaaec6385e3e2b25cf5a28b4560ace93f
- https://git.kernel.org/stable/c/f1706e0e1a74b095cbc60375b9b1e6205f5f4c98
- https://git.kernel.org/stable/c/f697ef117ecbf3a367dfc559a6a3589905956530
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38146
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Fix the dead loop of MPLS parse
The unexpected MPLS packet may not end with the bottom label stack.
When there are many stacks, The label count value has wrapped around.
A dead loop occurs, soft lockup/CPU stuck finally.
stack backtrace:
UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26
index -1 is out of range for type '__be32 [3]'
CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu
Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021
Call Trace:
- https://git.kernel.org/stable/c/0bdc924bfb319fb10d1113cbf091fc26fb7b1f99
- https://git.kernel.org/stable/c/3c1906a3d50cb94fd0a10e97a1c0a40c0f033cb7
- https://git.kernel.org/stable/c/4b9a086eedc1fddae632310386098c12155e3d0a
- https://git.kernel.org/stable/c/69541e58323ec3e3904e1fa87a6213961b1f52f4
- https://git.kernel.org/stable/c/8ebcd311b4866ab911d1445ead08690e67f0c488
- https://git.kernel.org/stable/c/ad17eb86d042d72a59fd184ad1adf34f5eb36843
- https://git.kernel.org/stable/c/f26fe7c3002516dd3c288f1012786df31f4d89e0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38147
In the Linux kernel, the following vulnerability has been resolved:
calipso: Don't call calipso functions for AF_INET sk.
syzkaller reported a null-ptr-deref in txopt_get(). [0]
The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,
so struct ipv6_pinfo was NULL there.
However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6
is always set in inet6_create(), meaning the socket was not IPv6 one.
The root cause is missing validation in netlbl_conn_setattr().
netlbl_conn_setattr() switches branches based on struct
sockaddr.sa_family, which is passed from userspace. However,
netlbl_conn_setattr() does not check if the address family matches
the socket.
The syzkaller must have called connect() for an IPv6 address on
an IPv4 socket.
We have a proper validation in tcp_v[46]_connect(), but
security_socket_connect() is called in the earlier stage.
Let's copy the validation to netlbl_conn_setattr().
[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]
RIP: 0010:
Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00
RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c
RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070
RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e
R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00
R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80
FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
- https://git.kernel.org/stable/c/0c813dbc851dbf418fdc6dc883fd0592d6c555cd
- https://git.kernel.org/stable/c/26ce90f1ce60b0ff587de8d6aec399aa55cab28e
- https://git.kernel.org/stable/c/6e9f2df1c550ead7cecb3e450af1105735020c92
- https://git.kernel.org/stable/c/946bfdfcb76ac2bac5b8526447035885ff41c598
- https://git.kernel.org/stable/c/c32ebe33626335a536dbbdd09571c06dd9bc1729
- https://git.kernel.org/stable/c/dd8928897594931d6912ef2f7a43e110b4958d3d
- https://git.kernel.org/stable/c/e2ec310c7a50271843c585e27ef14e48c66ce649
- https://git.kernel.org/stable/c/fc2da88411470480b8b7e9177e930cedd893cf56
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38148
In the Linux kernel, the following vulnerability has been resolved: net: phy: mscc: Fix memory leak when using one step timestamping Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping.
- https://git.kernel.org/stable/c/0b40aeaf83ca04d4c9801e235b7533400c8b5f17
- https://git.kernel.org/stable/c/24b24295464f25fb771d36ed558c7cd942119361
- https://git.kernel.org/stable/c/66abe22017522dd56b820e41ca3a5b131a637001
- https://git.kernel.org/stable/c/846992645b25ec4253167e3f931e4597eb84af56
- https://git.kernel.org/stable/c/cdbabd316c5a4a9b0fda6aafe491e2db17fbb95d
- https://git.kernel.org/stable/c/db2a12ddd3a31f668137ff6a4befc1343c79cbc4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38149
In the Linux kernel, the following vulnerability has been resolved: net: phy: clear phydev->devlink when the link is deleted There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows. [ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is deleted.
Modified: 2025-12-18
CVE-2025-38151
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work The cited commit fixed a crash when cma_netevent_callback was called for a cma_id while work on that id from a previous call had not yet started. The work item was re-initialized in the second call, which corrupted the work item currently in the work queue. However, it left a problem when queue_work fails (because the item is still pending in the work queue from a previous call). In this case, cma_id_put (which is called in the work handler) is therefore not called. This results in a userspace process hang (zombie process). Fix this by calling cma_id_put() if queue_work fails.
- https://git.kernel.org/stable/c/02e45168e0fd6fdc6f8f7c42c4b500857aa5efb0
- https://git.kernel.org/stable/c/1ac40736c8c4255d8417b937c9715b193f4a87b3
- https://git.kernel.org/stable/c/8b05aa3692e45b8249379dc52b14acc6a104d2e5
- https://git.kernel.org/stable/c/92a251c3df8ea1991cd9fe00f1ab0cfce18d7711
- https://git.kernel.org/stable/c/ac7897c0124066b9705ffca252a3662d54fc0c9b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38153
In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: fix error handling of usbnet read calls Syzkaller, courtesy of syzbot, identified an error (see report [1]) in aqc111 driver, caused by incomplete sanitation of usb read calls' results. This problem is quite similar to the one fixed in commit 920a9fa27e78 ("net: asix: add proper error handling of usb read errors"). For instance, usbnet_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will not check its result properly. As [1] shows, this may lead to MAC address in aqc111_bind() being only partly initialized, triggering KMSAN warnings. Fix the issue by verifying that the number of bytes read is as expected and not less. [1] Partial syzbot report: BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772
- https://git.kernel.org/stable/c/11273279012c922f37cfb4dd95d142803fc07b98
- https://git.kernel.org/stable/c/30a9e834c74e260533b8d0885e3c89f6f32f7993
- https://git.kernel.org/stable/c/405b0d610745fb5e84fc2961d9b960abb9f3d107
- https://git.kernel.org/stable/c/60790d287c1a1ced3554d4a87c2f27bf299a932a
- https://git.kernel.org/stable/c/7c01863b1c47f040d9674171e77789a423b9b128
- https://git.kernel.org/stable/c/8c97655275482ef5384ce0501640630a0fc0f6f4
- https://git.kernel.org/stable/c/acb47a40b5e38be03ef659b7bacdddc592ed73b7
- https://git.kernel.org/stable/c/f398d2dfe450ce2c031d10b585448862d74a0501
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38154
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and
during the call to skb_send_sock(), there is a race condition with
the release of sk_socket. All types of sockets(tcp/udp/unix/vsock)
will be affected.
Race conditions:
'''
CPU0 CPU1
backlog::skb_send_sock
sendmsg_unlocked
sock_sendmsg
sock_sendmsg_nosec
close(fd):
...
ops->release() -> sock_map_close()
sk_socket->ops = NULL
free(socket)
sock->ops->sendmsg
^
panic here
'''
The ref of psock become 0 after sock_map_close() executed.
'''
void sock_map_close()
{
...
if (likely(psock)) {
...
// !! here we remove psock and the ref of psock become 0
sock_map_remove_links(sk, psock)
psock = sk_psock_get(sk);
if (unlikely(!psock))
goto no_psock; <=== Control jumps here via goto
...
cancel_delayed_work_sync(&psock->work); <=== not executed
sk_psock_put(sk, psock);
...
}
'''
Based on the fact that we already wait for the workqueue to finish in
sock_map_close() if psock is held, we simply increase the psock
reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will
wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will
fail when invoked by sk_psock_get(), as the psock reference count have
been zeroed, and sk_psock_drop() will cancel all jobs via
cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread
and close() thread.
The panic I catched:
'''
Workqueue: events sk_psock_backlog
RIP: 0010:sock_sendmsg+0x21d/0x440
RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001
...
Call Trace:
- https://git.kernel.org/stable/c/15c0250dae3b48a398447d2b364603821ed4ed90
- https://git.kernel.org/stable/c/4c6fa65ab2aec7df94809478c8d28ef38676a1b7
- https://git.kernel.org/stable/c/4edb40b05cb6a261775abfd8046804ca139a5546
- https://git.kernel.org/stable/c/7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987
- https://git.kernel.org/stable/c/8259eb0e06d8f64c700f5fbdb28a5c18e10de291
- https://git.kernel.org/stable/c/b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38155
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init().
Modified: 2025-11-20
CVE-2025-38156
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init()
Modified: 2025-12-18
CVE-2025-38157
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Abort software beacon handling if disabled A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled.
- https://git.kernel.org/stable/c/0281c19074976ec48f0078d50530b406ddae75bc
- https://git.kernel.org/stable/c/40471b23147c86ea3ed97faee79937c618250bd0
- https://git.kernel.org/stable/c/5482ef9875eaa43f0435e14570e1193823de857e
- https://git.kernel.org/stable/c/5a85c21f812e02cb00ca07007d88acdd42d08c46
- https://git.kernel.org/stable/c/7ee3fb6258da8c890a51b514f60d7570dc703605
- https://git.kernel.org/stable/c/ac4e317a95a1092b5da5b9918b7118759342641c
- https://git.kernel.org/stable/c/e5ce9df1d68094d37360dbd9b09289d42fa21e54
- https://git.kernel.org/stable/c/ee5ee646385f5846dcbc881389f3c44a197c402a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38158
In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: fix XQE dma address error The dma addresses of EQE and AEQE are wrong after migration and results in guest kernel-mode encryption services failure. Comparing the definition of hardware registers, we found that there was an error when the data read from the register was combined into an address. Therefore, the address combination sequence needs to be corrected. Even after fixing the above problem, we still have an issue where the Guest from an old kernel can get migrated to new kernel and may result in wrong data. In order to ensure that the address is correct after migration, if an old magic number is detected, the dma address needs to be updated.
- https://git.kernel.org/stable/c/7710c883eb8cb5cf510ca47ec0e26c6cb7e94a4f
- https://git.kernel.org/stable/c/809a9c10274e1bcf6d05f1c0341459a425a4f05f
- https://git.kernel.org/stable/c/884a76e813178778d271fea59783763d32bb7e72
- https://git.kernel.org/stable/c/8bb7170c5a055ea17c6857c256ee73c10ff872eb
- https://git.kernel.org/stable/c/f0423873e7aeb69cb68f4e8fa3827832e7b037ba
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38159
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace.
- https://git.kernel.org/stable/c/1ee8ea6937d13b20f90ff35d71ccc03ba448182d
- https://git.kernel.org/stable/c/4c2c372de2e108319236203cce6de44d70ae15cd
- https://git.kernel.org/stable/c/68a1037f0bac4de9a585aa9c879ef886109f3647
- https://git.kernel.org/stable/c/74e18211c2c89ab66c9546baa7408288db61aa0d
- https://git.kernel.org/stable/c/9febcc8bded8be0d7efd8237fcef599b6d93b788
- https://git.kernel.org/stable/c/c13255389499275bc5489a0b5b7940ccea3aef04
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38160
In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Add NULL check in raspberrypi_clk_register() devm_kasprintf() returns NULL when memory allocation fails. Currently, raspberrypi_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.
- https://git.kernel.org/stable/c/0a2712cd24ecfeb520af60f6f859b442c7ab01ff
- https://git.kernel.org/stable/c/1b69a5299f28ce8e6afa37c3690dbc14c3a1f53f
- https://git.kernel.org/stable/c/3c1adc2f8c732ea09e8c4bce5941fec019c6205d
- https://git.kernel.org/stable/c/52562161df3567cdaedada46834a7a8d8c4ab737
- https://git.kernel.org/stable/c/54ce9bcdaee59d4ef0703f390d55708557818f9e
- https://git.kernel.org/stable/c/73c46d9a93d071ca69858dea3f569111b03e549e
- https://git.kernel.org/stable/c/938f625bd3364cfdc93916739add3b637ff90368
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38161
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure. Now properly rollback the object to its original state upon such failure. In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8
- https://git.kernel.org/stable/c/0a7790cbba654e925243571cf2f24d61603d3ed3
- https://git.kernel.org/stable/c/26d2f662d3a6655a82fd8a287e8b1ce471567f36
- https://git.kernel.org/stable/c/50ac361ff8914133e3cf6ef184bac90c22cb8d79
- https://git.kernel.org/stable/c/5d2ea5aebbb2f3ebde4403f9c55b2b057e5dd2d6
- https://git.kernel.org/stable/c/7c4c84cdcc19e89d42f6bf117238e5471173423e
- https://git.kernel.org/stable/c/cf32affe6f3801cfb72a65e69c4bc7a8ee9be100
- https://git.kernel.org/stable/c/f9784da76ad7be66230e829e743bdf68a2c49e56
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-25
CVE-2025-38162
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: prevent overflow in lookup table allocation When calculating the lookup table size, ensure the following multiplication does not overflow: - desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case. - NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field. Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this. While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().
- https://git.kernel.org/stable/c/43fe1181f738295624696ae9ff611790edb65b5e
- https://git.kernel.org/stable/c/4c5c6aa9967dbe55bd017bb509885928d0f31206
- https://git.kernel.org/stable/c/91edc076439c9e2f34b176149f1c84a47a8ec32f
- https://git.kernel.org/stable/c/a9e757473561da93c6a4136f0e59aba91ec777fc
- https://git.kernel.org/stable/c/c1360ac8156c0a3f2385baef91d8d26fd9d39701
Modified: 2025-12-18
CVE-2025-38163
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sbi->total_valid_block_count syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94 The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.
- https://git.kernel.org/stable/c/05872a167c2cab80ef186ef23cc34a6776a1a30c
- https://git.kernel.org/stable/c/25f3776b58c1c45ad2e50ab4b263505b4d2378ca
- https://git.kernel.org/stable/c/49bc7bf38e42cfa642787e947f5721696ea73ac3
- https://git.kernel.org/stable/c/65b3f76592aed5a43c4d79375ac097acf975972b
- https://git.kernel.org/stable/c/6a324d77f7ea1a91d55c4b6ad970e3ac9ab6a20d
- https://git.kernel.org/stable/c/a39cc43efc1bca74ed9d6cf9e60b995071f7d178
- https://git.kernel.org/stable/c/ccc28c0397f75a3ec9539cceed9db014d7b73869
- https://git.kernel.org/stable/c/f1b743c1955151bd392539b739a3ad155296be13
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-25
CVE-2025-38164
In the Linux kernel, the following vulnerability has been resolved:
f2fs: zone: fix to avoid inconsistence in between SIT and SSA
w/ below testcase, it will cause inconsistence in between SIT and SSA.
create_null_blk 512 2 1024 1024
mkfs.f2fs -m /dev/nullb0
mount /dev/nullb0 /mnt/f2fs/
touch /mnt/f2fs/file
f2fs_io pinfile set /mnt/f2fs/file
fallocate -l 4GiB /mnt/f2fs/file
F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT
CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G O 6.13.0-rc1 #84
Tainted: [O]=OOT_MODULE
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Call Trace:
Modified: 2025-12-18
CVE-2025-38165
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix panic when calling skb_linearize
The panic can be reproduced by executing the command:
./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000
Then a kernel panic was captured:
'''
[ 657.460555] kernel BUG at net/core/skbuff.c:2178!
[ 657.462680] Tainted: [W]=WARN
[ 657.463287] Workqueue: events sk_psock_backlog
...
[ 657.469610]
- https://git.kernel.org/stable/c/3d25fa2d7f127348c818e1dab9e58534f7ac56cc
- https://git.kernel.org/stable/c/4dba44333a11522df54b49aa1f2edfaf6ce35fc7
- https://git.kernel.org/stable/c/5ca2e29f6834c64c0e5a9ccf1278c21fb49b827e
- https://git.kernel.org/stable/c/9718ba6490732dbe70190d42c21deb1440834402
- https://git.kernel.org/stable/c/db1d15a26f21f97459508c42ae87cabe8d3afc3b
- https://git.kernel.org/stable/c/e9c1299d813fc04668042690f2c3cc76d013959a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38166
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix ktls panic with sockmap
[ 2172.936997] ------------[ cut here ]------------
[ 2172.936999] kernel BUG at lib/iov_iter.c:629!
......
[ 2172.944996] PKRU: 55555554
[ 2172.945155] Call Trace:
[ 2172.945299]
- https://git.kernel.org/stable/c/2e36a81d388ec9c3f78b6223f7eda2088cd40adb
- https://git.kernel.org/stable/c/328cac3f9f8ae394748485e769a527518a9137c8
- https://git.kernel.org/stable/c/54a3ecaeeeae8176da8badbd7d72af1017032c39
- https://git.kernel.org/stable/c/57fbbe29e86042bbaa31c1a30d2afa16c427e3f7
- https://git.kernel.org/stable/c/603943f022a7fe5cc83ca7005faf34798fb7853f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38167
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: handle hdr_first_de() return value The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently. Additionally, error handling for the return value already exists at other points where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/2d5879f64554181b89f44d4817b9ea86e8e913e1
- https://git.kernel.org/stable/c/4ecd0cde89feee26525ccdf1af0c1ae156ca010b
- https://git.kernel.org/stable/c/5390b3d4c6d41d05bb9149d094d504cbc9ea85bf
- https://git.kernel.org/stable/c/701340a25b1ad210e6b8192195be21fd3fcc22c7
- https://git.kernel.org/stable/c/83cd0aa74793384dbdffc140500b200e9776a302
- https://git.kernel.org/stable/c/af5cab0e5b6f8edb0be51a9f47f3f620e0b4fd70
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38168
In the Linux kernel, the following vulnerability has been resolved: perf: arm-ni: Unregister PMUs on probe failure When a resource allocation fails in one clock domain of an NI device, we need to properly roll back all previously registered perf PMUs in other clock domains of the same device. Otherwise, it can lead to kernel panics. Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374 arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000 arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16 list_add corruption: next->prev should be prev (fffffd01e9698a18), but was 0000000000000000. (next=ffff10001a0decc8). pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : list_add_valid_or_report+0x7c/0xb8 lr : list_add_valid_or_report+0x7c/0xb8 Call trace: __list_add_valid_or_report+0x7c/0xb8 perf_pmu_register+0x22c/0x3a0 arm_ni_probe+0x554/0x70c [arm_ni] platform_probe+0x70/0xe8 really_probe+0xc6/0x4d8 driver_probe_device+0x48/0x170 __driver_attach+0x8e/0x1c0 bus_for_each_dev+0x64/0xf0 driver_add+0x138/0x260 bus_add_driver+0x68/0x138 __platform_driver_register+0x2c/0x40 arm_ni_init+0x14/0x2a [arm_ni] do_init_module+0x36/0x298 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops - BUG: Fatal exception SMP: stopping secondary CPUs
Modified: 2025-11-20
CVE-2025-38169
In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP On system with SME, a thread's kernel FPSIMD state may be erroneously clobbered during a context switch immediately after that state is restored. Systems without SME are unaffected. If the CPU happens to be in streaming SVE mode before a context switch to a thread with kernel FPSIMD state, fpsimd_thread_switch() will restore the kernel FPSIMD state using fpsimd_load_kernel_state() while the CPU is still in streaming SVE mode. When fpsimd_thread_switch() subsequently calls fpsimd_flush_cpu_state(), this will execute an SMSTOP, causing an exit from streaming SVE mode. The exit from streaming SVE mode will cause the hardware to reset a number of FPSIMD/SVE/SME registers, clobbering the FPSIMD state. Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel FPSIMD state.
Modified: 2025-12-18
CVE-2025-38170
In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Discard stale CPU state when handling SME traps The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps") The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g. | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Note: this was originallly posted as [1]. [ Rutland: rewrite commit message ]
- https://git.kernel.org/stable/c/43be952e885476dafb74aa832c0847b2f4f650c6
- https://git.kernel.org/stable/c/6103f9ba51a59afb5a0f32299c837377c5a5a693
- https://git.kernel.org/stable/c/c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3
- https://git.kernel.org/stable/c/d3eaab3c70905c5467e5c4ea403053d67505adeb
- https://git.kernel.org/stable/c/de89368de3894a8db27caeb8fd902ba1c49f696a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38172
In the Linux kernel, the following vulnerability has been resolved: erofs: avoid using multiple devices with different type For multiple devices, both primary and extra devices should be the same type. `erofs_init_device` has already guaranteed that if the primary is a file-backed device, extra devices should also be regular files. However, if the primary is a block device while the extra device is a file-backed device, `erofs_init_device` will get an ENOTBLK, which is not treated as an error in `erofs_fc_get_tree`, and that leads to an UAF: erofs_fc_get_tree get_tree_bdev_flags(erofs_fc_fill_super) erofs_read_superblock erofs_init_device // sbi->dif0 is not inited yet, // return -ENOTBLK deactivate_locked_super free(sbi) if (err is -ENOTBLK) sbi->dif0.file = filp_open() // sbi UAF So if -ENOTBLK is hitted in `erofs_init_device`, it means the primary device must be a block device, and the extra device is not a block device. The error can be converted to -EINVAL.
Modified: 2025-12-18
CVE-2025-38173
In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/cesa - Handle zero-length skcipher requests Do not access random memory for zero-length skcipher requests. Just return 0.
- https://git.kernel.org/stable/c/32d3e8049a8b60f18c5c39f5931bfb1130ac11c9
- https://git.kernel.org/stable/c/5e9666ac8b94c978690f937d59170c5237bd2c45
- https://git.kernel.org/stable/c/7894694b5d5b2ecfd7fb081d6f60b9e169ab4d13
- https://git.kernel.org/stable/c/78ea1ff6cb413a03ff6f7af4e28e24b4461a0965
- https://git.kernel.org/stable/c/8a4e047c6cc07676f637608a9dd675349b5de0a7
- https://git.kernel.org/stable/c/c064ae2881d839709bd72d484d5f2af157f46024
- https://git.kernel.org/stable/c/c9610dda42bd382a96f97e68825cb5f66cd9e1dc
- https://git.kernel.org/stable/c/e1cc69da619588b1488689fe3535a0ba75a2b0e7
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38174
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Do not double dequeue a configuration request
Some of our devices crash in tb_cfg_request_dequeue():
general protection fault, probably for non-canonical address 0xdead000000000122
CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65
RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0
Call Trace:
- https://git.kernel.org/stable/c/0771bcbe2f6e5d5f263cf466efe571d2754a46da
- https://git.kernel.org/stable/c/0a3011d47dbc92a33621861c423cb64833d7fe57
- https://git.kernel.org/stable/c/0f73628e9da1ee39daf5f188190cdbaee5e0c98c
- https://git.kernel.org/stable/c/2f62eda4d974c26bc595425eafd429067541f2c9
- https://git.kernel.org/stable/c/5a057f261539720165d03d85024da2b52e67f63d
- https://git.kernel.org/stable/c/85286e634ebbaf9c0fb1cdf580add2f33fc7628c
- https://git.kernel.org/stable/c/cdb4feab2f39e75a66239e3a112beced279612a8
- https://git.kernel.org/stable/c/e49e994cd83705f7ca30eda1e304abddfd96a37a
- https://git.kernel.org/stable/c/eb2d5e794fb966b3ef8bde99eb8561446a53509f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38179
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix max_sge overflow in smb_extract_folioq_to_rdma()
This fixes the following problem:
[ 749.901015] [ T8673] run fstests cifs/001 at 2025-06-17 09:40:30
[ 750.346409] [ T9870] ==================================================================
[ 750.346814] [ T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870
[ 750.347705] [ T9870]
[ 750.348077] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)
[ 750.348082] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 750.348085] [ T9870] Call Trace:
[ 750.348086] [ T9870]
Modified: 2025-12-18
CVE-2025-38180
In the Linux kernel, the following vulnerability has been resolved: net: atm: fix /proc/net/atm/lec handling /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls without prior dev_hold(), leading to imbalance and UAF.
- https://git.kernel.org/stable/c/5fe1b23a2f87f43aeeac51e08819cbc6fd808cbc
- https://git.kernel.org/stable/c/9b9aeb3ada44d8abea1e31e4446113f460848ae4
- https://git.kernel.org/stable/c/a5e3a144268899f1a8c445c8a3bfa15873ba85e8
- https://git.kernel.org/stable/c/ca3829c18c8d0ceb656605d3bff6bb3dfb078589
- https://git.kernel.org/stable/c/d03b79f459c7935cff830d98373474f440bd03ae
- https://git.kernel.org/stable/c/e612c4b014f5808fbc6beae21f5ccaca5e76a2f8
- https://git.kernel.org/stable/c/f2d1443b18806640abdb530e88009af7be2588e7
- https://git.kernel.org/stable/c/fcfccf56f4eba7d00aa2d33c7bb1b33083237742
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38181
In the Linux kernel, the following vulnerability has been resolved:
calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().
syzkaller reported a null-ptr-deref in sock_omalloc() while allocating
a CALIPSO option. [0]
The NULL is of struct sock, which was fetched by sk_to_full_sk() in
calipso_req_setattr().
Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),
reqsk->rsk_listener could be NULL when SYN Cookie is returned to its
client, as hinted by the leading SYN Cookie log.
Here are 3 options to fix the bug:
1) Return 0 in calipso_req_setattr()
2) Return an error in calipso_req_setattr()
3) Alaways set rsk_listener
1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie
for CALIPSO. 3) is also no go as there have been many efforts to reduce
atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35
("tcp/dccp: do not touch listener sk_refcnt under synflood").
As of the blamed commit, SYN Cookie already did not need refcounting,
and no one has stumbled on the bug for 9 years, so no CALIPSO user will
care about SYN Cookie.
Let's return an error in calipso_req_setattr() and calipso_req_delattr()
in the SYN Cookie case.
This can be reproduced by [1] on Fedora and now connect() of nc times out.
[0]:
TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]
RIP: 0010:sock_net include/net/sock.h:655 [inline]
RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806
Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b
RSP: 0018:ffff88811af89038 EFLAGS: 00010216
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400
RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030
RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e
R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000
R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050
FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
- https://git.kernel.org/stable/c/058dd4a370f23a5553a9449f2db53d5bfa88d45e
- https://git.kernel.org/stable/c/10876da918fa1aec0227fb4c67647513447f53a9
- https://git.kernel.org/stable/c/956f1499412ed0953f6a116df7fdb855e9f1fc66
- https://git.kernel.org/stable/c/988edde4d52d5c02ea4dd95d7619372a5e2fb7b7
- https://git.kernel.org/stable/c/bde8833eb075ba8e8674de88e32de6b669966451
- https://git.kernel.org/stable/c/d092c7fd8e220b23d6c47e03d7d0cc79e731f379
- https://git.kernel.org/stable/c/dc724bd34d56f5589f7587a091a8cda2386826c4
- https://git.kernel.org/stable/c/f4ae0f61dd9a63329ecb49b1e6356139d43240b8
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38182
In the Linux kernel, the following vulnerability has been resolved: ublk: santizize the arguments from userspace when adding a device Sanity check the values for queue depth and number of queues we get from userspace when adding a device.
Modified: 2025-12-18
CVE-2025-38183
In the Linux kernel, the following vulnerability has been resolved: net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get() Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8). This seems correct and aligns with the PTP interrupt status register (PTP_INT_STS) specifications. However, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index: lan743x_ptp_io_event_clock_get(..., u8 channel,...) { ... /* Update Local timestamp */ extts = &ptp->extts[channel]; extts->ts.tv_sec = sec; ... } To avoid an out-of-bounds write and utilize all the supported GPIO inputs, set LAN743X_PTP_N_EXTTS to 8. Detected using the static analysis tool - Svace.
- https://git.kernel.org/stable/c/41017bd66c533f7af912c58273c7dfd5de0065d4
- https://git.kernel.org/stable/c/4da0d23516857230b8e9b3022e25422ee2e2ba80
- https://git.kernel.org/stable/c/66bba1fd5bad548c03f7e42669a59f3f4d8211cc
- https://git.kernel.org/stable/c/e353b0854d3a1a31cb061df8d022fbfea53a0f24
- https://git.kernel.org/stable/c/e8d48201a132f4aab31351c19a802c5a5ae820fa
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38184
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer
The reproduction steps:
1. create a tun interface
2. enable l2 bearer
3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun
tipc: Started in network mode
tipc: Node identity 8af312d38a21, cluster identity 4711
tipc: Enabled bearer
- https://git.kernel.org/stable/c/05d332ba075753d569d66333d62d60fff5f57ad8
- https://git.kernel.org/stable/c/0d3d91c3500f0c480e016faa4e2259c588616e59
- https://git.kernel.org/stable/c/0f4a72fb266e48dbe928e1d936eab149e4ac3e1b
- https://git.kernel.org/stable/c/3998283e4c32c0fe69edd59b0876c193f50abce6
- https://git.kernel.org/stable/c/8595350615f952fcf8bc861464a6bf6b1129af50
- https://git.kernel.org/stable/c/c2e17984752b9131061d1a2ca1199da2706337fd
- https://git.kernel.org/stable/c/d3dfe821dfe091c0045044343c8d86596d66e2cf
- https://git.kernel.org/stable/c/f82727adcf2992822e12198792af450a76ebd5ef
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38185
In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Free invalid length skb in atmtcp_c_send(). syzbot reported the splat below. [0] vcc_sendmsg() copies data passed from userspace to skb and passes it to vcc->dev->ops->send(). atmtcp_c_send() accesses skb->data as struct atmtcp_hdr after checking if skb->len is 0, but it's not enough. Also, when skb->len == 0, skb and sk (vcc) were leaked because dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing to revert atm_account_tx() in vcc_sendmsg(), which is expected to be done in atm_pop_raw(). Let's properly free skb with an invalid length in atmtcp_c_send(). [0]: BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
- https://git.kernel.org/stable/c/1b0ad18704913c92a3ad53748fbc0f219a75b876
- https://git.kernel.org/stable/c/2f370ae1fb6317985f3497b1bb80d457508ca2f7
- https://git.kernel.org/stable/c/3261c017a7c5d2815c6a388c5a3280d1fba0e8db
- https://git.kernel.org/stable/c/a4b0fd8c25a7583f8564af6cc910418fb8954e89
- https://git.kernel.org/stable/c/c19c0943424b412a84fdf178e6c71fe5480e4f0f
- https://git.kernel.org/stable/c/c9260c837de1d2b454960a4a2e44a81272fbcd22
- https://git.kernel.org/stable/c/ca00f0e6d733ecd9150716d1fd0138d26e674706
- https://git.kernel.org/stable/c/e996507f59610e5752b8702537f13f551e7a2c96
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38186
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start()
Before the commit under the Fixes tag below, bnxt_ulp_stop() and
bnxt_ulp_start() were always invoked in pairs. After that commit,
the new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop()
has been called. This may result in the RoCE driver's aux driver
.suspend() method being invoked twice. The 2nd bnxt_re_suspend()
call will crash when it dereferences a NULL pointer:
(NULL ib_device): Handle device suspend call
BUG: kernel NULL pointer dereference, address: 0000000000000b78
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S 6.15.0-rc1 #4 PREEMPT(voluntary)
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
Workqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en]
RIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re]
Code: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff <48> 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00
RSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff
RBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff
R10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070
R13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2025-11-19
CVE-2025-38188
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE Calling this packet is necessary when we switch contexts because there are various pieces of state used by userspace to synchronize between BR and BV that are persistent across submits and we need to make sure that they are in a "safe" state when switching contexts. Otherwise a userspace submission in one context could cause another context to function incorrectly and hang, effectively a denial of service (although without leaking data). This was missed during initial a7xx bringup. Patchwork: https://patchwork.freedesktop.org/patch/654924/
Modified: 2025-11-19
CVE-2025-38189
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Avoid NULL pointer dereference in `v3d_job_update_stats()` The following kernel Oops was recently reported by Mesa CI: [ 800.139824] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000588 [ 800.148619] Mem abort info: [ 800.151402] ESR = 0x0000000096000005 [ 800.155141] EC = 0x25: DABT (current EL), IL = 32 bits [ 800.160444] SET = 0, FnV = 0 [ 800.163488] EA = 0, S1PTW = 0 [ 800.166619] FSC = 0x05: level 1 translation fault [ 800.171487] Data abort info: [ 800.174357] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 800.179832] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 800.184873] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 800.190176] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001014c2000 [ 800.196607] [0000000000000588] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 800.205305] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 800.211564] Modules linked in: vc4 snd_soc_hdmi_codec drm_display_helper v3d cec gpu_sched drm_dma_helper drm_shmem_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm i2c_brcmstb snd_timer snd backlight [ 800.234448] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 800.244182] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 800.250005] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 800.256959] pc : v3d_job_update_stats+0x60/0x130 [v3d] [ 800.262112] lr : v3d_job_update_stats+0x48/0x130 [v3d] [ 800.267251] sp : ffffffc080003e60 [ 800.270555] x29: ffffffc080003e60 x28: ffffffd842784980 x27: 0224012000000000 [ 800.277687] x26: ffffffd84277f630 x25: ffffff81012fd800 x24: 0000000000000020 [ 800.284818] x23: ffffff8040238b08 x22: 0000000000000570 x21: 0000000000000158 [ 800.291948] x20: 0000000000000000 x19: ffffff8040238000 x18: 0000000000000000 [ 800.299078] x17: ffffffa8c1bd2000 x16: ffffffc080000000 x15: 0000000000000000 [ 800.306208] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 800.313338] x11: 0000000000000040 x10: 0000000000001a40 x9 : ffffffd83b39757c [ 800.320468] x8 : ffffffd842786420 x7 : 7fffffffffffffff x6 : 0000000000ef32b0 [ 800.327598] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : ffffffd842784980 [ 800.334728] x2 : 0000000000000004 x1 : 0000000000010002 x0 : 000000ba4c0ca382 [ 800.341859] Call trace: [ 800.344294] v3d_job_update_stats+0x60/0x130 [v3d] [ 800.349086] v3d_irq+0x124/0x2e0 [v3d] [ 800.352835] __handle_irq_event_percpu+0x58/0x218 [ 800.357539] handle_irq_event+0x54/0xb8 [ 800.361369] handle_fasteoi_irq+0xac/0x240 [ 800.365458] handle_irq_desc+0x48/0x68 [ 800.369200] generic_handle_domain_irq+0x24/0x38 [ 800.373810] gic_handle_irq+0x48/0xd8 [ 800.377464] call_on_irq_stack+0x24/0x58 [ 800.381379] do_interrupt_handler+0x88/0x98 [ 800.385554] el1_interrupt+0x34/0x68 [ 800.389123] el1h_64_irq_handler+0x18/0x28 [ 800.393211] el1h_64_irq+0x64/0x68 [ 800.396603] default_idle_call+0x3c/0x168 [ 800.400606] do_idle+0x1fc/0x230 [ 800.403827] cpu_startup_entry+0x40/0x50 [ 800.407742] rest_init+0xe4/0xf0 [ 800.410962] start_kernel+0x5e8/0x790 [ 800.414616] __primary_switched+0x80/0x90 [ 800.418622] Code: 8b170277 8b160296 11000421 b9000861 (b9401ac1) [ 800.424707] ---[ end trace 0000000000000000 ]--- [ 800.457313] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- This issue happens when the file descriptor is closed before the jobs submitted by it are completed. When the job completes, we update the global GPU stats and the per-fd GPU stats, which are exposed through fdinfo. If the file descriptor was closed, then the struct `v3d_file_priv` and its stats were already freed and we can't update the per-fd stats. Therefore, if the file descriptor was already closed, don't u ---truncated---
Modified: 2025-12-18
CVE-2025-38190
In the Linux kernel, the following vulnerability has been resolved: atm: Revert atm_account_tx() if copy_from_iter_full() fails. In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by atm_account_tx(). It is expected to be reverted by atm_pop_raw() later called by vcc->dev->ops->send(vcc, skb). However, vcc_sendmsg() misses the same revert when copy_from_iter_full() fails, and then we will leak a socket. Let's factorise the revert part as atm_return_tx() and call it in the failure path. Note that the corresponding sk_wmem_alloc operation can be found in alloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~
- https://git.kernel.org/stable/c/2252c539c43f9a1431a7e8b34e3c18e9dd77a96d
- https://git.kernel.org/stable/c/287b4f085d2ca3375cf1ee672af27410c64777e8
- https://git.kernel.org/stable/c/3902205eadf35db59dbc2186c2a98b9e6182efa5
- https://git.kernel.org/stable/c/3d828519bd69bfcaabdd942a872679617ef06739
- https://git.kernel.org/stable/c/5e0d00992118e234ebf29d5145c1cc920342777e
- https://git.kernel.org/stable/c/7851263998d4269125fd6cb3fdbfc7c6db853859
- https://git.kernel.org/stable/c/7d6bc28cfe5c8e3a279b4b4bdeed6698b2702685
- https://git.kernel.org/stable/c/c12430edd92fd49a4800b0f3fb395b50cb16bcc1
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38191
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference in destroy_previous_session If client set ->PreviousSessionId on kerberos session setup stage, NULL pointer dereference error will happen. Since sess->user is not set yet, It can pass the user argument as NULL to destroy_previous_session. sess->user will be set in ksmbd_krb5_authenticate(). So this patch move calling destroy_previous_session() after ksmbd_krb5_authenticate().
- https://git.kernel.org/stable/c/076f1adefb9837977af7ed233883842ddc446644
- https://git.kernel.org/stable/c/0902625a24eea7fdc187faa5d97df244d159dd6e
- https://git.kernel.org/stable/c/1193486dffb7432a09f57f5d09049b4d4123538b
- https://git.kernel.org/stable/c/281afc52e2961cd5dd8326ebc9c5bc40904c0468
- https://git.kernel.org/stable/c/7ac5b66acafcc9292fb935d7e03790f2b8b2dc0e
- https://www.zerodayinitiative.com/advisories/ZDI-25-610/
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-25
CVE-2025-38192
In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.
- https://git.kernel.org/stable/c/2a3ad42a57b43145839f2f233fb562247658a6d9
- https://git.kernel.org/stable/c/98b1d8dc9a3170b2614f1e8c93854e75cdd83980
- https://git.kernel.org/stable/c/ba9db6f907ac02215e30128770f85fbd7db2fcf9
- https://git.kernel.org/stable/c/bfa4d86e130a09f67607482e988313430e38f6c4
- https://git.kernel.org/stable/c/e9994e7b9f7bbb882d13c8191731649249150d21
Modified: 2025-12-18
CVE-2025-38193
In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: reject invalid perturb period Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch. We want to make sure ctl->perturb_period * HZ will not overflow and is positive. tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0
- https://git.kernel.org/stable/c/0357da9149eac621f39e235a135ebf155f01f7c3
- https://git.kernel.org/stable/c/2254d038dab9c194fe6a4b1ce31034f42e91a6e5
- https://git.kernel.org/stable/c/590b2d7d0beadba2aa576708a05a05f0aae39295
- https://git.kernel.org/stable/c/7ca52541c05c832d32b112274f81a985101f9ba8
- https://git.kernel.org/stable/c/956b5aebb349449b38d920d444ca1392d43719d1
- https://git.kernel.org/stable/c/b11a50544af691b787384089b68f740ae20a441b
- https://git.kernel.org/stable/c/e0936ff56be4e08ad5b60ec26971eae0c40af305
- https://git.kernel.org/stable/c/f9b97d466e6026ccbdda30bb5b71965b67ccbc82
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38194
In the Linux kernel, the following vulnerability has been resolved:
jffs2: check that raw node were preallocated before writing summary
Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault
injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't
check return value of jffs2_prealloc_raw_node_refs and simply lets any
error propagate into jffs2_sum_write_data, which eventually calls
jffs2_link_node_ref in order to link the summary to an expectedly allocated
node.
kernel BUG at fs/jffs2/nodelist.c:592!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592
Call Trace:
- https://git.kernel.org/stable/c/337f80f3d546e131c7aa90b61d8cde051ae858c7
- https://git.kernel.org/stable/c/346cfb9d19ea7feb6fb57917b21c4797fb444dab
- https://git.kernel.org/stable/c/3f46644a5131a4793fc95c32a7d0a769745b06e7
- https://git.kernel.org/stable/c/4adee34098a6ee86a54bf3ec885eab620c126a6b
- https://git.kernel.org/stable/c/8ce46dc5b10b0b6f67663202a4921b0e11ad7367
- https://git.kernel.org/stable/c/c0edcdb4fc106d69a2d1a0ce4868193511c389f3
- https://git.kernel.org/stable/c/da12ef7e19048dc5714032c2db587a215852b200
- https://git.kernel.org/stable/c/ec9e6f22bce433b260ea226de127ec68042849b0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38195
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset() ERROR INFO: CPU 25 Unable to handle kernel paging request at virtual address 0x0 ... Call Trace: [<900000000023c30c>] huge_pte_offset+0x3c/0x58 [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438 [<900000000051fee8>] __get_user_pages+0xe0/0x4c8 [<9000000000522414>] faultin_page_range+0x84/0x380 [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48 [<900000000056689c>] do_madvise+0x1bc/0x3e8 [<9000000000566df4>] sys_madvise+0x24/0x38 [<90000000015b9e88>] do_syscall+0x78/0x98 [<9000000000221f18>] handle_syscall+0xb8/0x158 In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here.
Modified: 2025-12-18
CVE-2025-38197
In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell_rbu: Fix list usage Pass the correct list head to list_for_each_entry*() when looping through the packet list. Without this patch, reading the packet data via sysfs will show the data incorrectly (because it starts at the wrong packet), and clearing the packet list will result in a NULL pointer dereference.
- https://git.kernel.org/stable/c/07d7b8e7ef7d1f812a6211ed531947c56d09e95e
- https://git.kernel.org/stable/c/32d05e6cc3a7bf6c8f16f7b7ef8fe80eca0c233e
- https://git.kernel.org/stable/c/4d71f2c1e5263a9f042faa71d59515709869dc79
- https://git.kernel.org/stable/c/5e8c658acd1b7c186aeffa46bf08795e121f401a
- https://git.kernel.org/stable/c/61ce04601e0d8265ec6d2ffa6df5a7e1bce64854
- https://git.kernel.org/stable/c/a7b477b64ef5e37cb08dd536ae07c46f9f28262e
- https://git.kernel.org/stable/c/f3b840fb1508a80cd8a0efb5c886ae1995a88b24
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38198
In the Linux kernel, the following vulnerability has been resolved: fbcon: Make sure modelist not set on unregistered console It looks like attempting to write to the "store_modes" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly.
- https://git.kernel.org/stable/c/519ba75728ee8cd561dce25fc52a2ec5c47171dc
- https://git.kernel.org/stable/c/54b28f7c567dd659e5f9562f518e4d7f3f6a367b
- https://git.kernel.org/stable/c/b3237d451bf3a4490cb1a76f3b7c91d9888f1c4b
- https://git.kernel.org/stable/c/cedc1b63394a866bf8663a3e40f4546f1d28c8d8
- https://git.kernel.org/stable/c/f28f1f578cd810779d01999c60618cda14c281dd
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38200
In the Linux kernel, the following vulnerability has been resolved: i40e: fix MMIO write access to an invalid page in i40e_clear_hw When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables.
- https://git.kernel.org/stable/c/015bac5daca978448f2671478c553ce1f300c21e
- https://git.kernel.org/stable/c/2a1f4f2e36442a9bdf771acf6ee86f3cf876e5ca
- https://git.kernel.org/stable/c/3502dd42f178dae9d54696013386bb52b4f2e655
- https://git.kernel.org/stable/c/5e75c9082987479e647c75ec8fdf18fa68263c42
- https://git.kernel.org/stable/c/872607632c658d3739e4e7889e4f3c419ae2c193
- https://git.kernel.org/stable/c/8cde755f56163281ec2c46b4ae8b61f532758a6f
- https://git.kernel.org/stable/c/d88a1e8f024ba26e19350958fecbf771a9960352
- https://git.kernel.org/stable/c/fecb2fc3fc10c95724407cc45ea35af4a65cdde2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38201
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")
- https://git.kernel.org/stable/c/0ab3de047808f375a36cd345225572eb3366f3c6
- https://git.kernel.org/stable/c/1fe27f97944017a9d3c5af4d6d95282bff0f1147
- https://git.kernel.org/stable/c/4abccfb61f422300be014b8e734c63344306f009
- https://git.kernel.org/stable/c/80417057ac60dd80f4816eb426e4e4a5bf696534
- https://git.kernel.org/stable/c/b85e3367a5716ed3662a4fe266525190d2af76df
- https://git.kernel.org/stable/c/d2768016f091f8a5264076b433fd7c3fabb6eb97
- https://git.kernel.org/stable/c/df524a68d9021c1401965d610bb6e42ee5d9611e
Modified: 2025-12-18
CVE-2025-38202
In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem() bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check.
- https://git.kernel.org/stable/c/2d834477bbc1e8b8a59ff8b0c081529d6bed7b22
- https://git.kernel.org/stable/c/2f8c69a72e8ad87b36b8052f789da3cc2b2e186c
- https://git.kernel.org/stable/c/7bf4461f1c97207fda757014690d55a447ce859f
- https://git.kernel.org/stable/c/b522d4d334f206284b1a44b0b0b2f99fd443b39b
- https://git.kernel.org/stable/c/d4965578267e2e81f67c86e2608481e77e9c8569
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38208
In the Linux kernel, the following vulnerability has been resolved: smb: client: add NULL check in automount_fullpath page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference.
Modified: 2025-11-18
CVE-2025-38210
In the Linux kernel, the following vulnerability has been resolved: configfs-tsm-report: Fix NULL dereference of tsm_ops Unlike sysfs, the lifetime of configfs objects is controlled by userspace. There is no mechanism for the kernel to find and delete all created config-items. Instead, the configfs-tsm-report mechanism has an expectation that tsm_unregister() can happen at any time and cause established config-item access to start failing. That expectation is not fully satisfied. While tsm_report_read(), tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail if tsm_ops have been unregistered, tsm_report_privlevel_store() tsm_report_provider_show() fail to check for ops registration. Add the missing checks for tsm_ops having been removed. Now, in supporting the ability for tsm_unregister() to always succeed, it leaves the problem of what to do with lingering config-items. The expectation is that the admin that arranges for the ->remove() (unbind) of the ${tsm_arch}-guest driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bind) of the ${tsm_arch}-guest driver fails. This allows for emergency shutdown / revocation of attestation interfaces, and requires coordinated restart.
Modified: 2025-12-18
CVE-2025-38211
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction
The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last
deref") simplified cm_id resource management by freeing cm_id once all
references to the cm_id were removed. The references are removed either
upon completion of iw_cm event handlers or when the application destroys
the cm_id. This commit introduced the use-after-free condition where
cm_id_private object could still be in use by event handler works during
the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a
use-after-free related to destroying CM IDs") addressed this use-after-
free by flushing all pending works at the cm_id destruction.
However, still another use-after-free possibility remained. It happens
with the work objects allocated for each cm_id_priv within
alloc_work_entries() during cm_id creation, and subsequently freed in
dealloc_work_entries() once all references to the cm_id are removed.
If the cm_id's last reference is decremented in the event handler work,
the work object for the work itself gets removed, and causes the use-
after-free BUG below:
BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250
Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091
CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
Workqueue: 0x0 (iw_cm_wq)
Call Trace:
- https://git.kernel.org/stable/c/013dcdf6f03bcedbaf1669e3db71c34a197715b2
- https://git.kernel.org/stable/c/23a707bbcbea468eedb398832eeb7e8e0ceafd21
- https://git.kernel.org/stable/c/3b4a50d733acad6831f6bd9288a76a80f70650ac
- https://git.kernel.org/stable/c/6883b680e703c6b2efddb4e7a8d891ce1803d06b
- https://git.kernel.org/stable/c/764c9f69beabef8bdc651a7746c59f7a340d104f
- https://git.kernel.org/stable/c/78381dc8a6b61c9bb9987d37b4d671b99767c4a1
- https://git.kernel.org/stable/c/bf7eff5e3a36c54bbe8aff7fd6dd7c07490b81c5
- https://git.kernel.org/stable/c/fd960b5ddf4faf00da43babdd3acda68842e1f6a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38212
In the Linux kernel, the following vulnerability has been resolved: ipc: fix to protect IPCS lookups using RCU syzbot reported that it discovered a use-after-free vulnerability, [0] [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/ idr_for_each() is protected by rwsem, but this is not enough. If it is not protected by RCU read-critical region, when idr_for_each() calls radix_tree_node_free() through call_rcu() to free the radix_tree_node structure, the node will be freed immediately, and when reading the next node in radix_tree_for_each_slot(), the already freed memory may be read. Therefore, we need to add code to make sure that idr_for_each() is protected within the RCU read-critical region when we call it in shm_destroy_orphaned().
- https://git.kernel.org/stable/c/5180561afff8e0f029073c8c8117c95c6512d1f9
- https://git.kernel.org/stable/c/5f1e1573bf103303944fd7225559de5d8297539c
- https://git.kernel.org/stable/c/68c173ea138b66d7dd1fd980c9bc578a18e11884
- https://git.kernel.org/stable/c/74bc813d11c30e28fc5261dc877cca662ccfac68
- https://git.kernel.org/stable/c/78297d53d3878d43c1d627d20cd09f611fa4b91d
- https://git.kernel.org/stable/c/b0b6bf90ce2699a574b3683e22c44d0dcdd7a057
- https://git.kernel.org/stable/c/b968ba8bfd9f90914957bbbd815413bf6a98eca7
- https://git.kernel.org/stable/c/d66adabe91803ef34a8b90613c81267b5ded1472
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38214
In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/05f6e183879d9785a3cdf2f08a498bc31b7a20aa
- https://git.kernel.org/stable/c/1a10d91766eb6ddfd5414e4785611e33a4fe0f9b
- https://git.kernel.org/stable/c/3ca78032a388a0795201792b36e6fc9b6e6e8eed
- https://git.kernel.org/stable/c/8a3a2887794b2c8e78b3e5d6e3de724527c9f41b
- https://git.kernel.org/stable/c/b3071bb463ea1e6c686d0dc9638fc940f2f5cf17
- https://git.kernel.org/stable/c/ee20216f12d9482cd70e44dae5e7fabb38367c71
- https://git.kernel.org/stable/c/fab201d72fde38d081e2c5d4ad25595c535b7b22
- https://git.kernel.org/stable/c/ff0e037241173b574b385bff53d67567b9816db5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38215
In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in do_register_framebuffer() fails to allocate memory for fb_videomode, it will later lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ Even though fbcon_init() checks beforehand if fb_match_mode() in var_to_display() fails, it can not prevent the panic because fbcon_init() does not return error code. Considering this and the comment in the code about fb_match_mode() returning NULL - "This should not happen" - it is better to prevent registering the fb_info if its mode was not set successfully. Also move fb_add_videomode() closer to the beginning of do_register_framebuffer() to avoid having to do the cleanup on fail. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/0909b2b49c4546a7a08c80f53d93736b63270827
- https://git.kernel.org/stable/c/17186f1f90d34fa701e4f14e6818305151637b9e
- https://git.kernel.org/stable/c/3f2098f4fba7718eb2501207ca6e99d22427f25a
- https://git.kernel.org/stable/c/908c5bb64f9c4319902b8ca1aa3fef8f83302520
- https://git.kernel.org/stable/c/d803c4c2a4ac8ce2be6d899d5c7ab0bf7ec355e9
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38216
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Restore context entry setup order for aliased devices Commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain") changed the context entry setup during domain attachment from a set-and-check policy to a clear-and-reset approach. This inadvertently introduced a regression affecting PCI aliased devices behind PCIe-to-PCI bridges. Specifically, keyboard and touchpad stopped working on several Apple Macbooks with below messages: kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 Fix this by restoring the previous context setup order.
Modified: 2025-11-18
CVE-2025-38217
In the Linux kernel, the following vulnerability has been resolved: hwmon: (ftsteutates) Fix TOCTOU race in fts_read() In the fts_read() function, when handling hwmon_pwm_auto_channels_temp, the code accesses the shared variable data->fan_source[channel] twice without holding any locks. It is first checked against FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again when used as an argument to the BIT() macro. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Another thread executing fts_update_device() can modify the value of data->fan_source[channel] between the check and its use. If the value is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the BIT() macro will be called with a large shift value (BIT(255)). A bit shift by a value greater than or equal to the type width is undefined behavior and can lead to a crash or incorrect values being returned to userspace. Fix this by reading data->fan_source[channel] into a local variable once, eliminating the race condition. Additionally, add a bounds check to ensure the value is less than BITS_PER_LONG before passing it to the BIT() macro, making the code more robust against undefined behavior. This possible bug was found by an experimental static analysis tool developed by our team.
Modified: 2025-12-18
CVE-2025-38218
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sit_bitmap_size w/ below testcase, resize will generate a corrupted image which contains inconsistent metadata, so when mounting such image, it will trigger kernel panic: touch img truncate -s $((512*1024*1024*1024)) img mkfs.f2fs -f img $((256*1024*1024)) resize.f2fs -s -i img -t $((1024*1024*1024)) mount img /mnt/f2fs ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.h:863! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490 Call Trace: f2fs_build_segment_manager+0x11c3/0x2600 f2fs_fill_super+0xe97/0x2840 mount_bdev+0xf4/0x140 legacy_get_tree+0x2b/0x50 vfs_get_tree+0x29/0xd0 path_mount+0x487/0xaf0 __x64_sys_mount+0x116/0x150 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdbfde1bcfe The reaseon is: sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt is 4762, build_sit_entries() -> current_sit_addr() tries to access out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on(). Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic.
- https://git.kernel.org/stable/c/38ef48a8afef8df646b6f6ae7abb872f18b533c1
- https://git.kernel.org/stable/c/3e5ac62a56a24f4d88ce8ffd7bc452428b235868
- https://git.kernel.org/stable/c/5db0d252c64e91ba1929c70112352e85dc5751e7
- https://git.kernel.org/stable/c/79ef8a6c4ec53d327580fd7d2b522cf4f1d05b0c
- https://git.kernel.org/stable/c/82f51bff393e4c12cf4de553120ca831cfa4ef19
- https://git.kernel.org/stable/c/ad862f71016ba38039df1c96ed55c0a4314cc183
- https://git.kernel.org/stable/c/ee1b421c469876544e297ec1090574bd76100247
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38219
In the Linux kernel, the following vulnerability has been resolved:
f2fs: prevent kernel warning due to negative i_nlink from corrupted image
WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0
home/cc/linux/fs/inode.c:417
Modules linked in:
CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted
6.14.0-12627-g94d471a4f428 #2 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417
Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff
f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90
<0f> 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6
ff
RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f
RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005
RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000
R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0
FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0
Call Trace:
- https://git.kernel.org/stable/c/1f6332872374b7f482fc4ad865f9422fedb587fc
- https://git.kernel.org/stable/c/42cb74a92adaf88061039601ddf7c874f58b554e
- https://git.kernel.org/stable/c/5018d035530b6fbfad33eeb1dd1bc87da419a276
- https://git.kernel.org/stable/c/a87cbcc909ccfd394d4936a94663f586453d0961
- https://git.kernel.org/stable/c/aaa644e7ffff02e12c89cbce4753bc0b6f23ff87
- https://git.kernel.org/stable/c/d14cbed4baccd712447fb3f9c011f008b56b2097
- https://git.kernel.org/stable/c/d9a55869d8237e677ddaa18b0f58586364cfbc1c
- https://git.kernel.org/stable/c/fbfe8446cd3274b9e367f5708d94574230a44409
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38220
In the Linux kernel, the following vulnerability has been resolved:
ext4: only dirty folios when data journaling regular files
fstest generic/388 occasionally reproduces a crash that looks as
follows:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
Modified: 2025-12-18
CVE-2025-38222
In the Linux kernel, the following vulnerability has been resolved:
ext4: inline: fix len overflow in ext4_prepare_inline_data
When running the following code on an ext4 filesystem with inline_data
feature enabled, it will lead to the bug below.
fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666);
ftruncate(fd, 30);
pwrite(fd, "a", 1, (1UL << 40) + 5UL);
That happens because write_begin will succeed as when
ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len
will be truncated, leading to ext4_prepare_inline_data parameter to be 6
instead of 0x10000000006.
Then, later when write_end is called, we hit:
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
at ext4_write_inline_data.
Fix it by using a loff_t type for the len parameter in
ext4_prepare_inline_data instead of an unsigned int.
[ 44.545164] ------------[ cut here ]------------
[ 44.545530] kernel BUG at fs/ext4/inline.c:240!
[ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb
[ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100
[ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49
[ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216
[ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006
[ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738
[ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000
[ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738
[ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000
[ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0
[ 44.546523] PKRU: 55555554
[ 44.546523] Call Trace:
[ 44.546523]
- https://git.kernel.org/stable/c/227cb4ca5a6502164f850d22aec3104d7888b270
- https://git.kernel.org/stable/c/26e09d18599da0adc543eabd300080daaeda6869
- https://git.kernel.org/stable/c/5766da2237e539f259aa0e5f3639ae37b44ca458
- https://git.kernel.org/stable/c/717414a8c083c376d4a8940a1230fe0c6ed4ee00
- https://git.kernel.org/stable/c/9d1d1c5bf4fc1af76be154d3afb2acdbd89ec7d8
- https://git.kernel.org/stable/c/cf5f319a2d8ab8238f8cf3a19463b9bff6420934
- https://git.kernel.org/stable/c/d3dfc60efd145df5324b99a244b0b05505cde29b
- https://git.kernel.org/stable/c/e80ee0263d88d77f2fd1927f915003a7066cbb50
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38223
In the Linux kernel, the following vulnerability has been resolved:
ceph: avoid kernel BUG for encrypted inode with unaligned file size
The generic/397 test hits a BUG_ON for the case of encrypted inode with
unaligned file size (for example, 33K or 1K):
[ 877.737811] run fstests generic/397 at 2025-01-03 12:34:40
[ 877.875761] libceph: mon0 (2)127.0.0.1:40674 session established
[ 877.876130] libceph: client4614 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
[ 877.991965] libceph: mon0 (2)127.0.0.1:40674 session established
[ 877.992334] libceph: client4617 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
[ 878.017234] libceph: mon0 (2)127.0.0.1:40674 session established
[ 878.017594] libceph: client4620 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
[ 878.031394] xfs_io (pid 18988) is setting deprecated v1 encryption policy; recommend upgrading to v2.
[ 878.054528] libceph: mon0 (2)127.0.0.1:40674 session established
[ 878.054892] libceph: client4623 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
[ 878.070287] libceph: mon0 (2)127.0.0.1:40674 session established
[ 878.070704] libceph: client4626 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
[ 878.264586] libceph: mon0 (2)127.0.0.1:40674 session established
[ 878.265258] libceph: client4629 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949
[ 878.374578] -----------[ cut here ]------------
[ 878.374586] kernel BUG at net/ceph/messenger.c:1070!
[ 878.375150] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 878.378145] CPU: 2 UID: 0 PID: 4759 Comm: kworker/2:9 Not tainted 6.13.0-rc5+ #1
[ 878.378969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 878.380167] Workqueue: ceph-msgr ceph_con_workfn
[ 878.381639] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50
[ 878.382152] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
[ 878.383928] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287
[ 878.384447] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000
[ 878.385129] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378
[ 878.385839] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000
[ 878.386539] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030
[ 878.387203] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001
[ 878.387877] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000
[ 878.388663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 878.389212] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0
[ 878.389921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 878.390620] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 878.391307] PKRU: 55555554
[ 878.391567] Call Trace:
[ 878.391807]
Modified: 2025-12-18
CVE-2025-38225
In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Cleanup after an allocation error When allocation failures are not cleaned up by the driver, further allocation errors will be false-positives, which will cause buffers to remain uninitialized and cause NULL pointer dereferences. Ensure proper cleanup of failed allocations to prevent these issues.
- https://git.kernel.org/stable/c/0ee9469f818a0b4de3c0e7aecd733c103820d181
- https://git.kernel.org/stable/c/6d0efe7d35c75394f32ff9d0650a007642d23857
- https://git.kernel.org/stable/c/7500bb9cf164edbb2c8117d57620227b1a4a8369
- https://git.kernel.org/stable/c/b89ff9cf37ff59399f850d5f7781ef78fc37679f
- https://git.kernel.org/stable/c/ec26be7d6355a05552a0d0c1e73031f83aa4dc7f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38226
In the Linux kernel, the following vulnerability has been resolved:
media: vivid: Change the siize of the composing
syzkaller found a bug:
BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]
BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705
Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304
CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/00da1c767a6567e56f23dda586847586868ac064
- https://git.kernel.org/stable/c/57597d8db5bbda618ba2145b7e8a7e6f01b6a27e
- https://git.kernel.org/stable/c/5d89aa42534723400fefd46e26e053b9c382b4ee
- https://git.kernel.org/stable/c/635cea4f44c1ddae208666772c164eab5a6bce39
- https://git.kernel.org/stable/c/89b5ab822bf69867c3951dd0eb34b0314c38966b
- https://git.kernel.org/stable/c/c56398885716d97ee9bcadb2bc9663a8c1757a34
- https://git.kernel.org/stable/c/f6b1b0f8ba0b61d8b511df5649d57235f230c135
- https://git.kernel.org/stable/c/f83ac8d30c43fd902af7c84c480f216157b60ef0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38227
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: Terminating the subsequent process of initialization failure
syzbot reported a slab-use-after-free Read in vidtv_mux_init. [1]
After PSI initialization fails, the si member is accessed again, resulting
in this uaf.
After si initialization fails, the subsequent process needs to be exited.
[1]
BUG: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline]
BUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524
Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059
CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0
Hardware name: Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
- https://git.kernel.org/stable/c/1d5f88f053480326873115092bc116b7d14916ba
- https://git.kernel.org/stable/c/685c18bc5a36f823ee725e85aac1303ef5f535ba
- https://git.kernel.org/stable/c/72541cae73d0809a6416bfcd2ee6473046a0013a
- https://git.kernel.org/stable/c/7e62be1f3b241bc9faee547864bb39332955509b
- https://git.kernel.org/stable/c/9824e1732a163e005aa84e12ec439493ebd4f097
- https://git.kernel.org/stable/c/e1d72ff111eceea6b28dccb7ca4e8f4900b11729
- https://git.kernel.org/stable/c/f8c2483be6e8bb6c2148315b4a924c65bb442b5e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38228
In the Linux kernel, the following vulnerability has been resolved: media: imagination: fix a potential memory leak in e5010_probe() Add video_device_release() to release the memory allocated by video_device_alloc() if something goes wrong.
Modified: 2025-12-18
CVE-2025-38229
In the Linux kernel, the following vulnerability has been resolved: media: cxusb: no longer judge rbuf when the write fails syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
- https://git.kernel.org/stable/c/04354c529c8246a38ae28f713fd6bfdc028113bc
- https://git.kernel.org/stable/c/390b864e3281802109dfe56e508396683e125653
- https://git.kernel.org/stable/c/41807a5f67420464ac8ee7741504f6b5decb3b7c
- https://git.kernel.org/stable/c/73fb3b92da84637e3817580fa205d48065924e15
- https://git.kernel.org/stable/c/77829a5f5a74026b888b0529628475b29750cef4
- https://git.kernel.org/stable/c/84eca597baa346f09b30accdaeca10ced3eeba2d
- https://git.kernel.org/stable/c/8b35b50b7e98d8e9a0a27257c8424448afae10de
- https://git.kernel.org/stable/c/9bff888c92f5c25effbb876d22a793c2388c1ccc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38230
In the Linux kernel, the following vulnerability has been resolved:
jfs: validate AG parameters in dbMount() to prevent crashes
Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch
corrupted metadata early and avoid undefined behavior in dbAllocAG.
Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:
- agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift
(L2LPERCTL - 2*agheight) >= 0.
- agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight))
ensures agperlev >= 1.
- Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5).
- LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG;
2^(10 - 2*agheight) prevents division to 0.
- agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within
stree (size 1365).
- Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9
shift exponent -335544310 is negative
CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
- https://git.kernel.org/stable/c/0c40fa81f850556e9aa0185fede9ef1112db7b39
- https://git.kernel.org/stable/c/37bfb464ddca87f203071b5bd562cd91ddc0b40a
- https://git.kernel.org/stable/c/8b69608c6b6779a7ab07ce4467a56df90152cfb9
- https://git.kernel.org/stable/c/9242ff6245527a3ebb693ddd175493b38ddca72f
- https://git.kernel.org/stable/c/95ae5ee6069d9a5945772625f289422ef659221a
- https://git.kernel.org/stable/c/a4259e72363e1ea204a97292001a9fc36c7e52fd
- https://git.kernel.org/stable/c/b62a1e59d8716bbd2e73660743fe06acc97ed7d1
- https://git.kernel.org/stable/c/c3705c82b7406a15ef38a610d03bf6baa43d6e0c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38231
In the Linux kernel, the following vulnerability has been resolved: nfsd: Initialize ssc before laundromat_work to prevent NULL dereference In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through nfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized, this can cause NULL pointer dereference. Normally the delayed start of laundromat_work allows sufficient time for nfsd_ssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4_state_start_net -> nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done -> cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), the delayed work may start before nfsd_ssc initialization finishes. Fix this by moving nfsd_ssc initialization before starting laundromat_work.
- https://git.kernel.org/stable/c/0fccf5f01ed28725cc313a66ca1247eef911d55e
- https://git.kernel.org/stable/c/5060e1a5fef184bd11d298e3f0ee920d96a23236
- https://git.kernel.org/stable/c/83ac1ba8ca102ab5c0ed4351f8ac6e74ac4d5d64
- https://git.kernel.org/stable/c/a97668ec6d73dab237cd1c15efe012a10090a4ed
- https://git.kernel.org/stable/c/b31da62889e6d610114d81dc7a6edbcaa503fcf8
- https://git.kernel.org/stable/c/d622c2ee6c08147ab8c9b9e37d93b6e95d3258e0
- https://git.kernel.org/stable/c/deaeb74ae9318252829c59a84a7d2316fc335660
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38232
In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.
- https://git.kernel.org/stable/c/2029ca75cdfa6a25716a5a76b751486cce7e3822
- https://git.kernel.org/stable/c/327011a2bb4f7de9c72b891a96ce8d902828bddf
- https://git.kernel.org/stable/c/49b57b98fa601ae6cc7897bab4515129da8290f7
- https://git.kernel.org/stable/c/8120e420013d947c890f358f30a2d98ba8ac20bc
- https://git.kernel.org/stable/c/88d6785c173a7c4de05bef8c4fd8a9b42ead02d5
- https://git.kernel.org/stable/c/f7fb730cac9aafda8b9813b55d04e28a9664d17c
Modified: 2025-12-18
CVE-2025-38236
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Don't leave consecutive consumed OOB skbs.
Jann Horn reported a use-after-free in unix_stream_read_generic().
The following sequences reproduce the issue:
$ python3
from socket import *
s1, s2 = socketpair(AF_UNIX, SOCK_STREAM)
s1.send(b'x', MSG_OOB)
s2.recv(1, MSG_OOB) # leave a consumed OOB skb
s1.send(b'y', MSG_OOB)
s2.recv(1, MSG_OOB) # leave a consumed OOB skb
s1.send(b'z', MSG_OOB)
s2.recv(1) # recv 'z' illegally
s2.recv(1, MSG_OOB) # access 'z' skb (use-after-free)
Even though a user reads OOB data, the skb holding the data stays on
the recv queue to mark the OOB boundary and break the next recv().
After the last send() in the scenario above, the sk2's recv queue has
2 leading consumed OOB skbs and 1 real OOB skb.
Then, the following happens during the next recv() without MSG_OOB
1. unix_stream_read_generic() peeks the first consumed OOB skb
2. manage_oob() returns the next consumed OOB skb
3. unix_stream_read_generic() fetches the next not-yet-consumed OOB skb
4. unix_stream_read_generic() reads and frees the OOB skb
, and the last recv(MSG_OOB) triggers KASAN splat.
The 3. above occurs because of the SO_PEEK_OFF code, which does not
expect unix_skb_len(skb) to be 0, but this is true for such consumed
OOB skbs.
while (skip >= unix_skb_len(skb)) {
skip -= unix_skb_len(skb);
skb = skb_peek_next(skb, &sk->sk_receive_queue);
...
}
In addition to this use-after-free, there is another issue that
ioctl(SIOCATMARK) does not function properly with consecutive consumed
OOB skbs.
So, nothing good comes out of such a situation.
Instead of complicating manage_oob(), ioctl() handling, and the next
ECONNRESET fix by introducing a loop for consecutive consumed OOB skbs,
let's not leave such consecutive OOB unnecessarily.
Now, while receiving an OOB skb in unix_stream_recv_urg(), if its
previous skb is a consumed OOB skb, it is freed.
[0]:
BUG: KASAN: slab-use-after-free in unix_stream_read_actor (net/unix/af_unix.c:3027)
Read of size 4 at addr ffff888106ef2904 by task python3/315
CPU: 2 UID: 0 PID: 315 Comm: python3 Not tainted 6.16.0-rc1-00407-gec315832f6f9 #8 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/32ca245464e1479bfea8592b9db227fdc1641705
- https://git.kernel.org/stable/c/523edfed4f68b7794d85b9ac828c5f8f4442e4c5
- https://git.kernel.org/stable/c/61a9ad7b69ce688697e5f63332f03e17725353bc
- https://git.kernel.org/stable/c/8db4d2d026e6e3649832bfe23b96c4acff0756db
- https://git.kernel.org/stable/c/a12237865b48a73183df252029ff5065d73d305e
- https://git.kernel.org/stable/c/fad0a2c16062ac7c606b93166a7ce9d265bab976
- https://project-zero.issues.chromium.org/issues/423023990
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38239
In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly.
- https://git.kernel.org/stable/c/074efb35552556a4b3b25eedab076d5dc24a8199
- https://git.kernel.org/stable/c/19a47c966deb36624843b7301f0373a3dc541a05
- https://git.kernel.org/stable/c/752eb816b55adb0673727ba0ed96609a17895654
- https://git.kernel.org/stable/c/bf2c1643abc3b2507d56bb6c22bf9897272f8a35
- https://git.kernel.org/stable/c/f1064b3532192e987ab17be7281d5fee36fd25e1
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38242
In the Linux kernel, the following vulnerability has been resolved:
mm: userfaultfd: fix race of userfaultfd_move and swap cache
This commit fixes two kinds of races, they may have different results:
Barry reported a BUG_ON in commit c50f8e6053b0, we may see the same
BUG_ON if the filemap lookup returned NULL and folio is added to swap
cache after that.
If another kind of race is triggered (folio changed after lookup) we
may see RSS counter is corrupted:
[ 406.893936] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0
type:MM_ANONPAGES val:-1
[ 406.894071] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0
type:MM_SHMEMPAGES val:1
Because the folio is being accounted to the wrong VMA.
I'm not sure if there will be any data corruption though, seems no.
The issues above are critical already.
On seeing a swap entry PTE, userfaultfd_move does a lockless swap cache
lookup, and tries to move the found folio to the faulting vma. Currently,
it relies on checking the PTE value to ensure that the moved folio still
belongs to the src swap entry and that no new folio has been added to the
swap cache, which turns out to be unreliable.
While working and reviewing the swap table series with Barry, following
existing races are observed and reproduced [1]:
In the example below, move_pages_pte is moving src_pte to dst_pte, where
src_pte is a swap entry PTE holding swap entry S1, and S1 is not in the
swap cache:
CPU1 CPU2
userfaultfd_move
move_pages_pte()
entry = pte_to_swp_entry(orig_src_pte);
// Here it got entry = S1
... < interrupted> ...
Modified: 2025-11-20
CVE-2025-38244
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when reconnecting channels Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W ------------------------------------------------------ cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200 but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK *** 3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
Modified: 2025-12-18
CVE-2025-38245
In the Linux kernel, the following vulnerability has been resolved:
atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().
syzbot reported a warning below during atm_dev_register(). [0]
Before creating a new device and procfs/sysfs for it, atm_dev_register()
looks up a duplicated device by __atm_dev_lookup(). These operations are
done under atm_dev_mutex.
However, when removing a device in atm_dev_deregister(), it releases the
mutex just after removing the device from the list that __atm_dev_lookup()
iterates over.
So, there will be a small race window where the device does not exist on
the device list but procfs/sysfs are still not removed, triggering the
splat.
Let's hold the mutex until procfs/sysfs are removed in
atm_dev_deregister().
[0]:
proc_dir_entry 'atm/atmtcp:0' already registered
WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377
Modules linked in:
CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377
Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48
RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248
RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001
RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140
R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444
FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/26248d5d68c865b888d632162abbf8130645622c
- https://git.kernel.org/stable/c/2a8dcee649d12f69713f2589171a1caf6d4fa439
- https://git.kernel.org/stable/c/4bb1bb438134d9ee6b97cc07289dd7c569092eec
- https://git.kernel.org/stable/c/6922f1a048c090f10704bbef4a3a1e81932d2e0a
- https://git.kernel.org/stable/c/a433791aeaea6e84df709e0b9584b9bbe040cd1c
- https://git.kernel.org/stable/c/ae539d963a17443ec54cba8a767e4ffa318264f4
- https://git.kernel.org/stable/c/b2e40fcfe1575faaa548f87614006d3fe44c779e
- https://git.kernel.org/stable/c/cabed6ba92a9a8c09da02a3f20e32ecd80989896
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-20
CVE-2025-38246
In the Linux kernel, the following vulnerability has been resolved:
bnxt: properly flush XDP redirect lists
We encountered following crash when testing a XDP_REDIRECT feature
in production:
[56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd
40f30).
[56251.601413] ------------[ cut here ]------------
[56251.611357] kernel BUG at lib/list_debug.c:29!
[56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6.
3 #1
[56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
[56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025
[56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0
[56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48
89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89
[56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246
[56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000
[56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80
[56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18
[56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000
[56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40
[56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000
[56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0
[56251.831365] PKRU: 55555554
[56251.838653] Call Trace:
[56251.845560]
Modified: 2025-12-18
CVE-2025-38249
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() In snd_usb_get_audioformat_uac3(), the length value returned from snd_usb_ctl_msg() is used directly for memory allocation without validation. This length is controlled by the USB device. The allocated buffer is cast to a uac3_cluster_header_descriptor and its fields are accessed without verifying that the buffer is large enough. If the device returns a smaller than expected length, this leads to an out-of-bounds read. Add a length check to ensure the buffer is large enough for uac3_cluster_header_descriptor.
- https://git.kernel.org/stable/c/0ee87c2814deb5e42921281116ac3abcb326880b
- https://git.kernel.org/stable/c/11e740dc1a2c8590eb7074b5c4ab921bb6224c36
- https://git.kernel.org/stable/c/24ff7d465c4284529bbfa207757bffb6f44b6403
- https://git.kernel.org/stable/c/2dc1c3edf67abd30c757f8054a5da61927cdda21
- https://git.kernel.org/stable/c/6eb211788e1370af52a245d4d7da35c374c7b401
- https://git.kernel.org/stable/c/74fcb3852a2f579151ce80b9ed96cd916ba0d5d8
- https://git.kernel.org/stable/c/c3fb926abe90d86f5e3055e0035f04d9892a118b
- https://git.kernel.org/stable/c/fb4e2a6e8f28a3c0ad382e363aeb9cd822007b8a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-25
CVE-2025-38250
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix use-after-free in vhci_flush()
syzbot reported use-after-free in vhci_flush() without repro. [0]
From the splat, a thread close()d a vhci file descriptor while
its device was being used by iotcl() on another thread.
Once the last fd refcnt is released, vhci_release() calls
hci_unregister_dev(), hci_free_dev(), and kfree() for struct
vhci_data, which is set to hci_dev->dev->driver_data.
The problem is that there is no synchronisation after unlinking
hdev from hci_dev_list in hci_unregister_dev(). There might be
another thread still accessing the hdev which was fetched before
the unlink operation.
We can use SRCU for such synchronisation.
Let's run hci_dev_reset() under SRCU and wait for its completion
in hci_unregister_dev().
Another option would be to restore hci_dev->destruct(), which was
removed in commit 587ae086f6e4 ("Bluetooth: Remove unused
hci-destruct cb"). However, this would not be a good solution, as
we should not run hci_unregister_dev() while there are in-flight
ioctl() requests, which could lead to another data-race KCSAN splat.
Note that other drivers seem to have the same problem, for exmaple,
virtbt_remove().
[0]:
BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718
CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
- https://git.kernel.org/stable/c/0e5c144c557df910ab64d9c25d06399a9a735e65
- https://git.kernel.org/stable/c/1d6123102e9fbedc8d25bf4731da6d513173e49e
- https://git.kernel.org/stable/c/bc0819a25e04cd68ef3568cfa51b63118fea39a7
- https://git.kernel.org/stable/c/c56b177efce8b62798e4d96bdb9867106cb7c4a0
- https://git.kernel.org/stable/c/ce23b73f0f27e2dbeb81734a79db710f05aa33c6
Modified: 2025-12-18
CVE-2025-38251
In the Linux kernel, the following vulnerability has been resolved: atm: clip: prevent NULL deref in clip_push() Blamed commit missed that vcc_destroy_socket() calls clip_push() with a NULL skb. If clip_devs is NULL, clip_push() then crashes when reading skb->truesize.
- https://git.kernel.org/stable/c/3c709dce16999bf6a1d2ce377deb5dd6fdd8cb08
- https://git.kernel.org/stable/c/41f6420ee845006354c004839fed07da71e34aee
- https://git.kernel.org/stable/c/88c88f91f4b3563956bb52e7a71a3640f7ece157
- https://git.kernel.org/stable/c/9199e8cb75f13a1650adcb3c6cad42789c43884e
- https://git.kernel.org/stable/c/a07005a77b18ae59b8471e7e4d991fa9f642b3c2
- https://git.kernel.org/stable/c/b993ea46b3b601915ceaaf3c802adf11e7d6bac6
- https://git.kernel.org/stable/c/ede31ad949ae0d03cb4c5edd79991586ad7c8bb8
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38253
In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix crash in wacom_aes_battery_handler() Commit fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended inactivity") introduced wacom_aes_battery_handler() which is scheduled as a delayed work (aes_battery_work). In wacom_remove(), aes_battery_work is not canceled. Consequently, if the device is removed while aes_battery_work is still pending, then hard crashes or "Oops: general protection fault..." are experienced when wacom_aes_battery_handler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aes_battery_work was still pending at the time of hibernation. So, take care to cancel aes_battery_work in wacom_remove().
Modified: 2025-11-19
CVE-2025-38255
In the Linux kernel, the following vulnerability has been resolved:
lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()
While testing null_blk with configfs, echo 0 > poll_queues will trigger
following panic:
BUG: kernel NULL pointer dereference, address: 0000000000000010
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
RIP: 0010:__bitmap_or+0x48/0x70
Call Trace:
Modified: 2025-11-19
CVE-2025-38256
In the Linux kernel, the following vulnerability has been resolved: io_uring/rsrc: fix folio unpinning syzbot complains about an unmapping failure: [ 108.070381][ T14] kernel BUG at mm/gup.c:71! [ 108.070502][ T14] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025 [ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work [ 108.174205][ T14] Call trace: [ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P) [ 108.178138][ T14] unpin_user_page+0x80/0x10c [ 108.180189][ T14] io_release_ubuf+0x84/0xf8 [ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c [ 108.184345][ T14] io_rsrc_data_free+0x148/0x298 [ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0 [ 108.188991][ T14] io_ring_ctx_free+0x48/0x480 [ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8 [ 108.193207][ T14] process_one_work+0x7e8/0x155c [ 108.195431][ T14] worker_thread+0x958/0xed8 [ 108.197561][ T14] kthread+0x5fc/0x75c [ 108.199362][ T14] ret_from_fork+0x10/0x20 We can pin a tail page of a folio, but then io_uring will try to unpin the head page of the folio. While it should be fine in terms of keeping the page actually alive, mm folks say it's wrong and triggers a debug warning. Use unpin_user_folio() instead of unpin_user_page*. [axboe: adapt to current tree, massage commit message]
Modified: 2025-12-18
CVE-2025-38257
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Prevent overflow in size calculation for memdup_user() Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow. In this case the actual size of the allocated area and the value describing it won't be in sync leading to various types of unpredictable behaviour later. Use a proper memdup_array_user() helper which returns an error if an overflow is detected. Note that it is different from when nr_apqns is initially zero - that case is considered valid and should be handled in subsequent pkey_handler implementations. Found by Linux Verification Center (linuxtesting.org).
- https://git.kernel.org/stable/c/73483ca7e07a5e39bdf612eec9d3d293e8bef649
- https://git.kernel.org/stable/c/7360ee47599af91a1d5f4e74d635d9408a54e489
- https://git.kernel.org/stable/c/88f3869649edbc4a13f6c2877091f81cd5a50f05
- https://git.kernel.org/stable/c/ad1bdd24a02d5a8d119af8e4cd50933780a6d29f
- https://git.kernel.org/stable/c/f855b119e62b004a5044ed565f2a2b368c4d3f16
- https://git.kernel.org/stable/c/faa1ab4a23c42e34dc000ef4977b751d94d5148c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38258
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write memcg_path_store() assigns a newly allocated memory buffer to filter->memcg_path, without deallocating the previously allocated and assigned memory buffer. As a result, users can leak kernel memory by continuously writing a data to memcg_path DAMOS sysfs file. Fix the leak by deallocating the previously set memory buffer.
Modified: 2025-12-18
CVE-2025-38259
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code.
- https://git.kernel.org/stable/c/9079db287fc3e38e040b0edeb0a25770bb679c8e
- https://git.kernel.org/stable/c/9830ef1803a5bc50b4a984a06cf23142cd46229d
- https://git.kernel.org/stable/c/a8795f3cd289cd958f6396a1b43ba46fa8e22a2e
- https://git.kernel.org/stable/c/b86280aaa23c1c0f31bcaa600d35ddc45bc38b7a
- https://git.kernel.org/stable/c/edadaf4239c14dc8a19ea7f60b97d5524d93c29b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38260
In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle csum tree error with rescue=ibadroots correctly
[BUG]
There is syzbot based reproducer that can crash the kernel, with the
following call trace: (With some debug output added)
DEBUG: rescue=ibadroots parsed
BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010)
BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8
BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm
BTRFS info (device loop0): using free-space-tree
BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0
DEBUG: read tree root path failed for tree csum, ret=-5
BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0
BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0
process 'repro' launched './file2' with NULL argv: empty string added
DEBUG: no csum root, idatacsums=0 ibadroots=134217728
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs]
Call Trace:
- https://git.kernel.org/stable/c/3f5c4a996f8f4fecd24a3eb344a307c50af895c2
- https://git.kernel.org/stable/c/547e836661554dcfa15c212a3821664e85b4191a
- https://git.kernel.org/stable/c/bbe9231fe611a54a447962494472f604419bad59
- https://git.kernel.org/stable/c/f8ce11903211542a61f05c02caedd2edfb4256b8
- https://git.kernel.org/stable/c/fc97a116dc4929905538bc0bd3af7faa51192957
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38262
In the Linux kernel, the following vulnerability has been resolved: tty: serial: uartlite: register uart driver in init When two instances of uart devices are probing, a concurrency race can occur. If one thread calls uart_register_driver function, which first allocates and assigns memory to 'uart_state' member of uart_driver structure, the other instance can bypass uart driver registration and call ulite_assign. This calls uart_add_one_port, which expects the uart driver to be fully initialized. This leads to a kernel panic due to a null pointer dereference: [ 8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8 [ 8.156982] #PF: supervisor write access in kernel mode [ 8.156984] #PF: error_code(0x0002) - not-present page [ 8.156986] PGD 0 P4D 0 ... [ 8.180668] RIP: 0010:mutex_lock+0x19/0x30 [ 8.188624] Call Trace: [ 8.188629] ? __die_body.cold+0x1a/0x1f [ 8.195260] ? page_fault_oops+0x15c/0x290 [ 8.209183] ? __irq_resolve_mapping+0x47/0x80 [ 8.209187] ? exc_page_fault+0x64/0x140 [ 8.209190] ? asm_exc_page_fault+0x22/0x30 [ 8.209196] ? mutex_lock+0x19/0x30 [ 8.223116] uart_add_one_port+0x60/0x440 [ 8.223122] ? proc_tty_register_driver+0x43/0x50 [ 8.223126] ? tty_register_driver+0x1ca/0x1e0 [ 8.246250] ulite_probe+0x357/0x4b0 [uartlite] To prevent it, move uart driver registration in to init function. This will ensure that uart_driver is always registered when probe function is called.
- https://git.kernel.org/stable/c/5015eed450005bab6e5cb6810f7a62eab0434fc4
- https://git.kernel.org/stable/c/685d29f2c5057b32c7b1b46f2a7d303b926c8f72
- https://git.kernel.org/stable/c/6bd697b5fc39fd24e2aa418c7b7d14469f550a93
- https://git.kernel.org/stable/c/6db06aaea07bb7c8e33a425cf7b98bf29ee6056e
- https://git.kernel.org/stable/c/8e958d10dd0ce5ae674cce460db5c9ca3f25243b
- https://git.kernel.org/stable/c/9c905fdbba68a6d73d39a6b7de9b9f0d6c46df87
- https://git.kernel.org/stable/c/f5e4229d94792b40e750f30c92bcf7a3107c72ef
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38263
In the Linux kernel, the following vulnerability has been resolved: bcache: fix NULL pointer in cache_set_flush() 1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc(). 2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set(). 3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 } (1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885). (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return. (3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL. LINE#1624 - LINE#1665 is some codes about function of cache_set_flush(). As (1), in LINE#1885 call bch_cache_set_unregister() ---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 } (4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below: [ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory [ 846.713242] bcache: register_bcache() error : failed to register device [ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered [ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8 [ 846.714790] PGD 0 P4D 0 [ 846.715129] Oops: 0000 [#1] SMP PTI [ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1 [ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018 [ 846.716451] Workqueue: events cache_set_flush [bcache] [ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache] [ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0 ---truncated---
- https://git.kernel.org/stable/c/1e46ed947ec658f89f1a910d880cd05e42d3763e
- https://git.kernel.org/stable/c/1f25f2d3fa29325320c19a30abf787e0bd5fc91b
- https://git.kernel.org/stable/c/3f9e128186c99a117e304f1dce6d0b9e50c63cd8
- https://git.kernel.org/stable/c/553f560e0a74a7008ad9dba05c3fd05da296befb
- https://git.kernel.org/stable/c/667c3f52373ff5354cb3543e27237eb7df7b2333
- https://git.kernel.org/stable/c/c4f5e7e417034b05f5d2f5fa9a872db897da69bd
- https://git.kernel.org/stable/c/d54681938b777488e5dfb781b566d16adad991de
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38264
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: sanitize request list handling Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing.
Modified: 2025-11-18
CVE-2025-38265
In the Linux kernel, the following vulnerability has been resolved:
serial: jsm: fix NPE during jsm_uart_port_init
No device was set which caused serial_base_ctrl_add to crash.
BUG: kernel NULL pointer dereference, address: 0000000000000050
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1 Debian 6.12.25-1
RIP: 0010:serial_base_ctrl_add+0x96/0x120
Call Trace:
- https://git.kernel.org/stable/c/3258d7ff8ebfa451426662b23e8f2b51b129afe1
- https://git.kernel.org/stable/c/985961dd2688a527a4847300d41beaad475ab7af
- https://git.kernel.org/stable/c/a14c0d2eb3f0b1836fdec22908b87ecffd2ac844
- https://git.kernel.org/stable/c/abaecb2a4ad021c2f2426e9b2a9c020aef57aca9
- https://git.kernel.org/stable/c/e3975aa899c0a3bbc10d035e699b142cd1373a71
Modified: 2025-11-18
CVE-2025-38267
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Do not trigger WARN_ON() due to a commit_overrun
When reading a memory mapped buffer the reader page is just swapped out
with the last page written in the write buffer. If the reader page is the
same as the commit buffer (the buffer that is currently being written to)
it was assumed that it should never have missed events. If it does, it
triggers a WARN_ON_ONCE().
But there just happens to be one scenario where this can legitimately
happen. That is on a commit_overrun. A commit overrun is when an interrupt
preempts an event being written to the buffer and then the interrupt adds
so many new events that it fills and wraps the buffer back to the commit.
Any new events would then be dropped and be reported as "missed_events".
In this case, the next page to read is the commit buffer and after the
swap of the reader page, the reader page will be the commit buffer, but
this time there will be missed events and this triggers the following
warning:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1127 at kernel/trace/ring_buffer.c:7357 ring_buffer_map_get_reader+0x49a/0x780
Modules linked in: kvm_intel kvm irqbypass
CPU: 2 UID: 0 PID: 1127 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00004-g478bc2824b45-dirty #564 PREEMPT
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:ring_buffer_map_get_reader+0x49a/0x780
Code: 00 00 00 48 89 fe 48 c1 ee 03 80 3c 2e 00 0f 85 ec 01 00 00 4d 3b a6 a8 00 00 00 0f 85 8a fd ff ff 48 85 c0 0f 84 55 fe ff ff <0f> 0b e9 4e fe ff ff be 08 00 00 00 4c 89 54 24 58 48 89 54 24 50
RSP: 0018:ffff888121787dc0 EFLAGS: 00010002
RAX: 00000000000006a2 RBX: ffff888100062800 RCX: ffffffff8190cb49
RDX: ffff888126934c00 RSI: 1ffff11020200a15 RDI: ffff8881010050a8
RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1024d26982
R10: ffff888126934c17 R11: ffff8881010050a8 R12: ffff888126934c00
R13: ffff8881010050b8 R14: ffff888101005000 R15: ffff888126930008
FS: 00007f95c8cd7540(0000) GS:ffff8882b576e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f95c8de4dc0 CR3: 0000000128452002 CR4: 0000000000172ef0
Call Trace:
Modified: 2025-11-20
CVE-2025-38268
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous work A state check was previously added to tcpm_queue_vdm_unlocked to prevent a deadlock where the DisplayPort Alt Mode driver would be executing work and attempting to grab the tcpm_lock while the TCPM was holding the lock and attempting to unregister the altmode, blocking on the altmode driver's cancel_work_sync call. Because the state check isn't protected, there is a small window where the Alt Mode driver could determine that the TCPM is in a ready state and attempt to grab the lock while the TCPM grabs the lock and changes the TCPM state to one that causes the deadlock. The callstack is provided below: [110121.667392][ C7] Call trace: [110121.667396][ C7] __switch_to+0x174/0x338 [110121.667406][ C7] __schedule+0x608/0x9f0 [110121.667414][ C7] schedule+0x7c/0xe8 [110121.667423][ C7] kernfs_drain+0xb0/0x114 [110121.667431][ C7] __kernfs_remove+0x16c/0x20c [110121.667436][ C7] kernfs_remove_by_name_ns+0x74/0xe8 [110121.667442][ C7] sysfs_remove_group+0x84/0xe8 [110121.667450][ C7] sysfs_remove_groups+0x34/0x58 [110121.667458][ C7] device_remove_groups+0x10/0x20 [110121.667464][ C7] device_release_driver_internal+0x164/0x2e4 [110121.667475][ C7] device_release_driver+0x18/0x28 [110121.667484][ C7] bus_remove_device+0xec/0x118 [110121.667491][ C7] device_del+0x1e8/0x4ac [110121.667498][ C7] device_unregister+0x18/0x38 [110121.667504][ C7] typec_unregister_altmode+0x30/0x44 [110121.667515][ C7] tcpm_reset_port+0xac/0x370 [110121.667523][ C7] tcpm_snk_detach+0x84/0xb8 [110121.667529][ C7] run_state_machine+0x4c0/0x1b68 [110121.667536][ C7] tcpm_state_machine_work+0x94/0xe4 [110121.667544][ C7] kthread_worker_fn+0x10c/0x244 [110121.667552][ C7] kthread+0x104/0x1d4 [110121.667557][ C7] ret_from_fork+0x10/0x20 [110121.667689][ C7] Workqueue: events dp_altmode_work [110121.667697][ C7] Call trace: [110121.667701][ C7] __switch_to+0x174/0x338 [110121.667710][ C7] __schedule+0x608/0x9f0 [110121.667717][ C7] schedule+0x7c/0xe8 [110121.667725][ C7] schedule_preempt_disabled+0x24/0x40 [110121.667733][ C7] __mutex_lock+0x408/0xdac [110121.667741][ C7] __mutex_lock_slowpath+0x14/0x24 [110121.667748][ C7] mutex_lock+0x40/0xec [110121.667757][ C7] tcpm_altmode_enter+0x78/0xb4 [110121.667764][ C7] typec_altmode_enter+0xdc/0x10c [110121.667769][ C7] dp_altmode_work+0x68/0x164 [110121.667775][ C7] process_one_work+0x1e4/0x43c [110121.667783][ C7] worker_thread+0x25c/0x430 [110121.667789][ C7] kthread+0x104/0x1d4 [110121.667794][ C7] ret_from_fork+0x10/0x20 Change tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work, which can perform the state check while holding the TCPM lock while the Alt Mode lock is no longer held. This requires a new struct to hold the vdm data, altmode_vdm_event.
Modified: 2025-11-20
CVE-2025-38269
In the Linux kernel, the following vulnerability has been resolved: btrfs: exit after state insertion failure at btrfs_convert_extent_bit() If insert_state() state failed it returns an error pointer and we call extent_io_tree_panic() which will trigger a BUG() call. However if CONFIG_BUG is disabled, which is an uncommon and exotic scenario, then we fallthrough and call cache_state() which will dereference the error pointer, resulting in an invalid memory access. So jump to the 'out' label after calling extent_io_tree_panic(), it also makes the code more clear besides dealing with the exotic scenario where CONFIG_BUG is disabled.
Modified: 2025-11-20
CVE-2025-38270
In the Linux kernel, the following vulnerability has been resolved: net: drv: netdevsim: don't napi_complete() from netpoll netdevsim supports netpoll. Make sure we don't call napi_complete() from it, since it may not be scheduled. Breno reports hitting a warning in napi_complete_done(): WARNING: CPU: 14 PID: 104 at net/core/dev.c:6592 napi_complete_done+0x2cc/0x560 __napi_poll+0x2d8/0x3a0 handle_softirqs+0x1fe/0x710 This is presumably after netpoll stole the SCHED bit prematurely.
Modified: 2025-11-20
CVE-2025-38274
In the Linux kernel, the following vulnerability has been resolved: fpga: fix potential null pointer deref in fpga_mgr_test_img_load_sgt() fpga_mgr_test_img_load_sgt() allocates memory for sgt using kunit_kzalloc() however it does not check if the allocation failed. It then passes sgt to sg_alloc_table(), which passes it to __sg_alloc_table(). This function calls memset() on sgt in an attempt to zero it out. If the allocation fails then sgt will be NULL and the memset will trigger a NULL pointer dereference. Fix this by checking the allocation with KUNIT_ASSERT_NOT_ERR_OR_NULL().
Modified: 2025-12-18
CVE-2025-38275
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling.
- https://git.kernel.org/stable/c/0b979a409e40457ca1b5cb48755d1f34eee58805
- https://git.kernel.org/stable/c/0c33117f00c8c5363c22676931b22ae5041f7603
- https://git.kernel.org/stable/c/127dfb4f1c5a2b622039c5d203f321380ea36665
- https://git.kernel.org/stable/c/5072c1749197fc28b27d7efc0d80320d7cac9572
- https://git.kernel.org/stable/c/d14402a38c2d868cacb1facaf9be908ca6558e59
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38277
In the Linux kernel, the following vulnerability has been resolved: mtd: nand: ecc-mxic: Fix use of uninitialized variable ret If ctx->steps is zero, the loop processing ECC steps is skipped, and the variable ret remains uninitialized. It is later checked and returned, which leads to undefined behavior and may cause unpredictable results in user space or kernel crashes. This scenario can be triggered in edge cases such as misconfigured geometry, ECC engine misuse, or if ctx->steps is not validated after initialization. Initialize ret to zero before the loop to ensure correct and safe behavior regardless of the ctx->steps value. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/49482f4a39620f6afedcd3f6aa9e0d558b6a460b
- https://git.kernel.org/stable/c/4d9d6e4be09472aa72953caca3dbefdc27846170
- https://git.kernel.org/stable/c/7a23cc510ecaabab4f6df7e9d910d16e279b72ad
- https://git.kernel.org/stable/c/a0d9d9b5a4634e146ae41cb25667322e5c7d74d2
- https://git.kernel.org/stable/c/d95846350aac72303036a70c4cdc69ae314aa26d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38278
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: QOS: Refactor TC_HTB_LEAF_DEL_LAST callback This patch addresses below issues, 1. Active traffic on the leaf node must be stopped before its send queue is reassigned to the parent. This patch resolves the issue by marking the node as 'Inner'. 2. During a system reboot, the interface receives TC_HTB_LEAF_DEL and TC_HTB_LEAF_DEL_LAST callbacks to delete its HTB queues. In the case of TC_HTB_LEAF_DEL_LAST, although the same send queue is reassigned to the parent, the current logic still attempts to update the real number of queues, leadning to below warnings New queues can't be registered after device unregistration. WARNING: CPU: 0 PID: 6475 at net/core/net-sysfs.c:1714 netdev_queue_update_kobjects+0x1e4/0x200
Modified: 2026-03-17
CVE-2025-38279
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do not include stack ptr register in precision backtracking bookkeeping
Yi Lai reported an issue ([1]) where the following warning appears
in kernel dmesg:
[ 60.643604] verifier backtracking bug
[ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10
[ 60.648428] Modules linked in: bpf_testmod(OE)
[ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full)
[ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10
[ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04
01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ...
[ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246
[ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000
[ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff
[ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a
[ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8
[ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001
[ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000
[ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0
[ 60.691623] Call Trace:
[ 60.692821]
Modified: 2025-12-18
CVE-2025-38280
In the Linux kernel, the following vulnerability has been resolved:
bpf: Avoid __bpf_prog_ret0_warn when jit fails
syzkaller reported an issue:
WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Modules linked in:
CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39
RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Call Trace:
- https://git.kernel.org/stable/c/0b9bb52796b239de6792d0d68cdc6eb505ebff96
- https://git.kernel.org/stable/c/2bc6dffb4b72d53d6a6ada510269bf548c3f7ae0
- https://git.kernel.org/stable/c/6f639c25bfad17d9fd7379ab91ff9678ea9aac85
- https://git.kernel.org/stable/c/86bc9c742426a16b52a10ef61f5b721aecca2344
- https://git.kernel.org/stable/c/e7fb4ebee6e900899d2b2e5852c3e2eafcbcad66
- https://git.kernel.org/stable/c/ef92b96530d1731d9ac167bc7c193c683cd78fff
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38282
In the Linux kernel, the following vulnerability has been resolved: kernfs: Relax constraint in draining guard The active reference lifecycle provides the break/unbreak mechanism but the active reference is not truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of kn->active counting. Assuming this mechanism is in place, the WARN check in kernfs_should_drain_open_files() is too sensitive -- it may transiently catch those (rightful) callers between kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen Ridong: kernfs_remove_by_name_ns kernfs_get_active // active=1 __kernfs_remove // active=0x80000002 kernfs_drain ... wait_event //waiting (active == 0x80000001) kernfs_break_active_protection // active = 0x80000001 // continue kernfs_unbreak_active_protection // active = 0x80000002 ... kernfs_should_drain_open_files // warning occurs kernfs_put_active To avoid the false positives (mind panic_on_warn) remove the check altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with larger rework.)
- https://git.kernel.org/stable/c/071d8e4c2a3b0999a9b822e2eb8854784a350f8a
- https://git.kernel.org/stable/c/2d6a67c2b3b87808a347dc1047b520a9dd177a4f
- https://git.kernel.org/stable/c/6bfb154f95d5f0ab7ed056f23aba8c1a94cb3927
- https://git.kernel.org/stable/c/6c81f1c7812c61f187bed1b938f1d2e391d503ab
- https://git.kernel.org/stable/c/72275c888f8962b406ee9c6885c79bf68cca5a63
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38283
In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: bugfix live migration function without VF device driver If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors. Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.
Modified: 2025-12-18
CVE-2025-38285
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861
Modules linked in:
CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861
RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c
RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005
RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003
R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004
R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900
FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/147ea936fc6fa8fe0c93f0df918803a5375ca535
- https://git.kernel.org/stable/c/18e8cbbae79cb35bdce8a01c889827b9799c762e
- https://git.kernel.org/stable/c/3880cdbed1c4607e378f58fa924c5d6df900d1d3
- https://git.kernel.org/stable/c/44ebe361abb322d2afd77930fa767a99f271c4d1
- https://git.kernel.org/stable/c/6d8f39875a10a194051c3eaefebc7ac06a34aaf3
- https://git.kernel.org/stable/c/c98cdf6795a36bca163ebb40411fef1687b9eb13
- https://git.kernel.org/stable/c/e167414beabb1e941fe563a96becc98627d5bdf6
- https://git.kernel.org/stable/c/ee90be48edb3dac612e0b7f5332482a9e8be2696
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38286
In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91: Fix possible out-of-boundary access at91_gpio_probe() doesn't check that given OF alias is not available or something went wrong when trying to get it. This might have consequences when accessing gpio_chips array with that value as an index. Note, that BUG() can be compiled out and hence won't actually perform the required checks.
- https://git.kernel.org/stable/c/264a5cf0c422e65c94447a1ebebfac7c92690670
- https://git.kernel.org/stable/c/288c39286f759314ee8fb3a80a858179b4f306da
- https://git.kernel.org/stable/c/2ecafe59668d2506a68459a9d169ebe41a147a41
- https://git.kernel.org/stable/c/762ef7d1e6eefad9896560bfcb9bcf7f1b6df9c1
- https://git.kernel.org/stable/c/db5665cbfd766db7d8cd0e5fd6e3c0b412916774
- https://git.kernel.org/stable/c/e02e12d6a7ab76c83849a4122785650dc7edef65
- https://git.kernel.org/stable/c/eb435bc4c74acbb286cec773deac13d117d3ef39
- https://git.kernel.org/stable/c/f1c1fdc41fbf7e308ced9c86f3f66345a3f6f478
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38288
In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Fix smp_processor_id() call trace for preemptible kernels
Correct kernel call trace when calling smp_processor_id() when called in
preemptible kernels by using raw_smp_processor_id().
smp_processor_id() checks to see if preemption is disabled and if not,
issue an error message followed by a call to dump_stack().
Brief example of call trace:
kernel: check_preemption_disabled: 436 callbacks suppressed
kernel: BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/u1025:0/2354
kernel: caller is pqi_scsi_queue_command+0x183/0x310 [smartpqi]
kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0
kernel: ...
kernel: Workqueue: writeback wb_workfn (flush-253:0)
kernel: Call Trace:
kernel:
Modified: 2025-11-19
CVE-2025-38289
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbk Smatch detected a potential use-after-free of an ndlp oject in dev_loss_tmo_callbk during driver unload or fatal error handling. Fix by reordering code to avoid potential use-after-free if initial nodelist reference has been previously removed.
Modified: 2025-11-19
CVE-2025-38290
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath12k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute normally. Call trace: __list_del_entry_valid_or_report+0xd4/0x100 (P) ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k] ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k] cfg80211_wiphy_work+0xfc/0x100 process_one_work+0x164/0x2d0 worker_thread+0x254/0x380 kthread+0xfc/0x100 ret_from_fork+0x10/0x20 The change is mostly copied from the ath11k patch: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Modified: 2025-11-19
CVE-2025-38292
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix invalid access to memory In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean is_continuation is part of rxcb. Currently, after freeing the skb, the rxcb->is_continuation accessed again which is wrong since the memory is already freed. This might lead use-after-free error. Hence, fix by locally defining bool is_continuation from rxcb, so that after freeing skb, is_continuation can be used. Compile tested only.
Modified: 2025-12-18
CVE-2025-38293
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally. Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
- https://git.kernel.org/stable/c/31e98e277ae47f56632e4d663b1d4fd12ba33ea8
- https://git.kernel.org/stable/c/6c139015b597e570dd5962934e9f9a2f4cc8ef48
- https://git.kernel.org/stable/c/6d6cb27fe146061f2512e904618f5e005bb7bb6a
- https://git.kernel.org/stable/c/b0974ed82e6ad5ff246fd90a5b14f3e7be4f2924
- https://git.kernel.org/stable/c/f50ba7e7b607f2d00618799312e7fdb76a1ff48e
- https://git.kernel.org/stable/c/f5d77d0d41ea7a204d47288d0cf0404a52b5890e
- https://git.kernel.org/stable/c/f9507cf2dd0e1ed5028c0e8240da6fe5fd3110d3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-17
CVE-2025-38295
In the Linux kernel, the following vulnerability has been resolved: perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create() The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses smp_processor_id(), which assumes disabled preemption. This leads to kernel warnings during module loading because meson_ddr_pmu_create() can be called in a preemptible context. Following kernel warning and stack trace: [ 31.745138] [ T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289 [ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38 [ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0 [ 31.745181] [ T2289] Tainted: [W]=WARN [ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT) [ 31.745188] [ T2289] Call trace: [ 31.745191] [ T2289] show_stack+0x28/0x40 (C) [ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198 [ 31.745205] [ T2289] dump_stack+0x20/0x50 [ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0 [ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38 [ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745246] [ T2289] platform_probe+0x98/0xe0 [ 31.745254] [ T2289] really_probe+0x144/0x3f8 [ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180 [ 31.745261] [ T2289] driver_probe_device+0x54/0x268 [ 31.745264] [ T2289] __driver_attach+0x11c/0x288 [ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160 [ 31.745274] [ T2289] driver_attach+0x34/0x50 [ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0 [ 31.745281] [ T2289] driver_register+0x78/0x120 [ 31.745285] [ T2289] __platform_driver_register+0x30/0x48 [ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd] [ 31.745298] [ T2289] do_one_initcall+0x11c/0x438 [ 31.745303] [ T2289] do_init_module+0x68/0x228 [ 31.745311] [ T2289] load_module+0x118c/0x13a8 [ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390 [ 31.745320] [ T2289] invoke_syscall+0x74/0x108 [ 31.745326] [ T2289] el0_svc_common+0x90/0xf8 [ 31.745330] [ T2289] do_el0_svc+0x2c/0x48 [ 31.745333] [ T2289] el0_svc+0x60/0x150 [ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118 [ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0 Changes replaces smp_processor_id() with raw_smp_processor_id() to ensure safe CPU ID retrieval in preemptible contexts.
Modified: 2025-11-19
CVE-2025-38297
In the Linux kernel, the following vulnerability has been resolved: PM: EM: Fix potential division-by-zero error in em_compute_costs() When the device is of a non-CPU type, table[i].performance won't be initialized in the previous em_init_performance(), resulting in division by zero when calculating costs in em_compute_costs(). Since the 'cost' algorithm is only used for EAS energy efficiency calculations and is currently not utilized by other device drivers, we should add the _is_cpu_device(dev) check to prevent this division-by-zero issue.
Modified: 2025-12-19
CVE-2025-38298
In the Linux kernel, the following vulnerability has been resolved:
EDAC/skx_common: Fix general protection fault
After loading i10nm_edac (which automatically loads skx_edac_common), if
unload only i10nm_edac, then reload it and perform error injection testing,
a general protection fault may occur:
mce: [Hardware Error]: Machine check events logged
Oops: general protection fault ...
...
Workqueue: events mce_gen_pool_process
RIP: 0010:string+0x53/0xe0
...
Call Trace:
- https://git.kernel.org/stable/c/20d2d476b3ae18041be423671a8637ed5ffd6958
- https://git.kernel.org/stable/c/31ef6f7c9aee3be78d63789653e92350f2537f93
- https://git.kernel.org/stable/c/3f5d0659000923735350da60ad710f8c804544fe
- https://git.kernel.org/stable/c/80bf28fd623d97dd4f4825fbbe9d736cec2afba3
- https://git.kernel.org/stable/c/a13e8343ffcff27af1ff79597ff7ba241e6d9471
- https://git.kernel.org/stable/c/a6ed3a6edff09c1187cc6ade7f5967bca2376a13
- https://git.kernel.org/stable/c/bf6a8502a5f4ff6e4d135d795945cdade49ec8b0
- https://git.kernel.org/stable/c/e8530ed3c0769a4d8f79c212715ec1cf277787f8
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38299
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY() ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(), in the case the codec dai_name will be null. Avoid a crash if the device tree is not assigning a codec to these links. [ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but active_mm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: events_unbound deferred_probe_work_func [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : __pi_strcmp+0x24/0x140 [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8 [ 1.203644] platform_probe+0x70/0xe8 [ 1.204106] really_probe+0xc8/0x3a0 [ 1.204556] __driver_probe_device+0x84/0x160 [ 1.205104] driver_probe_device+0x44/0x130 [ 1.205630] __device_attach_driver+0xc4/0x170 [ 1.206189] bus_for_each_drv+0x8c/0xf8 [ 1.206672] __device_attach+0xa8/0x1c8 [ 1.207155] device_initial_probe+0x1c/0x30 [ 1.207681] bus_probe_device+0xb0/0xc0 [ 1.208165] deferred_probe_work_func+0xa4/0x100 [ 1.208747] process_one_work+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ end trace 0000000000000000 ]---
Modified: 2025-12-19
CVE-2025-38300
In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare() Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare(): 1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- To fix this, check for !dma_mapping_error() before calling dma_unmap_single() on the "theend_iv" path.
- https://git.kernel.org/stable/c/19d267d9fad00d94ad8477899e38ed7c11f33fb6
- https://git.kernel.org/stable/c/4051250e5db489f8ad65fc337e2677b9b568ac72
- https://git.kernel.org/stable/c/a0ac3f85b2e3ef529e852f252a70311f9029d5e6
- https://git.kernel.org/stable/c/c62b79c1c51303dbcb6edfa4de0ee176f4934c52
- https://git.kernel.org/stable/c/f31adc3e356f7350d4a4d68c98d3f60f2f6e26b3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38301
In the Linux kernel, the following vulnerability has been resolved: nvmem: zynqmp_nvmem: unbreak driver after cleanup Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup") changed the driver to expect the device pointer to be passed as the "context", but in nvmem the context parameter comes from nvmem_config.priv which is never set - Leading to null pointer exceptions when the device is accessed.
Modified: 2025-11-19
CVE-2025-38302
In the Linux kernel, the following vulnerability has been resolved: block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work Bios queued up in the zone write plug have already gone through all all preparation in the submit_bio path, including the freeze protection. Submitting them through submit_bio_noacct_nocheck duplicates the work and can can cause deadlocks when freezing a queue with pending bio write plugs. Go straight to ->submit_bio or blk_mq_submit_bio to bypass the superfluous extra freeze protection and checks.
Modified: 2026-04-11
CVE-2025-38303
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.
Modified: 2025-12-19
CVE-2025-38304
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA.
- https://git.kernel.org/stable/c/20a2aa01f5aeb6daad9aeaa7c33dd512c58d81eb
- https://git.kernel.org/stable/c/497c9d2d7d3983826bb02c10fb4a5818be6550fb
- https://git.kernel.org/stable/c/4bf29910570666e668a60d953f8da78e95bb7fa2
- https://git.kernel.org/stable/c/7d99cc0f8e6fa0f35570887899f178122a61d44e
- https://git.kernel.org/stable/c/842f7c3154d5b25ca11753c02ee8cf6ee64c0142
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38305
In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking.
- https://git.kernel.org/stable/c/259119595227fd20f6aa29d85abe086b6fdd9eb1
- https://git.kernel.org/stable/c/5d217e7031a5c06d366580fc6ddbf43527b780d4
- https://git.kernel.org/stable/c/87f7ce260a3c838b49e1dc1ceedf1006795157a2
- https://git.kernel.org/stable/c/b1b73c452331451020be3bf4b014901015ae6663
- https://git.kernel.org/stable/c/b93e6fef4eda48e17d9c642b9abad98a066fd4a3
- https://git.kernel.org/stable/c/ef8fc007c28a30a4c0d90bf755e0f343d99bb392
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38307
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Verify content returned by parse_int_array() The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref.
Modified: 2025-12-19
CVE-2025-38310
In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one.
- https://git.kernel.org/stable/c/668923c474608dd9ebce0fbcc41bd8a27aa73dd6
- https://git.kernel.org/stable/c/7632fedb266d93ed0ed9f487133e6c6314a9b2d1
- https://git.kernel.org/stable/c/cd4cd09810211fa23609c5c1018352e9e1cd8e5a
- https://git.kernel.org/stable/c/cef33a86bcb04ecf4dc10c56f6c42ee9d1c54bac
- https://git.kernel.org/stable/c/d2507aeea45b3c5aa24d5daae0cf3db76895c0b7
- https://git.kernel.org/stable/c/d5d9fd13bc19a3f9f2a951c5b6e934d84205789e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38312
In the Linux kernel, the following vulnerability has been resolved: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.
- https://git.kernel.org/stable/c/2d63433e8eaa3c91b2948190e395bc67009db0d9
- https://git.kernel.org/stable/c/3f6dae09fc8c306eb70fdfef70726e1f154e173a
- https://git.kernel.org/stable/c/53784073cbad18f75583fd3da9ffdfc4d1f05405
- https://git.kernel.org/stable/c/54947530663edcbaaee1314c01fdd8c72861b124
- https://git.kernel.org/stable/c/610f247f2772e4f92b63442125a1b7ade79898d8
- https://git.kernel.org/stable/c/9027ce4c037b566b658b8939a76326b7125e3627
- https://git.kernel.org/stable/c/ab91647acdf43b984824776559a452212eaeb21a
- https://git.kernel.org/stable/c/b235393b9f43ff86a38ca2bde6372312ea215dc5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38313
In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix double-free on mc_dev The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is a false-positive. WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);
- https://git.kernel.org/stable/c/12e4431e5078847791936820bd39df9e1ee26d2e
- https://git.kernel.org/stable/c/1d5baab39e5b09a76870b345cdee7933871b881f
- https://git.kernel.org/stable/c/3135e03a92f6b5259d0a7f25f728e9e7866ede3f
- https://git.kernel.org/stable/c/4b23c46eb2d88924b93aca647bde9a4b9cf62cf9
- https://git.kernel.org/stable/c/7002b954c4a8b9965ba0f139812ee4a6f71beac8
- https://git.kernel.org/stable/c/873d47114fd5e5a1cad2018843671537cc71ac84
- https://git.kernel.org/stable/c/b2057374f326303c86d8423415ab58656eebc695
- https://git.kernel.org/stable/c/d694bf8a9acdbd061596f3e7549bc8cb70750a60
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38315
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Check dsbr size from EFI variable Since the size of struct btintel_dsbr is already known, we can just start there instead of querying the EFI variable size. If the final result doesn't match what we expect also fail. This fixes a stack buffer overflow when the EFI variable is larger than struct btintel_dsbr.
Modified: 2025-11-18
CVE-2025-38317
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix buffer overflow in debugfs If the user tries to write more than 32 bytes then it results in memory corruption. Fortunately, this is debugfs so it's limited to root users.
Modified: 2025-11-18
CVE-2025-38318
In the Linux kernel, the following vulnerability has been resolved: perf: arm-ni: Fix missing platform_set_drvdata() Add missing platform_set_drvdata in arm_ni_probe(), otherwise calling platform_get_drvdata() in remove returns NULL.
Modified: 2025-12-19
CVE-2025-38319
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.
- https://git.kernel.org/stable/c/64f3acc8c7e6809631457b75638601b36dea3129
- https://git.kernel.org/stable/c/7080c20a9139842033ed4af604dc1fa4028593ad
- https://git.kernel.org/stable/c/820116a39f96bdc7d426c33a804b52f53700a919
- https://git.kernel.org/stable/c/85cdcb834fb490731ff2d123f87ca799c57dacf2
- https://git.kernel.org/stable/c/a4ff7391c8b75b1541900bd9d0c238e558c11fb3
- https://git.kernel.org/stable/c/cdf7e1ff99ab06ef15d0b5d1aca5258a4fb62b85
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38320
In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] __se_sys_clone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] dup_task_struct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before: commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()") As described in that commit, regs_get_kernel_stack_nth() has confirmed that `addr` is on the stack, so reading the value at `*addr` should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case. [will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]
- https://git.kernel.org/stable/c/01f91d415a8375d85e0c7d3615cd4a168308bb7c
- https://git.kernel.org/stable/c/21da6d3561f373898349ca7167c9811c020da695
- https://git.kernel.org/stable/c/22f935bc86bdfbde04009f05eee191d220cd8c89
- https://git.kernel.org/stable/c/39dfc971e42d886e7df01371cd1bef505076d84c
- https://git.kernel.org/stable/c/422e565b7889ebfd9c8705a3fc786642afe61fca
- https://git.kernel.org/stable/c/64773b3ea09235168a549a195cba43bb867c4a17
- https://git.kernel.org/stable/c/67abac27d806e8f9d4226ec1528540cf73af673a
- https://git.kernel.org/stable/c/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38321
In the Linux kernel, the following vulnerability has been resolved: smb: Log an error when close_all_cached_dirs fails Under low-memory conditions, close_all_cached_dirs() can't move the dentries to a separate list to dput() them once the locks are dropped. This will result in a "Dentry still in use" error, so add an error message that makes it clear this is what happened: [ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries [ 495.281595] ------------[ cut here ]------------ [ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs] [ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0 Also, bail out of looping through all tcons as soon as a single allocation fails, since we're already in trouble, and kmalloc() attempts for subseqeuent tcons are likely to fail just like the first one did.
Modified: 2025-12-19
CVE-2025-38323
In the Linux kernel, the following vulnerability has been resolved:
net: atm: add lec_mutex
syzbot found its way in net/atm/lec.c, and found an error path
in lecd_attach() could leave a dangling pointer in dev_lec[].
Add a mutex to protect dev_lecp[] uses from lecd_attach(),
lec_vcc_attach() and lec_mcast_attach().
Following patch will use this mutex for /proc/net/atm/lec.
BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline]
BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142
CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
- https://git.kernel.org/stable/c/17e156a94e94a906a570dbf9b48877956c60bef8
- https://git.kernel.org/stable/c/18e8f0c4f826fb08c2d3825cdd6c57e24b207e0a
- https://git.kernel.org/stable/c/64b378db28a967f7b271b055380c2360279aa424
- https://git.kernel.org/stable/c/a7a713dfb5f9477345450f27c7c0741864511192
- https://git.kernel.org/stable/c/d13a3824bfd2b4774b671a75cf766a16637a0e67
- https://git.kernel.org/stable/c/dffd03422ae6a459039c8602f410e6c0f4cbc6c8
- https://git.kernel.org/stable/c/e91274cc7ed88ab5bdc62d426067c82b0b118a0b
- https://git.kernel.org/stable/c/f4d80b16ecc4229f7e6345158ef34c36be323f0e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38324
In the Linux kernel, the following vulnerability has been resolved:
mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().
As syzbot reported [0], mpls_route_input_rcu() can be called
from mpls_getroute(), where is under RTNL.
net->mpls.platform_label is only updated under RTNL.
Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to
silence the splat.
[0]:
WARNING: suspicious RCU usage
6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted
----------------------------
net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz.2.4451/17730:
#0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
#0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961
stack backtrace:
CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
- https://git.kernel.org/stable/c/2919297b18e5a5fb7e643f9e32c12c0b17cce1be
- https://git.kernel.org/stable/c/36af82f25fbdcd719eb947c15ea874bf80bcf229
- https://git.kernel.org/stable/c/49b8a9d7d44401a186e20b1aaf591d2e62727aeb
- https://git.kernel.org/stable/c/517bc6836ee9fcffe2539f6f6aa3fdd9c7a7ae73
- https://git.kernel.org/stable/c/6dbb0d97c5096072c78a6abffe393584e57ae945
- https://git.kernel.org/stable/c/a060781640012d5d5105072f4c44ed6ad6830ef9
- https://git.kernel.org/stable/c/d8cd847fb8626872631cc22d44be5127b4ebfb74
- https://git.kernel.org/stable/c/f19cbd84e645e39bc3228e1191bb151ef0ffac8c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38325
In the Linux kernel, the following vulnerability has been resolved: ksmbd: add free_transport ops in ksmbd connection free_transport function for tcp connection can be called from smbdirect. It will cause kernel oops. This patch add free_transport ops in ksmbd connection, and add each free_transports for tcp and smbdirect.
Modified: 2025-12-19
CVE-2025-38326
In the Linux kernel, the following vulnerability has been resolved: aoe: clean device rq_list in aoedev_downdev() An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue().
- https://git.kernel.org/stable/c/00be74e1470af292c37a438b8e69dee47dcbf481
- https://git.kernel.org/stable/c/531aef4a1accb13b21a3b82ec29955f4733367d5
- https://git.kernel.org/stable/c/64fc0bad62ed38874131dd0337d844a43bd1017e
- https://git.kernel.org/stable/c/7f90d45e57cb2ef1f0adcaf925ddffdfc5e680ca
- https://git.kernel.org/stable/c/8662ac79a63488e279b91c12a72b02bc0dc49f7b
- https://git.kernel.org/stable/c/ed52e9652ba41d362e9ec923077f6da23336f269
- https://git.kernel.org/stable/c/ef0b5bbbed7f220db2e9c73428f9a36e8dfc69ca
- https://git.kernel.org/stable/c/fa2a79f0da92614c5dc45c8b3d2638681c7734ee
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38328
In the Linux kernel, the following vulnerability has been resolved: jffs2: check jffs2_prealloc_raw_node_refs() result in few other places Fuzzing hit another invalid pointer dereference due to the lack of checking whether jffs2_prealloc_raw_node_refs() completed successfully. Subsequent logic implies that the node refs have been allocated. Handle that. The code is ready for propagating the error upwards. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600 Call Trace: jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline] jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497 call_write_iter include/linux/fs.h:2039 [inline] do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740 do_iter_write+0x18c/0x710 fs/read_write.c:866 vfs_writev+0x1db/0x6a0 fs/read_write.c:939 do_pwritev fs/read_write.c:1036 [inline] __do_sys_pwritev fs/read_write.c:1083 [inline] __se_sys_pwritev fs/read_write.c:1078 [inline] __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/042fa922c84b5080401bcd8897d4ac4919d15075
- https://git.kernel.org/stable/c/2b6d96503255a3ed676cd70f8368870c6d6a25c6
- https://git.kernel.org/stable/c/38d767fb4a7766ec2058f97787e4c6e8d10343d6
- https://git.kernel.org/stable/c/7e860296d7808de1db175c1eda29f94a2955dcc4
- https://git.kernel.org/stable/c/cd42ddddd70abc7127c12b96c8c85dbd080ea56f
- https://git.kernel.org/stable/c/d1b81776f337a9b997f797c70ac0a26d838a2168
- https://git.kernel.org/stable/c/d96e6451a8d0fe62492d4cc942d695772293c05a
- https://git.kernel.org/stable/c/f41c625328777f9ad572901ba0b0065bb9c9c1da
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38331
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Use TOE/TSO on all TCP It is desireable to push the hardware accelerator to also process non-segmented TCP frames: we pass the skb->len to the "TOE/TSO" offloader and it will handle them. Without this quirk the driver becomes unstable and lock up and and crash. I do not know exactly why, but it is probably due to the TOE (TCP offload engine) feature that is coupled with the segmentation feature - it is not possible to turn one part off and not the other, either both TOE and TSO are active, or neither of them. Not having the TOE part active seems detrimental, as if that hardware feature is not really supposed to be turned off. The datasheet says: "Based on packet parsing and TCP connection/NAT table lookup results, the NetEngine puts the packets belonging to the same TCP connection to the same queue for the software to process. The NetEngine puts incoming packets to the buffer or series of buffers for a jumbo packet. With this hardware acceleration, IP/TCP header parsing, checksum validation and connection lookup are offloaded from the software processing." After numerous tests with the hardware locking up after something between minutes and hours depending on load using iperf3 I have concluded this is necessary to stabilize the hardware.
- https://git.kernel.org/stable/c/1b503b790109d19710ec83c589c3ee59e95347ec
- https://git.kernel.org/stable/c/2bd434bb0eeb680c2b3dd6c68ca319b30cb8d47f
- https://git.kernel.org/stable/c/6a07e3af4973402fa199a80036c10060b922c92c
- https://git.kernel.org/stable/c/a37888a435b0737128d2d9c6f67b8d608f83df7a
- https://git.kernel.org/stable/c/ebe12e232f1d58ebb4b53b6d9149962b707bed91
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38332
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Use memcpy() for BIOS version The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string.
- https://git.kernel.org/stable/c/003baa7a1a152576d744bd655820449bbdb0248e
- https://git.kernel.org/stable/c/2f63bf0d2b146956a2f2ff3b25cee71019e64561
- https://git.kernel.org/stable/c/34c0a670556b24d36c9f8934227edb819ca5609e
- https://git.kernel.org/stable/c/75ea8375c5a83f46c47bfb3de6217c7589a8df93
- https://git.kernel.org/stable/c/ac7bfaa099ec3e4d7dfd0ab9726fc3bc7911365d
- https://git.kernel.org/stable/c/ae82eaf4aeea060bb736c3e20c0568b67c701d7d
- https://git.kernel.org/stable/c/b699bda5db818b684ff62d140defd6394f38f3d6
- https://git.kernel.org/stable/c/d34f2384d6df11a6c67039b612c2437f46e587e8
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38333
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to bail out in get_new_segment() ------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20 get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment.
Modified: 2025-12-16
CVE-2025-38334
In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Prevent attempts to reclaim poisoned pages TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a "TBD" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply. This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.
- https://git.kernel.org/stable/c/00a88e9ea1b170d579c56327c38f7e8cf689df87
- https://git.kernel.org/stable/c/31dcbac94bfeabb86bf85b0c36803fdd6536437b
- https://git.kernel.org/stable/c/62b62a2a6dc51ed6e8e334861f04220c9cf8106a
- https://git.kernel.org/stable/c/dc5de5bd6deabd327ced2b2b1d0b4f14cd146afe
- https://git.kernel.org/stable/c/ed16618c380c32c68c06186d0ccbb0d5e0586e59
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38335
In the Linux kernel, the following vulnerability has been resolved: Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context, but the input_event() takes a spin_lock, which isn't allowed there as it is converted to a rt_spin_lock(). [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context. Relax the hrtimer not to use the hard context.
- https://git.kernel.org/stable/c/664e5a6f541ff226621487d1280d2ec28e86be28
- https://git.kernel.org/stable/c/a7b79db25846459de63ca8974268f0c41c734c4b
- https://git.kernel.org/stable/c/a8f01e51109f77229e426b57c5d19251b462c6aa
- https://git.kernel.org/stable/c/ec8f5da79b425deef5aebacdd4fe645620cd4f0b
- https://git.kernel.org/stable/c/f4a8f561d08e39f7833d4a278ebfb12a41eef15f
- https://git.kernel.org/stable/c/fa53beab4740c4e5fe969f218a379f9558be33dc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38336
In the Linux kernel, the following vulnerability has been resolved: ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330 The controller has a hardware bug that can hard hang the system when doing ATAPI DMAs without any trace of what happened. Depending on the device attached, it can also prevent the system from booting. In this case, the system hangs when reading the ATIP from optical media with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, running at UDMA/33. The issue can be reproduced by running the same command with a cygwin build of cdrecord on WinXP, although it requires more attempts to cause it. The hang in that case is also resolved by forcing PIO. It doesn't appear that VIA has produced any drivers for that OS, thus no known workaround exists. HDDs attached to the controller do not suffer from any DMA issues.
- https://git.kernel.org/stable/c/0d9a48dfa934f43ac839211ae4aeba34f666a9a5
- https://git.kernel.org/stable/c/67d66a5e4583fd3bcf13d6f747e571df13cbad51
- https://git.kernel.org/stable/c/7fc89c218fc96a296a2840b1e37f4e0975f7a108
- https://git.kernel.org/stable/c/8212cd92fe40aae6fe5a073bc70e758c42bb4bfc
- https://git.kernel.org/stable/c/8edfed4439b107d62151ff6c075958d169da3e71
- https://git.kernel.org/stable/c/947f9304d3c876c6672b947b80c0ef51161c6d2f
- https://git.kernel.org/stable/c/bb7212ee4ff086628a2c1c22336d082a87cb893d
- https://git.kernel.org/stable/c/d29fc02caad7f94b62d56ee1b01c954f9c961ba7
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38337
In the Linux kernel, the following vulnerability has been resolved: jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() Since handle->h_transaction may be a NULL pointer, so we should change it to call is_handle_aborted(handle) first before dereferencing it. And the following data-race was reported in my fuzzer: ================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ================================================================== This issue is caused by missing data-race annotation for jh->b_modified. Therefore, the missing annotation needs to be added.
- https://git.kernel.org/stable/c/23361b479f2700c00960d3ae9cdc8ededa762d47
- https://git.kernel.org/stable/c/2e7c64d7a92c031d016f11c8e8cb05131ab7b75a
- https://git.kernel.org/stable/c/43d5e3bb5f1dcd91e30238ea0b59a5f77063f84e
- https://git.kernel.org/stable/c/5c1a34ff5b0bfdfd2f9343aa9b08d25df618bac5
- https://git.kernel.org/stable/c/a377996d714afb8d4d5f4906336f78510039da29
- https://git.kernel.org/stable/c/af98b0157adf6504fade79b3e6cb260c4ff68e37
- https://git.kernel.org/stable/c/ec669e5bf409f16e464bfad75f0ba039a45de29a
- https://git.kernel.org/stable/c/f78b38af3540b4875147b7b884ee11a27b3dbf4c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38338
In the Linux kernel, the following vulnerability has been resolved:
fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()
Sometimes, when a file was read while it was being truncated by
another NFS client, the kernel could deadlock because folio_unlock()
was called twice, and the second call would XOR back the `PG_locked`
flag.
Most of the time (depending on the timing of the truncation), nobody
notices the problem because folio_unlock() gets called three times,
which flips `PG_locked` back off:
1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,
nfs_return_empty_folio
2. vfs_read, nfs_read_folio, ... netfs_read_collection,
netfs_unlock_abandoned_read_pages
3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,
nfs_return_empty_folio
The problem is that nfs_read_add_folio() is not supposed to unlock the
folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is
missing in nfs_return_empty_folio().
Rarely this leads to a warning in netfs_read_collection():
------------[ cut here ]------------
R=0000031c: folio 10 is not locked
WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00
[...]
Workqueue: events_unbound netfs_read_collection_worker
RIP: 0010:netfs_read_collection+0x7c0/0xf00
[...]
Call Trace:
Modified: 2025-11-18
CVE-2025-38341
In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: avoid double free when failing to DMA-map FW msg The semantics are that caller of fbnic_mbx_map_msg() retains the ownership of the message on error. All existing callers dutifully free the page.
Modified: 2025-12-16
CVE-2025-38342
In the Linux kernel, the following vulnerability has been resolved: software node: Correct a OOB check in software_node_get_reference_args() software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.
- https://git.kernel.org/stable/c/142acd739eb6f08c148a96ae8309256f1422ff4b
- https://git.kernel.org/stable/c/31e4e12e0e9609850cefd4b2e1adf782f56337d6
- https://git.kernel.org/stable/c/4b3383110b6df48e0ba5936af2cb68d5eb6bd43b
- https://git.kernel.org/stable/c/56ce76e8d406cc72b89aee7931df5cf3f18db49d
- https://git.kernel.org/stable/c/7af18e42bdefe1dba5bcb32555a4d524fd504939
- https://git.kernel.org/stable/c/9324127b07dde8529222dc19233aa57ec810856c
- https://git.kernel.org/stable/c/f9397cf7bfb680799fb8c7f717c8f756384c3280
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38343
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: drop fragments with multicast or broadcast RA IEEE 802.11 fragmentation can only be applied to unicast frames. Therefore, drop fragments with multicast or broadcast RA. This patch addresses vulnerabilities such as CVE-2020-26145.
Modified: 2025-12-16
CVE-2025-38344
In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi parse and parseext cache leaks ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5 I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncated---
- https://git.kernel.org/stable/c/0a119fdaed67566aa3e0b5222dced4d08bbce463
- https://git.kernel.org/stable/c/198c2dab022e5e94a99fff267b669d693bc7bb49
- https://git.kernel.org/stable/c/1e0e629e88b1f7751ce69bf70cda6d1598d45271
- https://git.kernel.org/stable/c/1fee4324b5660de080cefc3fc91c371543bdb8f6
- https://git.kernel.org/stable/c/3e0c59180ec83bdec43b3d3482cff23d86d380d0
- https://git.kernel.org/stable/c/41afebc9a0762aafc35d2df88f4e1b798155a940
- https://git.kernel.org/stable/c/960236150cd3f08e13b397dd5ae4ccf7a2986c00
- https://git.kernel.org/stable/c/bed18f0bdcd6737a938264a59d67923688696fc4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38345
In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi operand cache leak in dswstate.c ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak.
- https://git.kernel.org/stable/c/156fd20a41e776bbf334bd5e45c4f78dfc90ce1c
- https://git.kernel.org/stable/c/1c0d9115a001979cb446ba5e8331dd1d29a10bbf
- https://git.kernel.org/stable/c/4fa430a8bca708c7776f6b9d001257f48b19a5b7
- https://git.kernel.org/stable/c/5a68893b594ee6ce0efce5f74c07e64e9dd0c2c4
- https://git.kernel.org/stable/c/64c4bcf0308dd1d752ef31d560040b8725e29984
- https://git.kernel.org/stable/c/755a8006b76792922ff7b1c9674d8897a476b5d7
- https://git.kernel.org/stable/c/76d37168155880f2b04a0aad92ceb0f9d799950e
- https://git.kernel.org/stable/c/e0783910ca4368b01466bc8dcdcc13c3e0b7db53
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38346
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix UAF when lookup kallsym after ftrace disabled
The following issue happens with a buggy module:
BUG: unable to handle page fault for address: ffffffffc05d0218
PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0
Oops: Oops: 0000 [#1] SMP KASAN PTI
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
RIP: 0010:sized_strscpy+0x81/0x2f0
RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000
RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d
RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68
R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038
R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff
FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/03a162933c4a03b9f1a84f7d8482903c7e1e11bb
- https://git.kernel.org/stable/c/6805582abb720681dd1c87ff677f155dcf4e86c9
- https://git.kernel.org/stable/c/83a692a9792aa86249d68a8ac0b9d55ecdd255fa
- https://git.kernel.org/stable/c/8690cd3258455bbae64f809e1d3ee0f043661c71
- https://git.kernel.org/stable/c/8e89c17dc8970c5f71a3a991f5724d4c8de42d8c
- https://git.kernel.org/stable/c/d064c68781c19f378af1ae741d9132d35d24b2bb
- https://git.kernel.org/stable/c/f78a786ad9a5443a29eef4dae60cde85b7375129
- https://git.kernel.org/stable/c/f914b52c379c12288b7623bb814d0508dbe7481d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-19
CVE-2025-38347
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on ino and xnid
syzbot reported a f2fs bug as below:
INFO: task syz-executor140:5308 blocked for more than 143 seconds.
Not tainted 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor140 state:D stack:24016 pid:5308 tgid:5308 ppid:5306 task_flags:0x400140 flags:0x00000006
Call Trace:
- https://git.kernel.org/stable/c/061cf3a84bde038708eb0f1d065b31b7c2456533
- https://git.kernel.org/stable/c/44e904a1ad09e84039058dcbbb1b9ea5b8d7d75d
- https://git.kernel.org/stable/c/5a06d97d5340c00510f24e80e8de821bd3bd9285
- https://git.kernel.org/stable/c/aaddc6c696bd1bff20eaacfa88579d6eae64d541
- https://git.kernel.org/stable/c/c4029044cc408b149e63db7dc8617a0783a3f10d
- https://git.kernel.org/stable/c/e98dc1909f3d5bc078ec7a605524f1e3f4c0eb14
- https://git.kernel.org/stable/c/ecff54aa20b5b21db82e63e46066b55e43d72e78
- https://git.kernel.org/stable/c/fed611bd8c7b76b070aa407d0c7558e20d9e1f68
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38348
In the Linux kernel, the following vulnerability has been resolved: wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback() Robert Morris reported: |If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun. This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them. The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.
- https://git.kernel.org/stable/c/0e4dc150423b829c35cbcf399481ca11594fc036
- https://git.kernel.org/stable/c/12134f79e53eb56b0b0b7447fa0c512acf6a8422
- https://git.kernel.org/stable/c/1f7f8168abe8cbe845ab8bb557228d44784a6b57
- https://git.kernel.org/stable/c/6d05390d20f110de37d051a3e063ef0a542d01fb
- https://git.kernel.org/stable/c/714afb4c38edd19a057d519c1f9c5d164b43de94
- https://git.kernel.org/stable/c/9701f842031b825e2fd5f22d064166f8f13f6e4d
- https://git.kernel.org/stable/c/da1b9a55ff116cb040528ef664c70a4eec03ae99
- https://git.kernel.org/stable/c/f39b2f8c1549a539846e083790fad396ef6cd802
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38349
In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "ep_free(ep)" until after it has unlocked the mutex. But it's wrong for the much subtler "next to last" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: "mutex_unlock() may access the mutex structure even after it has internally released the lock already - so it's not safe for another context to acquire the mutex and assume that the mutex_unlock() context is not using the structure anymore" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes).
- https://git.kernel.org/stable/c/521e9ff0b67c66a17d6f9593dfccafaa984aae4c
- https://git.kernel.org/stable/c/605c18698ecfa99165f36b7f59d3ed503e169814
- https://git.kernel.org/stable/c/6dee745bd0aec9d399df674256e7b1ecdb615444
- https://git.kernel.org/stable/c/8c2e52ebbe885c7eeaabd3b7ddcdc1246fc400d2
- https://project-zero.issues.chromium.org/issues/430541637
Modified: 2025-11-18
CVE-2025-38351
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated. However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error(): invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm] Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way. Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.
Modified: 2026-01-08
CVE-2025-38352
In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail. Add the tsk->exit_state check into run_posix_cpu_timers() to fix this. This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case.
- https://git.kernel.org/stable/c/2c72fe18cc5f9f1750f5bc148cf1c94c29e106ff
- https://git.kernel.org/stable/c/2f3daa04a9328220de46f0d5c919a6c0073a9f0b
- https://git.kernel.org/stable/c/460188bc042a3f40f72d34b9f7fc6ee66b0b757b
- https://git.kernel.org/stable/c/764a7a5dfda23f69919441f2eac2a83e7db6e5bb
- https://git.kernel.org/stable/c/78a4b8e3795b31dae58762bc091bb0f4f74a2200
- https://git.kernel.org/stable/c/c076635b3a42771ace7d276de8dc3bc76ee2ba1b
- https://git.kernel.org/stable/c/c29d5318708e67ac13c1b6fc1007d179fb65b4d7
- https://git.kernel.org/stable/c/f90fff1e152dedf52b932240ebbd670d83330eca
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
- https://github.com/farazsth98/chronomaly
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-38352
Modified: 2025-11-18
CVE-2025-38353
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix taking invalid lock on wedge If device wedges on e.g. GuC upload, the submission is not yet enabled and the state is not even initialized. Protect the wedge call so it does nothing in this case. It fixes the following splat: [] xe 0000:bf:00.0: [drm] device wedged, needs recovery [] ------------[ cut here ]------------ [] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60 ... [] RIP: 0010:__mutex_lock+0x8a1/0xe60 [] mutex_lock_nested+0x1b/0x30 [] xe_guc_submit_wedge+0x80/0x2b0 [xe]
Modified: 2025-12-16
CVE-2025-38354
In the Linux kernel, the following vulnerability has been resolved: drm/msm/gpu: Fix crash when throttling GPU immediately during boot There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ... At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msm_devfreq_get_dev_status() will end up accessing GMU registers, causing the crash. Fix this by setting df->suspended correctly during initialization. Patchwork: https://patchwork.freedesktop.org/patch/650772/
- https://git.kernel.org/stable/c/1847ea44e3bdf7da8ff4158bc01b43a2e46394bd
- https://git.kernel.org/stable/c/7946a10f8da75abc494e4bb80243e153e93e459a
- https://git.kernel.org/stable/c/a6f673cc9488fd722c601fe020601dba14db21b2
- https://git.kernel.org/stable/c/ae2015b0dbc0eea7aaf022194371f451f784d994
- https://git.kernel.org/stable/c/b71717735be48d7743a34897e9e44a0b53e30c0e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38355
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Process deferred GGTT node removals on device unwind
While we are indirectly draining our dedicated workqueue ggtt->wq
that we use to complete asynchronous removal of some GGTT nodes,
this happends as part of the managed-drm unwinding (ggtt_fini_early),
which could be later then manage-device unwinding, where we could
already unmap our MMIO/GMS mapping (mmio_fini).
This was recently observed during unsuccessful VF initialization:
[ ] xe 0000:00:02.1: probe with driver xe failed with error -62
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes)
[ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin
[ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes)
[ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes)
[ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes)
[ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes)
and this was leading to:
[ ] BUG: unable to handle page fault for address: ffffc900058162a0
[ ] #PF: supervisor write access in kernel mode
[ ] #PF: error_code(0x0002) - not-present page
[ ] Oops: Oops: 0002 [#1] SMP NOPTI
[ ] Tainted: [W]=WARN
[ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe]
[ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe]
[ ] Call Trace:
[ ]
Modified: 2025-11-18
CVE-2025-38356
In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Explicitly exit CT safe mode on unwind During driver probe we might be briefly using CT safe mode, which is based on a delayed work, but usually we are able to stop this once we have IRQ fully operational. However, if we abort the probe quite early then during unwind we might try to destroy the workqueue while there is still a pending delayed work that attempts to restart itself which triggers a WARN. This was recently observed during unsuccessful VF initialization: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] ------------[ cut here ]------------ [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710 [ ] RIP: 0010:__queue_work+0x287/0x710 [ ] Call Trace: [ ] delayed_work_timer_fn+0x19/0x30 [ ] call_timer_fn+0xa1/0x2a0 Exit the CT safe mode on unwind to avoid that warning. (cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)
Modified: 2025-11-18
CVE-2025-38360
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add more checks for DSC / HUBP ONO guarantees [WHY] For non-zero DSC instances it's possible that the HUBP domain required to drive it for sequential ONO ASICs isn't met, potentially causing the logic to the tile to enter an undefined state leading to a system hang. [HOW] Add more checks to ensure that the HUBP domain matching the DSC instance is appropriately powered. (cherry picked from commit da63df07112e5a9857a8d2aaa04255c4206754ec)
Modified: 2026-03-17
CVE-2025-38361
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)
- https://git.kernel.org/stable/c/5e1482ae14b03b9fca73ef5afea26ede683f4450
- https://git.kernel.org/stable/c/60e450eec5d63113c6ad5c456ce64c12b4496a6e
- https://git.kernel.org/stable/c/b669507b637eb6b1aaecf347f193efccc65d756e
- https://git.kernel.org/stable/c/df11bf0ef795b6d415c4d8ee54fa3f2105e75bcb
- https://git.kernel.org/stable/c/e881b82f5d3d8d54d168cd276169f0fee01bf0e7
Modified: 2025-12-16
CVE-2025-38362
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null pointer check for get_first_active_display() The function mod_hdcp_hdcp1_enable_encryption() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference in mod_hdcp_hdcp2_enable_encryption(). Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
- https://git.kernel.org/stable/c/1ebcdf38887949def1a553ff3e45c98ed95a3cd0
- https://git.kernel.org/stable/c/34d3e10ab905f06445f8dbd8a3d9697095e71bae
- https://git.kernel.org/stable/c/4ce9f2dc9ff7cc410e8c5d936ec551e26b9599a9
- https://git.kernel.org/stable/c/5148c7ea69e9c5bf2f05081190f45ba96d3d1e7a
- https://git.kernel.org/stable/c/b3005145eab98d36777660b8893466e4f630ae1c
- https://git.kernel.org/stable/c/c3e9826a22027a21d998d3e64882fa377b613006
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38363
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix a possible null pointer dereference In tegra_crtc_reset(), new memory is allocated with kzalloc(), but no check is performed. Before calling __drm_atomic_helper_crtc_reset, state should be checked to prevent possible null pointer dereference.
- https://git.kernel.org/stable/c/31ac2c680a8ac11dc54a5b339a07e138bcedd924
- https://git.kernel.org/stable/c/5ff3636bcc32e1cb747f6f820bcf2bb6990a7d41
- https://git.kernel.org/stable/c/780351a5f61416ed2ba1199cc57e4a076fca644d
- https://git.kernel.org/stable/c/99a25fc7933b88d5e16668bf6ba2d098e1754406
- https://git.kernel.org/stable/c/ab390ab81241cf8bf37c0a0ac2e9c6606bf3e991
- https://git.kernel.org/stable/c/ac4ca634f0c9f227538711d725339293f7047b02
- https://git.kernel.org/stable/c/c7fc459ae6f988e0d5045a270bd600ab08bc61f1
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38364
In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate() Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations. The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption. User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least)
- https://git.kernel.org/stable/c/9e32f4700867abbd5d19abfcf698dbd0d2ce36a4
- https://git.kernel.org/stable/c/cf95f8426f889949b738f51ffcd72884411f3a6a
- https://git.kernel.org/stable/c/d69cd64bd5af41c6fd409313504089970edaf02f
- https://git.kernel.org/stable/c/e63032e66bca1d06e600033f3369ba3db3af0870
- https://git.kernel.org/stable/c/fba46a5d83ca8decb338722fb4899026d8d9ead2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38365
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a race between renames and directory logging We have a race between a rename and directory inode logging that if it happens and we crash/power fail before the rename completes, the next time the filesystem is mounted, the log replay code will end up deleting the file that was being renamed. This is best explained following a step by step analysis of an interleaving of steps that lead into this situation. Consider the initial conditions: 1) We are at transaction N; 2) We have directories A and B created in a past transaction (< N); 3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N); 4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N). The steps leading to a file loss are the following and for all of them we are under transaction N: 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree; 10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name "A/bar", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to "A/bar"). Since there's no other hard link for inode Y and the log replay code deletes the name "A/bar", the file is lost. The issue wouldn't happen if task B synced the log only after task A called btrfs_log_new_name(), which would update the log with the new name for inode Y ("A/bar"). Fix this by pinning the log root during renames before removing the old directory entry, and unpinning af ---truncated---
- https://git.kernel.org/stable/c/2088895d5903082bb9021770b919e733c57edbc1
- https://git.kernel.org/stable/c/3ca864de852bc91007b32d2a0d48993724f4abad
- https://git.kernel.org/stable/c/51bd363c7010d033d3334daf457c824484bf9bf0
- https://git.kernel.org/stable/c/8c6874646c21bd820cf475e2874e62c133954023
- https://git.kernel.org/stable/c/aeeae8feeaae4445a86f9815273e81f902dc1f5b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38368
In the Linux kernel, the following vulnerability has been resolved: misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe() The returned value, pfsm->miscdev.name, from devm_kasprintf() could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool.
Modified: 2025-11-18
CVE-2025-38369
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated. This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point. In this case, when the user driver detaches, the WQ is destroyed but it still calls destroy_workqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists.
Modified: 2025-12-16
CVE-2025-38371
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Disable interrupts before resetting the GPU Currently, an interrupt can be triggered during a GPU reset, which can lead to GPU hangs and NULL pointer dereference in an interrupt context as shown in the following trace: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Before resetting the G ---truncated---
- https://git.kernel.org/stable/c/226862f50a7a88e4e4de9abbf36c64d19acd6fd0
- https://git.kernel.org/stable/c/2446e25e9246e0642a41d91cbf54c33b275da3c3
- https://git.kernel.org/stable/c/387da3b6d1a90e3210bc9a7fb56703bdad2ac18a
- https://git.kernel.org/stable/c/576a6739e08ac06c67f2916f71204557232388b0
- https://git.kernel.org/stable/c/9ff95ed0371aec4d9617e478e9c69cde86cd7c38
- https://git.kernel.org/stable/c/b9c403d1236cecb10dd0246a30d81e4b265f8e8d
- https://git.kernel.org/stable/c/c8851a6ab19d9f390677c42a3cc01ff9b2eb6241
- https://git.kernel.org/stable/c/dc805c927cd832bb8f790b756880ae6c769d5fbc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38372
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix unsafe xarray access in implicit ODP handling __xa_store() and __xa_erase() were used without holding the proper lock, which led to a lockdep warning due to unsafe RCU usage. This patch replaces them with xa_store() and xa_erase(), which perform the necessary locking internally. ============================= WARNING: suspicious RCPU usage 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted ----------------------------- ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by kworker/u136:0/219: at: process_one_work+0xbe4/0x15f0 process_one_work+0x75c/0x15f0 pagefault_mr+0x9a5/0x1390 [mlx5_ib] stack backtrace: CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] Call Trace: dump_stack_lvl+0xa8/0xc0 lockdep_rcu_suspicious+0x1e6/0x260 xas_create+0xb8a/0xee0 xas_store+0x73/0x14c0 __xa_store+0x13c/0x220 ? xa_store_range+0x390/0x390 ? spin_bug+0x1d0/0x1d0 pagefault_mr+0xcb5/0x1390 [mlx5_ib] ? _raw_spin_unlock+0x1f/0x30 mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib] ? lockdep_hardirqs_on_prepare+0x400/0x400 ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib] process_one_work+0x7db/0x15f0 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? assign_work+0x168/0x240 worker_thread+0x57d/0xcd0 ? rescuer_thread+0xc40/0xc40 kthread+0x3b3/0x800 ? kthread_is_per_cpu+0xb0/0xb0 ? lock_downgrade+0x680/0x680 ? do_raw_spin_lock+0x12d/0x270 ? spin_bug+0x1d0/0x1d0 ? finish_task_switch.isra.0+0x284/0x9e0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork+0x2d/0x70 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork_asm+0x11/0x20
Modified: 2025-11-19
CVE-2025-38373
In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix potential deadlock in MR deregistration The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock. The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | → revoke_mr() | → mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | → mutex_lock(&dev->cache.rb_lock) | → mlx5r_cache_create_ent_locked() | → kzalloc(GFP_KERNEL) | → fs_reclaim() | → mmu_notifier_invalidate_range_start() | → mlx5_ib_invalidate_range() | → mutex_lock(&umem_odp->umem_mutex) → cache_ent_find_and_store() | → mutex_lock(&dev->cache.rb_lock) | Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex. Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path. This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path. The following lockdep warning demonstrates the deadlock: python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated---
Modified: 2025-11-19
CVE-2025-38374
In the Linux kernel, the following vulnerability has been resolved: optee: ffa: fix sleep in atomic context The OP-TEE driver registers the function notif_callback() for FF-A notifications. However, this function is called in an atomic context leading to errors like this when processing asynchronous notifications: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13 | Hardware name: linux,dummy-virt (DT) | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | optee_get_msg_arg+0x7c/0x21c | simple_call_with_arg+0x50/0xc0 | optee_do_bottom_half+0x14/0x20 | notif_callback+0x3c/0x48 | handle_notif_callbacks+0x9c/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 Fix this by adding work queue to process the notification in a non-atomic context.
Modified: 2025-12-16
CVE-2025-38375
In the Linux kernel, the following vulnerability has been resolved: virtio-net: ensure the received length does not exceed allocated size In xdp_linearize_page, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check.
- https://git.kernel.org/stable/c/11f2d0e8be2b5e784ac45fa3da226492c3e506d8
- https://git.kernel.org/stable/c/315dbdd7cdf6aa533829774caaf4d25f1fd20e73
- https://git.kernel.org/stable/c/6aca3dad2145e864dfe4d1060f45eb1bac75dd58
- https://git.kernel.org/stable/c/773e95c268b5d859f51f7547559734fd2a57660c
- https://git.kernel.org/stable/c/80b971be4c37a4d23a7f1abc5ff33dc7733d649b
- https://git.kernel.org/stable/c/982beb7582c193544eb9c6083937ec5ac1c9d651
- https://git.kernel.org/stable/c/bc68bc3563344ccdc57d1961457cdeecab8f81ef
- https://git.kernel.org/stable/c/ddc8649d363141fb3371dd81a73e1cb4ef8ed1e1
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38376
In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume Shawn and John reported a hang issue during system suspend as below: - USB gadget is enabled as Ethernet - There is data transfer over USB Ethernet (scp a big file between host and device) - Device is going in/out suspend (echo mem > /sys/power/state) The root cause is the USB device controller is suspended but the USB bus is still active which caused the USB host continues to transfer data with device and the device continues to queue USB requests (in this case, a delayed TCP ACK packet trigger the issue) after controller is suspended, however the USB controller clock is already gated off. Then if udc driver access registers after that point, the system will hang. The correct way to avoid such issue is to disconnect device from host when the USB bus is not at suspend state. Then the host will receive disconnect event and stop data transfer in time. To continue make USB gadget device work after system resume, this will reconnect device automatically. To make usb wakeup work if USB bus is already at suspend state, this will keep connection for it only when USB device controller has enabled wakeup capability.
Modified: 2025-12-18
CVE-2025-38377
In the Linux kernel, the following vulnerability has been resolved: rose: fix dangling neighbour pointers in rose_rt_device_down() There are two bugs in rose_rt_device_down() that can cause use-after-free: 1. The loop bound `t->count` is modified within the loop, which can cause the loop to terminate early and miss some entries. 2. When removing an entry from the neighbour array, the subsequent entries are moved up to fill the gap, but the loop index `i` is still incremented, causing the next entry to be skipped. For example, if a node has three neighbours (A, A, B) with count=3 and A is being removed, the second A is not checked. i=0: (A, A, B) -> (A, B) with count=2 ^ checked i=1: (A, B) -> (A, B) with count=2 ^ checked (B, not A!) i=2: (doesn't occur because i < count is false) This leaves the second A in the array with count=2, but the rose_neigh structure has been freed. Code that accesses these entries assumes that the first `count` entries are valid pointers, causing a use-after-free when it accesses the dangling pointer. Fix both issues by iterating over the array in reverse order with a fixed loop bound. This ensures that all entries are examined and that the removal of an entry doesn't affect subsequent iterations.
- https://git.kernel.org/stable/c/2b952dbb32fef835756f07ff0cd77efbb836dfea
- https://git.kernel.org/stable/c/2c6c82ee074bfcfd1bc978ec45bfea37703d840a
- https://git.kernel.org/stable/c/34a500caf48c47d5171f4aa1f237da39b07c6157
- https://git.kernel.org/stable/c/446ac00b86be1670838e513b643933d78837d8db
- https://git.kernel.org/stable/c/7a1841c9609377e989ec41c16551309ce79c39e4
- https://git.kernel.org/stable/c/94e0918e39039c47ddceb609500817f7266be756
- https://git.kernel.org/stable/c/b6b232e16e08c6dc120672b4753392df0d28c1b4
- https://git.kernel.org/stable/c/fe62a35fb1f77f494ed534fc69a9043dc5a30ce1
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38381
In the Linux kernel, the following vulnerability has been resolved: Input: cs40l50-vibra - fix potential NULL dereference in cs40l50_upload_owt() The cs40l50_upload_owt() function allocates memory via kmalloc() without checking for allocation failure, which could lead to a NULL pointer dereference. Return -ENOMEM in case allocation fails.
Modified: 2025-12-16
CVE-2025-38382
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix iteration of extrefs during log replay At __inode_add_ref() when processing extrefs, if we jump into the next label we have an undefined value of victim_name.len, since we haven't initialized it before we did the goto. This results in an invalid memory access in the next iteration of the loop since victim_name.len was not initialized to the length of the name of the current extref. Fix this by initializing victim_name.len with the current extref's name length.
- https://git.kernel.org/stable/c/2d11d274e2e1d7c79e2ca8461ce3ff3a95c11171
- https://git.kernel.org/stable/c/539969fc472886a1d63565459514d47e27fef461
- https://git.kernel.org/stable/c/54a7081ed168b72a8a2d6ef4ba3a1259705a2926
- https://git.kernel.org/stable/c/7ac790dc2ba00499a8d671d4a24de4d4ad27e234
- https://git.kernel.org/stable/c/aee57a0293dca675637e5504709f9f8fd8e871be
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38383
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix data race in show_numa_info() The following data-race was found in show_numa_info(): ================================================================== BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 .... write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 .... value changed: 0x0000008f -> 0x00000000 ================================================================== According to this report,there is a read/write data-race because m->private is accessible to multiple CPUs. To fix this, instead of allocating the heap in proc_vmalloc_init() and passing the heap address to m->private, vmalloc_info_show() should allocate the heap.
Modified: 2025-12-16
CVE-2025-38384
In the Linux kernel, the following vulnerability has been resolved: mtd: spinand: fix memory leak of ECC engine conf Memory allocated for the ECC engine conf is not released during spinand cleanup. Below kmemleak trace is seen for this memory leak: unreferenced object 0xffffff80064f00e0 (size 8): comm "swapper/0", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160 Fix the leak by calling nanddev_ecc_engine_cleanup() inside spinand_cleanup().
- https://git.kernel.org/stable/c/6463cbe08b0cbf9bba8763306764f5fd643023e1
- https://git.kernel.org/stable/c/68d3417305ee100dcad90fd6e5846b22497aa394
- https://git.kernel.org/stable/c/93147abf80a831dd3b5660b3309b4f09546073b2
- https://git.kernel.org/stable/c/c40b207cafd006c610832ba52a81cedee77adcb9
- https://git.kernel.org/stable/c/d5c1e3f32902ab518519d05515ee6030fd6c59ae
- https://git.kernel.org/stable/c/f99408670407abb6493780e38cb4ece3fbb52cfc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38385
In the Linux kernel, the following vulnerability has been resolved:
net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect
Remove redundant netif_napi_del() call from disconnect path.
A WARN may be triggered in __netif_napi_del_locked() during USB device
disconnect:
WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
This happens because netif_napi_del() is called in the disconnect path while
NAPI is still enabled. However, it is not necessary to call netif_napi_del()
explicitly, since unregister_netdev() will handle NAPI teardown automatically
and safely. Removing the redundant call avoids triggering the warning.
Full trace:
lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV
lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV
lan78xx 1-1:1.0 enu1: Link is Down
lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV
------------[ cut here ]------------
WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
Modules linked in: flexcan can_dev fuse
CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT
Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)
Workqueue: usb_hub_wq hub_event
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __netif_napi_del_locked+0x2b4/0x350
lr : __netif_napi_del_locked+0x7c/0x350
sp : ffffffc085b673c0
x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8
x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb
x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000
x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000
x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028
x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8
x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000
x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001
x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000
Call trace:
__netif_napi_del_locked+0x2b4/0x350 (P)
lan78xx_disconnect+0xf4/0x360
usb_unbind_interface+0x158/0x718
device_remove+0x100/0x150
device_release_driver_internal+0x308/0x478
device_release_driver+0x1c/0x30
bus_remove_device+0x1a8/0x368
device_del+0x2e0/0x7b0
usb_disable_device+0x244/0x540
usb_disconnect+0x220/0x758
hub_event+0x105c/0x35e0
process_one_work+0x760/0x17b0
worker_thread+0x768/0xce8
kthread+0x3bc/0x690
ret_from_fork+0x10/0x20
irq event stamp: 211604
hardirqs last enabled at (211603): [
- https://git.kernel.org/stable/c/17a37b9a5dd945d86110838fb471e7139ba993a2
- https://git.kernel.org/stable/c/510a6095d754df9d727f644ec5076b7929d6c9ea
- https://git.kernel.org/stable/c/6c7ffc9af7186ed79403a3ffee9a1e5199fc7450
- https://git.kernel.org/stable/c/7135056a49035597198280820c61b8c5dbe4a1d0
- https://git.kernel.org/stable/c/968a419c95131e420f12bbdba19e96e2f6b071c4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38386
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Refuse to evaluate a method if arguments are missing As reported in [1], a platform firmware update that increased the number of method parameters and forgot to update a least one of its callers, caused ACPICA to crash due to use-after-free. Since this a result of a clear AML issue that arguably cannot be fixed up by the interpreter (it cannot produce missing data out of thin air), address it by making ACPICA refuse to evaluate a method if the caller attempts to pass fewer arguments than expected to it.
- https://git.kernel.org/stable/c/18ff4ed6a33a7e3f2097710eacc96bea7696e803
- https://git.kernel.org/stable/c/2219e49857ffd6aea1b1ca5214d3270f84623a16
- https://git.kernel.org/stable/c/4305d936abde795c2ef6ba916de8f00a50f64d2d
- https://git.kernel.org/stable/c/6fcab2791543924d438e7fa49276d0998b0a069f
- https://git.kernel.org/stable/c/ab1e8491c19eb2ea0fda81ef28e841c7cb6399f5
- https://git.kernel.org/stable/c/b49d224d1830c46e20adce2a239c454cdab426f1
- https://git.kernel.org/stable/c/c9e4da550ae196132b990bd77ed3d8f2d9747f87
- https://git.kernel.org/stable/c/d547779e72cea9865b732cd45393c4cd02b3598e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38387
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insert The obj_event may be loaded immediately after inserted, then if the list_head is not initialized then we may get a poisonous pointer. This fixes the crash below: mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E) [last unloaded: mst_pci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatch_event_fd+0x68/0x300 [mlx5_ib] lr : devx_event_notifier+0xcc/0x228 [mlx5_ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatch_event_fd+0x68/0x300 [mlx5_ib] devx_event_notifier+0xcc/0x228 [mlx5_ib] atomic_notifier_call_chain+0x58/0x80 mlx5_eq_async_int+0x148/0x2b0 [mlx5_core] atomic_notifier_call_chain+0x58/0x80 irq_int_handler+0x20/0x30 [mlx5_core] __handle_irq_event_percpu+0x60/0x220 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x58/0x158 handle_fasteoi_irq+0xfc/0x188 generic_handle_irq+0x34/0x48 ...
- https://git.kernel.org/stable/c/00ed215f593876385451423924fe0358c556179c
- https://git.kernel.org/stable/c/23a3b32a274a8d6f33480d0eff436eb100981651
- https://git.kernel.org/stable/c/716b555fc0580c2aa4c2c32ae4401c7e3ad9873e
- https://git.kernel.org/stable/c/8edab8a72d67742f87e9dc2e2b0cdfddda5dc29a
- https://git.kernel.org/stable/c/93fccfa71c66a4003b3d2fef3a38de7307e14a4e
- https://git.kernel.org/stable/c/972e968aac0dce8fe8faad54f6106de576695d8e
- https://git.kernel.org/stable/c/9a28377a96fb299c180dd9cf0be3b0a038a52d4e
- https://git.kernel.org/stable/c/e8069711139249994450c214cec152b917b959e0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38388
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It results in the below kernel warnings: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 To address this, replace the mutex with an rwlock to protect the notifier hashtable accesses. This ensures that read-side locking does not sleep and multiple readers can acquire the lock concurrently, avoiding unnecessary contention and potential deadlocks. Writer access remains exclusive, preserving correctness. This change resolves warnings from lockdep about potential sleep in atomic context.
Modified: 2025-12-16
CVE-2025-38389
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Fix timeline left held on VMA alloc error
The following error has been reported sporadically by CI when a test
unbinds the i915 driver on a ring submission platform:
<4> [239.330153] ------------[ cut here ]------------
<4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)
<4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]
...
<4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]
...
<4> [239.330942] Call Trace:
<4> [239.330944]
- https://git.kernel.org/stable/c/40e09506aea1fde1f3e0e04eca531bbb23404baf
- https://git.kernel.org/stable/c/4c778c96e469fb719b11683e0a3be8ea68052fa2
- https://git.kernel.org/stable/c/5a7ae7bebdc4c2ecd48a2c061319956f65c09473
- https://git.kernel.org/stable/c/60b757730884e4a223152a68d9b5f625dac94119
- https://git.kernel.org/stable/c/a5aa7bc1fca78c7fa127d9e33aa94a0c9066c1d6
- https://git.kernel.org/stable/c/c542d62883f62ececafcb630a1c5010133826bea
- https://git.kernel.org/stable/c/e47d7d6edc40a6ace7cc04e5893759fee68569f5
- https://git.kernel.org/stable/c/f10af34261448610d4048ac6e6af87f80e3881a4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38390
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix memory leak by freeing notifier callback node Commit e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") adds support for notifier callbacks by allocating and inserting a callback node into a hashtable during registration of notifiers. However, during unregistration, the code only removes the node from the hashtable without freeing the associated memory, resulting in a memory leak. Resolve the memory leak issue by ensuring the allocated notifier callback node is properly freed after it is removed from the hashtable entry.
Modified: 2025-12-23
CVE-2025-38391
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: do not index invalid pin_assignments A poorly implemented DisplayPort Alt Mode port partner can indicate that its pin assignment capabilities are greater than the maximum value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show will cause a BRK exception due to an out of bounds array access. Prevent for loop in pin_assignment_show from accessing invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop condition.
- https://git.kernel.org/stable/c/114a977e0f6bf278e05eade055e13fc271f69cf7
- https://git.kernel.org/stable/c/2f535517b5611b7221ed478527e4b58e29536ddf
- https://git.kernel.org/stable/c/45e9444b3b97eaf51a5024f1fea92f44f39b50c6
- https://git.kernel.org/stable/c/47cb5d26f61d80c805d7de4106451153779297a1
- https://git.kernel.org/stable/c/5581e694d3a1c2f32c5a51d745c55b107644e1f8
- https://git.kernel.org/stable/c/621d5a3ef0231ab242f2d31eecec40c38ca609c5
- https://git.kernel.org/stable/c/af4db5a35a4ef7a68046883bfd12468007db38f1
- https://git.kernel.org/stable/c/c93bc959788ed9a1af7df57cb539837bdf790cee
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38392
In the Linux kernel, the following vulnerability has been resolved:
idpf: convert control queue mutex to a spinlock
With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated
on module load:
[ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578
[ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager
[ 324.701689] preempt_count: 201, expected: 0
[ 324.701693] RCU nest depth: 0, expected: 0
[ 324.701697] 2 locks held by NetworkManager/1582:
[ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0
[ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870
[ 324.701749] Preemption disabled at:
[ 324.701752] [
Modified: 2025-12-23
CVE-2025-38393
In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero. It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.
- https://git.kernel.org/stable/c/08287df60bac5b008b6bcdb03053988335d3d282
- https://git.kernel.org/stable/c/1f4da20080718f258e189a2c5f515385fa393da6
- https://git.kernel.org/stable/c/864a54c1243ed3ca60baa4bc492dede1361f4c83
- https://git.kernel.org/stable/c/8846fd02c98da8b79e6343a20e6071be6f372180
- https://git.kernel.org/stable/c/8ca65fa71024a1767a59ffbc6a6e2278af84735e
- https://git.kernel.org/stable/c/c01776287414ca43412d1319d2877cbad65444ac
- https://git.kernel.org/stable/c/e4b13885e7ef1e64e45268feef1e5f0707c47e72
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38395
In the Linux kernel, the following vulnerability has been resolved: regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But the memory is allocated for only one pointer. This will lead to out-of-bounds access later in the code if 'config::ngpios' is > 1. So fix the code to allocate enough memory to hold 'config::ngpios' of GPIO descriptors. While at it, also move the check for memory allocation failure to be below the allocation to make it more readable.
- https://git.kernel.org/stable/c/24418bc77a66cb5be9f5a837431ba3674ed8b52f
- https://git.kernel.org/stable/c/3830ab97cda9599872625cc0dc7b00160193634f
- https://git.kernel.org/stable/c/56738cbac3bbb1d39a71a07f57484dec1db8b239
- https://git.kernel.org/stable/c/9fe71972869faed1f8f9b3beb9040f9c1b300c79
- https://git.kernel.org/stable/c/a1e12fac214d4f49fcb186dbdf9c5592e7fa0a7a
- https://git.kernel.org/stable/c/a3cd5ae7befbac849e0e0529c94ca04e8093cfd2
- https://git.kernel.org/stable/c/c9764fd88bc744592b0604ccb6b6fc1a5f76b4e3
- https://git.kernel.org/stable/c/e4d19e5d71b217940e33f2ef6c6962b7b68c5606
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38396
In the Linux kernel, the following vulnerability has been resolved: fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass Export anon_inode_make_secure_inode() to allow KVM guest_memfd to create anonymous inodes with proper security context. This replaces the current pattern of calling alloc_anon_inode() followed by inode_init_security_anon() for creating security context manually. This change also fixes a security regression in secretmem where the S_PRIVATE flag was not cleared after alloc_anon_inode(), causing LSM/SELinux checks to be bypassed for secretmem file descriptors. As guest_memfd currently resides in the KVM module, we need to export this symbol for use outside the core kernel. In the future, guest_memfd might be moved to core-mm, at which point the symbols no longer would have to be exported. When/if that happens is still unclear.
- https://git.kernel.org/stable/c/66d29d757c968d2bee9124816da5d718eb352959
- https://git.kernel.org/stable/c/6ca45ea48530332a4ba09595767bd26d3232743b
- https://git.kernel.org/stable/c/cbe4134ea4bc493239786220bd69cb8a13493190
- https://git.kernel.org/stable/c/e3eed01347721cd7a8819568161c91d538fbf229
- https://git.kernel.org/stable/c/f94c422157f3e43dd31990567b3e5d54b3e5b32b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38399
In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port() The function core_scsi3_decode_spec_i_port(), in its error code path, unconditionally calls core_scsi3_lunacl_undepend_item() passing the dest_se_deve pointer, which may be NULL. This can lead to a NULL pointer dereference if dest_se_deve remains unset. SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg Unable to handle kernel paging request at virtual address dfff800000000012 Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod] Fix this by adding a NULL check before calling core_scsi3_lunacl_undepend_item()
- https://git.kernel.org/stable/c/1129e0e0a833acf90429e0f13951068d5f026e4f
- https://git.kernel.org/stable/c/1627dda4d70ceb1ba62af2e401af73c09abb1eb5
- https://git.kernel.org/stable/c/55dfffc5e94730370b08de02c0cf3b7c951bbe9e
- https://git.kernel.org/stable/c/70ddb8133fdb512d4b1f2b4fd1c9e518514f182c
- https://git.kernel.org/stable/c/7296c938df2445f342be456a6ff0b3931d97f4e5
- https://git.kernel.org/stable/c/c412185d557578d3f936537ed639c4ffaaed4075
- https://git.kernel.org/stable/c/d8ab68bdb294b09a761e967dad374f2965e1913f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38400
In the Linux kernel, the following vulnerability has been resolved:
nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.
syzbot reported a warning below [1] following a fault injection in
nfs_fs_proc_net_init(). [0]
When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.
Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning
is logged as the directory is not empty.
Let's handle the error of nfs_fs_proc_net_init() properly.
[0]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
- https://git.kernel.org/stable/c/3c94212b57bedec3a386ef3da1ef00602f5c3d1d
- https://git.kernel.org/stable/c/412534a1fb76958b88dca48360c6f3ad4f3390f4
- https://git.kernel.org/stable/c/6acf340f8c1d296bcf535986175f5d0d6f2aab09
- https://git.kernel.org/stable/c/7701c245ff1ac1a126bf431e72b24547519046ff
- https://git.kernel.org/stable/c/8785701fd7cd52ae74c0d2b35b82568df74e9dbb
- https://git.kernel.org/stable/c/b92397ce96743e4cc090207e2df2a856cb4cef08
- https://git.kernel.org/stable/c/d0877c479f44fe475f4c8c02c88ce9ad43e90298
- https://git.kernel.org/stable/c/e8d6f3ab59468e230f3253efe5cb63efa35289f7
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38401
In the Linux kernel, the following vulnerability has been resolved: mtk-sd: Prevent memory corruption from DMA map failure If msdc_prepare_data() fails to map the DMA region, the request is not prepared for data receiving, but msdc_start_data() proceeds the DMA with previous setting. Since this will lead a memory corruption, we have to stop the request operation soon after the msdc_prepare_data() fails to prepare it.
- https://git.kernel.org/stable/c/3419bc6a7b65cbbb91417bb9970208478e034c79
- https://git.kernel.org/stable/c/48bf4f3dfcdab02b22581d8e350a2d23130b72c0
- https://git.kernel.org/stable/c/5ac9e9e2e9cd6247d8c2d99780eae4556049e1cc
- https://git.kernel.org/stable/c/61cdd663564674ea21ceb50aa9d3697cbe9e45f9
- https://git.kernel.org/stable/c/63e8953f16acdcb23e2d4dd8a566d3c34df3e200
- https://git.kernel.org/stable/c/a5f5f67b284d81776d4a3eb1f8607e4b7f91f11c
- https://git.kernel.org/stable/c/d54771571f74a82c59830a32e76af78a8e57ac69
- https://git.kernel.org/stable/c/f5de469990f19569627ea0dd56536ff5a13beaa3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38402
In the Linux kernel, the following vulnerability has been resolved:
idpf: return 0 size for RSS key if not supported
Returning -EOPNOTSUPP from function returning u32 is leading to
cast and invalid size value as a result.
-EOPNOTSUPP as a size probably will lead to allocation fail.
Command: ethtool -x eth0
It is visible on all devices that don't have RSS caps set.
[ 136.615917] Call Trace:
[ 136.615921]
Modified: 2025-12-23
CVE-2025-38403
In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: Clear the vmci transport packet properly when initializing it In vmci_transport_packet_init memset the vmci_transport_packet before populating the fields to avoid any uninitialised data being left in the structure.
- https://git.kernel.org/stable/c/0a01021317375b8d1895152f544421ce49299eb1
- https://git.kernel.org/stable/c/19c2cc01ff9a8031398a802676ffb0f4692dd95d
- https://git.kernel.org/stable/c/1c1bcb0e78230f533b4103e8cf271d17c3f469f0
- https://git.kernel.org/stable/c/223e2288f4b8c262a864e2c03964ffac91744cd5
- https://git.kernel.org/stable/c/2d44723a091bc853272e1a51a488a3d22b80be5e
- https://git.kernel.org/stable/c/75705b44e0b9aaa74f4c163d93d388bcba9e386a
- https://git.kernel.org/stable/c/94d0c326cb3ee6b0f8bd00e209550b93fcc5c839
- https://git.kernel.org/stable/c/e9a673153d578fd439919a24e99851b2f87ecbce
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38405
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix memory leak of bio integrity If nvmet receives commands with metadata there is a continuous memory leak of kmalloc-128 slab or more precisely bio->bi_integrity. Since commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio") each user of bio_init has to use bio_uninit as well. Otherwise the bio integrity is not getting free. Nvmet uses bio_init for inline bios. Uninit the inline bio to complete deallocation of integrity in bio.
Modified: 2025-12-23
CVE-2025-38406
In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: remove WARN on bad firmware input If the firmware gives bad input, that's nothing to do with the driver's stack at this point etc., so the WARN_ON() doesn't add any value. Additionally, this is one of the top syzbot reports now. Just print a message, and as an added bonus, print the sizes too.
- https://git.kernel.org/stable/c/27d07deea35ae67f2e75913242e25bdb7e1114e5
- https://git.kernel.org/stable/c/327997afbb5e62532c28c1861ab5534c01969c9a
- https://git.kernel.org/stable/c/347827bd0c5680dac2dd59674616840c4d5154f1
- https://git.kernel.org/stable/c/46b47d4b06fa7f234d93f0f8ac43798feafcff89
- https://git.kernel.org/stable/c/7a2afdc5af3b82b601f6a2f0d1c90d5f0bc27aeb
- https://git.kernel.org/stable/c/89bd133529a4d2d68287128b357e49adc00ec690
- https://git.kernel.org/stable/c/e6c49f0b203a987c306676d241066451b74db1a5
- https://git.kernel.org/stable/c/e7417421d89358da071fd2930f91e67c7128fbff
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38407
In the Linux kernel, the following vulnerability has been resolved:
riscv: cpu_ops_sbi: Use static array for boot_data
Since commit 6b9f29b81b15 ("riscv: Enable pcpu page first chunk
allocator"), if NUMA is enabled, the page percpu allocator may be used
on very sparse configurations, or when requested on boot with
percpu_alloc=page.
In that case, percpu data gets put in the vmalloc area. However,
sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,
and simply assumes that __pa() would work. This causes the just started
hart to immediately access an invalid address and hang.
Fortunately, struct sbi_hart_boot_data is not too large, so we can
simply allocate an array for boot_data statically, putting it in the
kernel image.
This fixes NUMA=y SMP boot on Sophgo SG2042.
To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then
run with:
qemu-system-riscv64 -M virt -smp 2 -nographic \
-kernel arch/riscv/boot/Image \
-append "percpu_alloc=page"
Kernel output:
[ 0.000000] Booting Linux on hartid 0
[ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025
...
[ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712
...
[ 0.083192] smp: Bringing up secondary CPUs ...
[ 0.086722] ------------[ cut here ]------------
[ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)
[ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8
[ 0.088376] Modules linked in:
[ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE
[ 0.088833] Hardware name: riscv-virtio,qemu (DT)
[ 0.088948] epc : __virt_to_phys+0xae/0xe8
[ 0.089001] ra : __virt_to_phys+0xae/0xe8
[ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0
[ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976
[ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0
[ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000
[ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
[ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
[ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001
[ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec
[ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000
[ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7
[ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8
[ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003
[ 0.090101] [
Modified: 2026-03-17
CVE-2025-38408
In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing.
- https://git.kernel.org/stable/c/186df821de0f34490ed5fc0861243748b2483861
- https://git.kernel.org/stable/c/19bd7597858dd15802c1d99fcc38e528f469080a
- https://git.kernel.org/stable/c/7f73d1def72532bac4d55ea8838f457a6bed955c
- https://git.kernel.org/stable/c/8a2277a3c9e4cc5398f80821afe7ecbe9bdf2819
- https://git.kernel.org/stable/c/c71aa4bb528ae6f8fd7577a0a39e5a03c60b04fb
- https://git.kernel.org/stable/c/ec3656a8cb428d763def32bc2fa695f94be23629
Modified: 2025-12-23
CVE-2025-38409
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix another leak in the submit error path put_unused_fd() doesn't free the installed file, if we've already done fd_install(). So we need to also free the sync_file. Patchwork: https://patchwork.freedesktop.org/patch/653583/
- https://git.kernel.org/stable/c/00b3401f692082ddf6342500d1be25560bba46d4
- https://git.kernel.org/stable/c/30d3819b0b9173e31b84d662a592af8bad351427
- https://git.kernel.org/stable/c/3f6ce8433a9035b0aa810e1f5b708e9dc1c367b0
- https://git.kernel.org/stable/c/c40ad1c04d306f7fde26337fdcf8a5979657d93f
- https://git.kernel.org/stable/c/f681c2aa8676a890eacc84044717ab0fd26e058f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38410
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix a fence leak in submit error path In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Patchwork: https://patchwork.freedesktop.org/patch/653584/
- https://git.kernel.org/stable/c/0dc817f852e5f8ec8501d19ef7dcc01affa181d0
- https://git.kernel.org/stable/c/0eaa495b3d5710e5ba72051d2e01bb28292c625c
- https://git.kernel.org/stable/c/201eba5c9652a900c0b248070263f9acd3735689
- https://git.kernel.org/stable/c/5d319f75ccf7f0927425a7545aa1a22b3eedc189
- https://git.kernel.org/stable/c/5deab0fa6cfd0cd7def17598db15ceb84f950584
- https://git.kernel.org/stable/c/fe2695b2f63bd77e0e03bc0fc779164115bb4699
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38412
In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.
- https://git.kernel.org/stable/c/0deb3eb78ebf225cb41aa9b2b2150f46cbfd359e
- https://git.kernel.org/stable/c/5df3b870bc389a1767c72448a3ce1c576ef4deab
- https://git.kernel.org/stable/c/68e9963583d11963ceca5d276e9c44684509f759
- https://git.kernel.org/stable/c/92c2d914b5337431d885597a79a3a3d9d55e80b7
- https://git.kernel.org/stable/c/aaf847dcb4114fe8b25d4c1c790bedcb6088cb3d
- https://git.kernel.org/stable/c/eb617dd25ca176f3fee24f873f0fd60010773d67
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38413
In the Linux kernel, the following vulnerability has been resolved: virtio-net: xsk: rx: fix the frame's length check When calling buf_to_xdp, the len argument is the frame data's length without virtio header's length (vi->hdr_len). We check that len with xsk_pool_get_rx_frame_size() + vi->hdr_len to ensure the provided len does not larger than the allocated chunk size. The additional vi->hdr_len is because in virtnet_add_recvbuf_xsk, we use part of XDP_PACKET_HEADROOM for virtio header and ask the vhost to start placing data from hard_start + XDP_PACKET_HEADROOM - vi->hdr_len not hard_start + XDP_PACKET_HEADROOM But the first buffer has virtio_header, so the maximum frame's length in the first buffer can only be xsk_pool_get_rx_frame_size() not xsk_pool_get_rx_frame_size() + vi->hdr_len like in the current check. This commit adds an additional argument to buf_to_xdp differentiate between the first buffer and other ones to correctly calculate the maximum frame's length.
Modified: 2025-11-19
CVE-2025-38414
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850 GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms. Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Modified: 2025-12-23
CVE-2025-38415
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check return result of sb_min_blocksize Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize().
- https://git.kernel.org/stable/c/0aff95d9bc7fb5400ca8af507429c4b067bdb425
- https://git.kernel.org/stable/c/295ab18c2dbce8d0ac6ecf7c5187e16e1ac8b282
- https://git.kernel.org/stable/c/4f99357dadbf9c979ad737156ad4c37fadf7c56b
- https://git.kernel.org/stable/c/549f9e3d7b60d53808c98b9fde49b4f46d0524a5
- https://git.kernel.org/stable/c/5c51aa862cbeed2f3887f0382a2708956710bd68
- https://git.kernel.org/stable/c/6abf6b78c6fb112eee495f5636ffcc350dd2ce25
- https://git.kernel.org/stable/c/734aa85390ea693bb7eaf2240623d41b03705c84
- https://git.kernel.org/stable/c/db7096ea160e40d78c67fce52e7cc51bde049497
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38416
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: uart: Set tty->disc_data only in success path Setting tty->disc_data before opening the NCI device means we need to clean it up on error paths. This also opens some short window if device starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded (broken hardware?). Close the window by exposing tty->disc_data only on the success path, when opening of the NCI device and try_module_get() succeeds. The code differs in error path in one aspect: tty->disc_data won't be ever assigned thus NULL-ified. This however should not be relevant difference, because of "tty->disc_data=NULL" in nci_uart_tty_open().
- https://git.kernel.org/stable/c/000bfbc6bc334a93fffca8f5aa9583e7b6356cb5
- https://git.kernel.org/stable/c/55c3dbd8389636161090a2b2b6d2d709b9602e9c
- https://git.kernel.org/stable/c/a514fca2b8e95838a3ba600f31a18fa60b76d893
- https://git.kernel.org/stable/c/a8acc7080ad55c5402a1b818b3008998247dda87
- https://git.kernel.org/stable/c/ac6992f72bd8e22679c1e147ac214de6a7093c23
- https://git.kernel.org/stable/c/dc7722619a9c307e9938d735cf4a2210d3d48dcb
- https://git.kernel.org/stable/c/e9799db771b2d574d5bf0dfb3177485e5f40d4d6
- https://git.kernel.org/stable/c/fc27ab48904ceb7e4792f0c400f1ef175edf16fe
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38417
In the Linux kernel, the following vulnerability has been resolved: ice: fix eswitch code memory leak in reset scenario Add simple eswitch mode checker in attaching VF procedure and allocate required port representor memory structures only in switchdev mode. The reset flows triggers VF (if present) detach/attach procedure. It might involve VF port representor(s) re-creation if the device is configured is switchdev mode (not legacy one). The memory was blindly allocated in current implementation, regardless of the mode and not freed if in legacy mode. Kmemeleak trace: unreferenced object (percpu) 0x7e3bce5b888458 (size 40): comm "bash", pid 1784, jiffies 4295743894 hex dump (first 32 bytes on cpu 45): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): pcpu_alloc_noprof+0x4c4/0x7c0 ice_repr_create+0x66/0x130 [ice] ice_repr_create_vf+0x22/0x70 [ice] ice_eswitch_attach_vf+0x1b/0xa0 [ice] ice_reset_all_vfs+0x1dd/0x2f0 [ice] ice_pci_err_resume+0x3b/0xb0 [ice] pci_reset_function+0x8f/0x120 reset_store+0x56/0xa0 kernfs_fop_write_iter+0x120/0x1b0 vfs_write+0x31c/0x430 ksys_write+0x61/0xd0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Testing hints (ethX is PF netdev): - create at least one VF echo 1 > /sys/class/net/ethX/device/sriov_numvfs - trigger the reset echo 1 > /sys/class/net/ethX/device/reset
Modified: 2025-12-23
CVE-2025-38418
In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Release rproc->clean_table after rproc_attach() fails When rproc->state = RPROC_DETACHED is attached to remote processor through rproc_attach(), if rproc_handle_resources() returns failure, then the clean table should be released, otherwise the following memory leak will occur. unreferenced object 0xffff000086a99800 (size 1024): comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s) hex dump (first 32 bytes): 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............ 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............ backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16):
- https://git.kernel.org/stable/c/3562c09feeb8d8e9d102ce6840e8c7d57a7feb5c
- https://git.kernel.org/stable/c/3ee979709e16a83b257bc9a544a7ff71fd445ea9
- https://git.kernel.org/stable/c/6fe9486d709e4a60990843832501ef6556440ca7
- https://git.kernel.org/stable/c/bcd241230fdbc6005230f80a4f8646ff5a84f15b
- https://git.kernel.org/stable/c/bf876fd9dc2d0c9fff96aef63d4346719f206fc1
- https://git.kernel.org/stable/c/f4ef928ca504c996f9222eb2c59ac6d6eefd9c75
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38419
In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach() When rproc->state = RPROC_DETACHED and rproc_attach() is used to attach to the remote processor, if rproc_handle_resources() returns a failure, the resources allocated by imx_rproc_prepare() should be released, otherwise the following memory leak will occur. Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cleanup() is able to deal with empty lists so it is better to fix the "goto" statements in rproc_attach(). replace the "unprepare_device" goto statement with "clean_up_resources" and get rid of the "unprepare_device" label. unreferenced object 0xffff0000861c5d00 (size 128): comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20
- https://git.kernel.org/stable/c/5434d9f2fd68722b514c14b417b53a8af02c4d24
- https://git.kernel.org/stable/c/7692c9fbedd9087dc9050903f58095915458d9b1
- https://git.kernel.org/stable/c/82208ce9505abb057afdece7c62a14687c52c9ca
- https://git.kernel.org/stable/c/92776ca0ccfe78b9bfe847af206bad641fb11121
- https://git.kernel.org/stable/c/9515d74c9d1ae7308a02e8bd4f894eb8137cf8df
- https://git.kernel.org/stable/c/c56d6ef2711ee51b54f160ad0f25a381561f0287
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38420
In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: do not ping device which has failed to load firmware Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217
- https://git.kernel.org/stable/c/0140d3d37f0f1759d1fdedd854c7875a86e15f8d
- https://git.kernel.org/stable/c/11ef72b3312752c2ff92f3c1e64912be3228ed36
- https://git.kernel.org/stable/c/15d25307692312cec4b57052da73387f91a2e870
- https://git.kernel.org/stable/c/301268dbaac8e9013719e162a000202eac8054be
- https://git.kernel.org/stable/c/4e9ab5c48ad5153cc908dd29abad0cd2a92951e4
- https://git.kernel.org/stable/c/527fad1ae32ffa2d4853a1425fe1c8dbb8c9744c
- https://git.kernel.org/stable/c/8a3734a6f4c05fd24605148f21fb2066690d61b3
- https://git.kernel.org/stable/c/bfeede26e97ce4a15a0b961118de4a0e28c9907a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38422
In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write.
- https://git.kernel.org/stable/c/088279ff18cdc437d6fac5890e0c52c624f78a5b
- https://git.kernel.org/stable/c/3b9935586a9b54d2da27901b830d3cf46ad66a1e
- https://git.kernel.org/stable/c/51318d644c993b3f7a60b8616a6a5adc1e967cd2
- https://git.kernel.org/stable/c/6b4201d74d0a49af2123abf2c9d142e59566714b
- https://git.kernel.org/stable/c/9c41d2a2aa3817946eb613522200cab55513ddaa
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38423
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9375: Fix double free of regulator supplies Driver gets regulator supplies in probe path with devm_regulator_bulk_get(), so should not call regulator_bulk_free() in error and remove paths to avoid double free.
Modified: 2025-12-23
CVE-2025-38424
In the Linux kernel, the following vulnerability has been resolved: perf: Fix sample vs do_exit() Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons. Flip this order by moving up where we stop perf in do_exit(). Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER to abort when the current task does not have an mm (exit_mm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem.
- https://git.kernel.org/stable/c/2ee6044a693735396bb47eeaba1ac3ae26c1c99b
- https://git.kernel.org/stable/c/456019adaa2f5366b89c868dea9b483179bece54
- https://git.kernel.org/stable/c/4f6fc782128355931527cefe3eb45338abd8ab39
- https://git.kernel.org/stable/c/507c9a595bad3abd107c6a8857d7fd125d89f386
- https://git.kernel.org/stable/c/7311970d07c4606362081250da95f2c7901fc0db
- https://git.kernel.org/stable/c/7b8f3c72175c6a63a95cf2e219f8b78e2baad34e
- https://git.kernel.org/stable/c/975ffddfa2e19823c719459d2364fcaa17673964
- https://git.kernel.org/stable/c/a9f6aab7910a0ef2895797f15c947f6d1053160f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38425
In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: check msg length in SMBUS block read For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes.
- https://git.kernel.org/stable/c/3f03f77ce688d02da284174e1884b6065d6159bd
- https://git.kernel.org/stable/c/75a864f21ceeb8c1e8ce1b7589174fec2c3a039e
- https://git.kernel.org/stable/c/a6e04f05ce0b070ab39d5775580e65c7d943da0b
- https://git.kernel.org/stable/c/be5f6a65509cd5675362f15eb0440fb28b0f9d64
- https://git.kernel.org/stable/c/c39d1a9ae4ad66afcecab124d7789722bfe909fa
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38427
In the Linux kernel, the following vulnerability has been resolved: video: screen_info: Relocate framebuffers behind PCI bridges Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory. Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screen_info refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself. Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v3: - Only use struct pci_bus_region for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb
Modified: 2025-12-23
CVE-2025-38428
In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - check record size in ims_pcu_flash_firmware() The "len" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the "len" is too large it could result in memory corruption when we do "memcpy(fragment->data, rec->data, len);"
- https://git.kernel.org/stable/c/17474a56acf708bf6b2d174c06ed26abad0a9fd6
- https://git.kernel.org/stable/c/5a8cd6ae8393e2eaebf51d420d5374821ef2af87
- https://git.kernel.org/stable/c/74661516daee1eadebede8dc607b6830530096ec
- https://git.kernel.org/stable/c/8e03f1c7d50343bf21da54873301bc4fa647479f
- https://git.kernel.org/stable/c/a95ef0199e80f3384eb992889322957d26c00102
- https://git.kernel.org/stable/c/c1b9d140b0807c6aee4bb53e1bfa4e391e3dc204
- https://git.kernel.org/stable/c/d63706d9f73846106fde28b284f08e01b92ce9f1
- https://git.kernel.org/stable/c/e5a2481dc2a0b430f49276d7482793a8923631d6
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38429
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Update read pointer only after buffer is written Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated before the buffer is written, potentially causing race conditions where the host sees an updated read pointer before the buffer is actually written. Updating rd_offset prematurely can lead to the host accessing an uninitialized or incomplete element, resulting in data corruption. Invoke the buffer write before updating rd_offset to ensure the element is fully written before signaling its availability.
Modified: 2025-12-22
CVE-2025-38430
In the Linux kernel, the following vulnerability has been resolved: nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request If the request being processed is not a v4 compound request, then examining the cstate can have undefined results. This patch adds a check that the rpc procedure being executed (rq_procinfo) is the NFSPROC4_COMPOUND procedure.
- https://git.kernel.org/stable/c/1244f0b2c3cecd3f349a877006e67c9492b41807
- https://git.kernel.org/stable/c/2c54bd5a380ebf646fb9efbc4ae782ff3a83a5af
- https://git.kernel.org/stable/c/425efc6b3292a3c79bfee4a1661cf043dcd9cf2f
- https://git.kernel.org/stable/c/64a723b0281ecaa59d31aad73ef8e408a84cb603
- https://git.kernel.org/stable/c/7a75a956692aa64211a9e95781af1ec461642de4
- https://git.kernel.org/stable/c/b1d0323a09a29f81572c7391e0d80d78724729c9
- https://git.kernel.org/stable/c/bf78a2706ce975981eb5167f2d3b609eb5d24c19
- https://git.kernel.org/stable/c/e7e943ddd1c6731812357a28e7954ade3a7d8517
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38434
In the Linux kernel, the following vulnerability has been resolved: Revert "riscv: Define TASK_SIZE_MAX for __access_ok()" This reverts commit ad5643cf2f69 ("riscv: Define TASK_SIZE_MAX for __access_ok()"). This commit changes TASK_SIZE_MAX to be LONG_MAX to optimize access_ok(), because the previous TASK_SIZE_MAX (default to TASK_SIZE) requires some computation. The reasoning was that all user addresses are less than LONG_MAX, and all kernel addresses are greater than LONG_MAX. Therefore access_ok() can filter kernel addresses. Addresses between TASK_SIZE and LONG_MAX are not valid user addresses, but access_ok() let them pass. That was thought to be okay, because they are not valid addresses at hardware level. Unfortunately, one case is missed: get_user_pages_fast() happily accepts addresses between TASK_SIZE and LONG_MAX. futex(), for instance, uses get_user_pages_fast(). This causes the problem reported by Robert [1]. Therefore, revert this commit. TASK_SIZE_MAX is changed to the default: TASK_SIZE. This unfortunately reduces performance, because TASK_SIZE is more expensive to compute compared to LONG_MAX. But correctness first, we can think about optimization later, if required.
Modified: 2026-04-18
CVE-2025-38436
In the Linux kernel, the following vulnerability has been resolved: drm/scheduler: signal scheduled fence when kill job When an entity from application B is killed, drm_sched_entity_kill() removes all jobs belonging to that entity through drm_sched_entity_kill_jobs_work(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared. This leads to application A hanging indefinitely while waiting for a dependency that will never be resolved. Fix this issue by ensuring that scheduled fences are properly signaled when an entity is killed, allowing dependent applications to continue execution.
- https://git.kernel.org/stable/c/471db2c2d4f80ee94225a1ef246e4f5011733e50
- https://git.kernel.org/stable/c/8342127a8a65b0673863b106ce32b79c91ae3270
- https://git.kernel.org/stable/c/aa382a8b6ed483e9812d0e63b6d1bdcba0186f29
- https://git.kernel.org/stable/c/aefd0a935625165a6ca36d0258d2d053901555df
- https://git.kernel.org/stable/c/c5734f9bab6f0d40577ad0633af4090a5fda2407
Modified: 2025-12-22
CVE-2025-38437
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potential use-after-free in oplock/lease break ack If ksmbd_iov_pin_rsp return error, use-after-free can happen by accessing opinfo->state and opinfo_put and ksmbd_fd_put could called twice.
- https://git.kernel.org/stable/c/50f930db22365738d9387c974416f38a06e8057e
- https://git.kernel.org/stable/c/8106adc21a2270c16abf69cd74ccd7c79c6e7acd
- https://git.kernel.org/stable/c/815f1161d6dbc4c54ccf94b7d3fdeab34b4d7477
- https://git.kernel.org/stable/c/97c355989928a5f60b228ef5266c1be67a46cdf9
- https://git.kernel.org/stable/c/e38ec88a2b42c494601b1213816d75f0b54d9bf0
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38438
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak. sof_pdata->tplg_filename can have address allocated by kstrdup() and can be overwritten. Memory leak was detected with kmemleak: unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49c/0x6b0 kstrdup+0x46/0xc0 hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] sof_init_environment+0x16f/0xb50 [snd_sof] sof_probe_continue+0x45/0x7c0 [snd_sof] sof_probe_work+0x1e/0x40 [snd_sof] process_one_work+0x894/0x14b0 worker_thread+0x5e5/0xfb0 kthread+0x39d/0x760 ret_from_fork+0x31/0x70 ret_from_fork_asm+0x1a/0x30
Modified: 2025-12-22
CVE-2025-38439
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT
When transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()
with the proper length instead of 0. This bug triggers this warning
on a system with IOMMU enabled:
WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170
RIP: 0010:__iommu_dma_unmap+0x159/0x170
Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45
b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00
RSP: 0018:ff22d31181150c88 EFLAGS: 00010206
RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000
R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000
R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00
FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/16ae306602163fcb7ae83f2701b542e43c100cee
- https://git.kernel.org/stable/c/3cdf199d4755d477972ee87110b2aebc88b3cfad
- https://git.kernel.org/stable/c/50dad9909715094e7d9ca25e9e0412b875987519
- https://git.kernel.org/stable/c/5909679a82cd74cf0343d9e3ddf4b6931aa7e613
- https://git.kernel.org/stable/c/8d672a1a6bfc81fef9151925c9c0481f4acf4bec
- https://git.kernel.org/stable/c/e260f4d49370c85a4701d43c6d16b8c39f8b605f
- https://git.kernel.org/stable/c/f154e41e1d9d15ab21300ba7bbf0ebb5cb3b9c2a
- https://git.kernel.org/stable/c/f9eaf6d036075dc820520e1194692c0619b7297b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38440
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix race between DIM disable and net_dim()
There's a race between disabling DIM and NAPI callbacks using the dim
pointer on the RQ or SQ.
If NAPI checks the DIM state bit and sees it still set, it assumes
`rq->dim` or `sq->dim` is valid. But if DIM gets disabled right after
that check, the pointer might already be set to NULL, leading to a NULL
pointer dereference in net_dim().
Fix this by calling `synchronize_net()` before freeing the DIM context.
This ensures all in-progress NAPI callbacks are finished before the
pointer is cleared.
Kernel log:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
RIP: 0010:net_dim+0x23/0x190
...
Call Trace:
Modified: 2025-12-22
CVE-2025-38441
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto() syzbot found a potential access to uninit-value in nf_flow_pppoe_proto() Blamed commit forgot the Ethernet header. BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5742 [inline] __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837 __netif_receive_skb_one_core net/core/dev.c:5975 [inline] __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090 netif_receive_skb_internal net/core/dev.c:6176 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6235 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xb4b/0x1580 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline]
- https://git.kernel.org/stable/c/18cdb3d982da8976b28d57691eb256ec5688fad2
- https://git.kernel.org/stable/c/9fbc49429a23b02595ba82536c5ea425fdabb221
- https://git.kernel.org/stable/c/a3aea97d55964e70a1e6426aa4cafdc036e8a2dd
- https://git.kernel.org/stable/c/cfbf0665969af2c69d10c377d4c3d306e717efb4
- https://git.kernel.org/stable/c/e0dd2e9729660f3f4fcb16e0aef87342911528ef
- https://git.kernel.org/stable/c/eed8960b289327235185b7c32649c3470a3e969b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38443
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix uaf in nbd_genl_connect() error path
There is a use-after-free issue in nbd:
block nbd6: Receive control failed (result -104)
block nbd6: shutting down sockets
==================================================================
BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022
Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67
CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: nbd6-recv recv_work
Call Trace:
- https://git.kernel.org/stable/c/002aca89753f666d878ca0eb8584c372684ac4ba
- https://git.kernel.org/stable/c/8586552df591e0a367eff44af0c586213eeecc3f
- https://git.kernel.org/stable/c/91fa560c73a8126868848ed6cd70607cbf8d87e2
- https://git.kernel.org/stable/c/aa9552438ebf015fc5f9f890dbfe39f0c53cf37e
- https://git.kernel.org/stable/c/cb121c47f364b51776c4db904a6a5a90ab0a7ec5
- https://git.kernel.org/stable/c/d46186eb7bbd9a11c145120f2d77effa8d4d44c2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38444
In the Linux kernel, the following vulnerability has been resolved: raid10: cleanup memleak at raid10_make_request If raid10_read_request or raid10_write_request registers a new request and the REQ_NOWAIT flag is set, the code does not free the malloc from the mempool. unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7e V4: changing backing tree to see if CKI tests will pass. The patch code has not changed between any versions.
- https://git.kernel.org/stable/c/10c6021a609deb95f23f0cc2f89aa9d4bffb14c7
- https://git.kernel.org/stable/c/2941155d9a5ae098b480d551f3a5f8605d4f9af5
- https://git.kernel.org/stable/c/43806c3d5b9bb7d74ba4e33a6a8a41ac988bde24
- https://git.kernel.org/stable/c/8fc3d7b23d139e3cbc944c15d99b3cdbed797d2d
- https://git.kernel.org/stable/c/9af149ca9d0dab6e59e813519d309eff62499864
- https://git.kernel.org/stable/c/ed7bcd9f617e4107ac0813c516e72e6b8f6029bd
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38445
In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; } raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } } mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } } Fix: reinit conf->r1bio_pool.wait after assigning newpool.
- https://git.kernel.org/stable/c/12b00ec99624f8da8c325f2dd6e807df26df0025
- https://git.kernel.org/stable/c/48da050b4f54ed639b66278d0ae6f4107b2c4e2d
- https://git.kernel.org/stable/c/5f35e48b76655e45522df338876dfef88dafcc71
- https://git.kernel.org/stable/c/61fd5e93006cf82ec8ee5c115ab5cf4bbd104bdb
- https://git.kernel.org/stable/c/776e6186dc9ecbdb8a1b706e989166c8a99bbf64
- https://git.kernel.org/stable/c/d67ed2ccd2d1dcfda9292c0ea8697a9d0f2f0d98
- https://git.kernel.org/stable/c/d8a6853d00fbaa810765c8ed2f452a5832273968
- https://git.kernel.org/stable/c/df5894014a92ff0196dbc212a7764e97366fd2b7
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38446
In the Linux kernel, the following vulnerability has been resolved: clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data When num_parents is 4, __clk_register() occurs an out-of-bounds when accessing parent_names member. Use ARRAY_SIZE() instead of hardcode number here. BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8 Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59 Hardware name: NXP i.MX95 19X19 board (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x8c/0xcc print_report+0x398/0x5fc kasan_report+0xd4/0x114 __asan_report_load8_noabort+0x20/0x2c __clk_register+0x1844/0x20d8 clk_hw_register+0x44/0x110 __clk_hw_register_mux+0x284/0x3a8 imx95_bc_probe+0x4f4/0xa70
Modified: 2025-12-22
CVE-2025-38448
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Fix race condition in TTY wakeup A race condition occurs when gs_start_io() calls either gs_start_rx() or gs_start_tx(), as those functions briefly drop the port_lock for usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear port.tty and port_usb, respectively. Use the null-safe TTY Port helper function to wake up TTY. Example CPU1: CPU2: gserial_connect() // lock gs_close() // await lock gs_start_rx() // unlock usb_ep_queue() gs_close() // lock, reset port.tty and unlock gs_start_rx() // lock tty_wakeup() // NPE
- https://git.kernel.org/stable/c/18d58a467ccf011078352d91b4d6a0108c7318e8
- https://git.kernel.org/stable/c/a5012673d49788f16bb4e375b002d7743eb642d9
- https://git.kernel.org/stable/c/abf3620cba68e0e51e5c21054ce4f925f75b3661
- https://git.kernel.org/stable/c/c529c3730bd09115684644e26bf01ecbd7e2c2c9
- https://git.kernel.org/stable/c/c6eb4a05af3d0ba3bc4e8159287722fb9abc6359
- https://git.kernel.org/stable/c/c8c80a3a35c2e3488409de2d5376ef7e662a2bf5
- https://git.kernel.org/stable/c/d43657b59f36e88289a6066f15bc9a80df5014eb
- https://git.kernel.org/stable/c/ee8d688e2ba558f3bb8ac225113740be5f335417
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38449
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Acquire references on GEM handles for framebuffers
A GEM handle can be released while the GEM buffer object is attached
to a DRM framebuffer. This leads to the release of the dma-buf backing
the buffer object, if any. [1] Trying to use the framebuffer in further
mode-setting operations leads to a segmentation fault. Most easily
happens with driver that use shadow planes for vmap-ing the dma-buf
during a page flip. An example is shown below.
[ 156.791968] ------------[ cut here ]------------
[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430
[...]
[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
[ 157.043420] Call Trace:
[ 157.045898]
Modified: 2025-11-19
CVE-2025-38450
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload() Add a NULL check for msta->vif before accessing its members to prevent a kernel panic in AP mode deployment. This also fix the issue reported in [1]. The crash occurs when this function is triggered before the station is fully initialized. The call trace shows a page fault at mt7925_sta_set_decap_offload() due to accessing resources when msta->vif is NULL. Fix this by adding an early return if msta->vif is NULL and also check wcid.sta is ready. This ensures we only proceed with decap offload configuration when the station's state is properly initialized. [14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0 [14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G [14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE [14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) [14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common] [14739.851985] sp : ffffffc085efb500 [14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158 [14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001 [14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88 [14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000 [14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080 [14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000 [14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0 [14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100 [14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000 [14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8 [14739.926686] Call trace: [14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211] [14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211] [14739.946860] sta_info_move_state+0x1c/0x30 [mac80211] [14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211] [14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211] [14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211] [14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211] [14739.975516] genl_family_rcv_msg_doit+0xdc/0x150 [14739.980158] genl_rcv_msg+0x218/0x298 [14739.983830] netlink_rcv_skb+0x64/0x138 [14739.987670] genl_rcv+0x40/0x60 [14739.990816] netlink_unicast+0x314/0x380 [14739.994742] netlink_sendmsg+0x198/0x3f0 [14739.998664] __sock_sendmsg+0x64/0xc0 [14740.002324] ____sys_sendmsg+0x260/0x298 [14740.006242] ___sys_sendmsg+0xb4/0x110
Modified: 2025-12-22
CVE-2025-38451
In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix GPF in bitmap_get_stats() The commit message of commit 6ec1f0239485 ("md/md-bitmap: fix stats collection for external bitmaps") states: Remove the external bitmap check as the statistics should be available regardless of bitmap storage location. Return -EINVAL only for invalid bitmap with no storage (neither in superblock nor in external file). But, the code does not adhere to the above, as it does only check for a valid super-block for "internal" bitmaps. Hence, we observe: Oops: GPF, probably for non-canonical address 0x1cd66f1f40000028 RIP: 0010:bitmap_get_stats+0x45/0xd0 Call Trace: seq_read_iter+0x2b9/0x46a seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6d/0xf0 do_syscall_64+0x8c/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e We fix this by checking the existence of a super-block for both the internal and external case.
- https://git.kernel.org/stable/c/3d82a729530bd2110ba66e4a1f73461c776edec2
- https://git.kernel.org/stable/c/3e0542701b37aa25b025d8531583458e4f014c2e
- https://git.kernel.org/stable/c/a18f9b08c70e10ea3a897058fee8a4f3b4c146ec
- https://git.kernel.org/stable/c/a23b16ba3274961494f5ad236345d238364349ff
- https://git.kernel.org/stable/c/c17fb542dbd1db745c9feac15617056506dd7195
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38452
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe() Add check for the return value of rcar_gen4_ptp_alloc() to prevent potential null pointer dereference.
Modified: 2025-11-19
CVE-2025-38454
In the Linux kernel, the following vulnerability has been resolved: ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp() Use pr_warn() instead of dev_warn() when 'pdev' is NULL to avoid a potential NULL pointer dereference.
Modified: 2025-12-22
CVE-2025-38455
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight
Reject migration of SEV{-ES} state if either the source or destination VM
is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the
section between incrementing created_vcpus and online_vcpus. The bulk of
vCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUs
in parallel, and so sev_info.es_active can get toggled from false=>true in
the destination VM after (or during) svm_vcpu_create(), resulting in an
SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.
The issue manifests most visibly as a crash when trying to free a vCPU's
NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.
BUG: unable to handle page fault for address: ffffebde00000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE
Tainted: [U]=USER, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024
RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]
RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]
RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]
RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]
RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067
Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0
RSP: 0018:ffff8984551978d0 EFLAGS: 00010246
RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000
RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000
R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000
R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000
FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0
DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/8c8e8d4d7544bb783e15078eda8ba2580e192246
- https://git.kernel.org/stable/c/b5725213149597cd9c2b075b87bc4e0f87e906c1
- https://git.kernel.org/stable/c/e0d9a7cf37ca09c513420dc88e0d0e805a4f0820
- https://git.kernel.org/stable/c/ecf371f8b02d5e31b9aa1da7f159f1b2107bdb01
- https://git.kernel.org/stable/c/fd044c99d831e9f837518816c7c366b04014d405
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38456
In the Linux kernel, the following vulnerability has been resolved: ipmi:msghandler: Fix potential memory corruption in ipmi_create_user() The "intf" list iterator is an invalid pointer if the correct "intf->intf_num" is not found. Calling atomic_dec(&intf->nr_users) on and invalid pointer will lead to memory corruption. We don't really need to call atomic_dec() if we haven't called atomic_add_return() so update the if (intf->in_shutdown) path as well.
- https://git.kernel.org/stable/c/7c1a6ddb99858e7d68961f74ae27caeeeca67b6a
- https://git.kernel.org/stable/c/9e0d33e75c1604c3fad5586ad4dfa3b2695a3950
- https://git.kernel.org/stable/c/cbc1670297f675854e982d23c8583900ff0cc67a
- https://git.kernel.org/stable/c/e2d5c005dfc96fe857676d1d8ac46b29275cb89b
- https://git.kernel.org/stable/c/fa332f5dc6fc662ad7d3200048772c96b861cf6b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38457
In the Linux kernel, the following vulnerability has been resolved: net/sched: Abort __tc_modify_qdisc if parent class does not exist Lion's patch [1] revealed an ancient bug in the qdisc API. Whenever a user creates/modifies a qdisc specifying as a parent another qdisc, the qdisc API will, during grafting, detect that the user is not trying to attach to a class and reject. However grafting is performed after qdisc_create (and thus the qdiscs' init callback) is executed. In qdiscs that eventually call qdisc_tree_reduce_backlog during init or change (such as fq, hhf, choke, etc), an issue arises. For example, executing the following commands: sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq Qdiscs such as fq, hhf, choke, etc unconditionally invoke qdisc_tree_reduce_backlog() in their control path init() or change() which then causes a failure to find the child class; however, that does not stop the unconditional invocation of the assumed child qdisc's qlen_notify with a null class. All these qdiscs make the assumption that class is non-null. The solution is ensure that qdisc_leaf() which looks up the parent class, and is invoked prior to qdisc_create(), should return failure on not finding the class. In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the parentid doesn't correspond to a class, so that we can detect it earlier on and abort before qdisc_create is called. [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/
- https://git.kernel.org/stable/c/23c165dde88eac405eebb59051ea1fe139a45803
- https://git.kernel.org/stable/c/25452638f133ac19d75af3f928327d8016952c8e
- https://git.kernel.org/stable/c/4c691d1b6b6dbd73f30ed9ee7da05f037b0c49af
- https://git.kernel.org/stable/c/8ecd651ef24ab50123692a4e3e25db93cb11602a
- https://git.kernel.org/stable/c/90436e72c9622c2f70389070088325a3232d339f
- https://git.kernel.org/stable/c/923a276c74e25073ae391e930792ac86a9f77f1e
- https://git.kernel.org/stable/c/e28a383d6485c3bb51dc5953552f76c4dea33eea
- https://git.kernel.org/stable/c/ffdde7bf5a439aaa1955ebd581f5c64ab1533963
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38458
In the Linux kernel, the following vulnerability has been resolved:
atm: clip: Fix NULL pointer dereference in vcc_sendmsg()
atmarpd_dev_ops does not implement the send method, which may cause crash
as bellow.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: Oops: 0010 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246
RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000
RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000
RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287
R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00
R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88
FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/07b585ae3699c0a5026f86ac846f144e34875eee
- https://git.kernel.org/stable/c/22fc46cea91df3dce140a7dc6847c6fcf0354505
- https://git.kernel.org/stable/c/27b5bb7ea1a8fa7b8c4cfde4d2bf8650cca2e8e8
- https://git.kernel.org/stable/c/34a09d6240a25185ef6fc5a19dbb3cdbb6a78bc0
- https://git.kernel.org/stable/c/7f1cad84ac1a6af42d9d57e879de47ce37995024
- https://git.kernel.org/stable/c/7f8a9b396037daae453a108faec5b28886361323
- https://git.kernel.org/stable/c/9ec7e943aee5c28c173933f9defd40892fb3be3d
- https://git.kernel.org/stable/c/a16fbe6087e91c8e7c4aa50e1af7ad56edbd9e3e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38459
In the Linux kernel, the following vulnerability has been resolved:
atm: clip: Fix infinite recursive call of clip_push().
syzbot reported the splat below. [0]
This happens if we call ioctl(ATMARP_MKIP) more than once.
During the first call, clip_mkip() sets clip_push() to vcc->push(),
and the second call copies it to clip_vcc->old_push().
Later, when the socket is close()d, vcc_destroy_socket() passes
NULL skb to clip_push(), which calls clip_vcc->old_push(),
triggering the infinite recursion.
Let's prevent the second ioctl(ATMARP_MKIP) by checking
vcc->user_back, which is allocated by the first call as clip_vcc.
Note also that we use lock_sock() to prevent racy calls.
[0]:
BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)
Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191
Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00
RSP: 0018:ffffc9000d670000 EFLAGS: 00010246
RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000
RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e
R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300
R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578
FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0
Call Trace:
- https://git.kernel.org/stable/c/024876b247a882972095b22087734dcd23396a4e
- https://git.kernel.org/stable/c/125166347d5676466d368aadc0bbc31ee7714352
- https://git.kernel.org/stable/c/1579a2777cb914a249de22c789ba4d41b154509f
- https://git.kernel.org/stable/c/3f61b997fe014bbfcc208a9fcbd363a1fe7e3a31
- https://git.kernel.org/stable/c/5641019dfbaee5e85fe093b590f0451c9dd4d6f8
- https://git.kernel.org/stable/c/c489f3283dbfc0f3c00c312149cae90d27552c45
- https://git.kernel.org/stable/c/df0312d8859763aa15b8b56ac151a1ea4a4e5b88
- https://git.kernel.org/stable/c/f493f31a63847624fd3199ac836a8bd8828e50e2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38460
In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix potential null-ptr-deref in to_atmarpd(). atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clip causes unregister hang"). However, it is not enough because to_atmarpd() is called without RTNL, especially clip_neigh_solicit() / neigh_ops->solicit() is unsleepable. Also, there is no RTNL dependency around atmarpd. Let's use a private mutex and RCU to protect access to atmarpd in to_atmarpd().
- https://git.kernel.org/stable/c/06935c50cfa3ac57cce80bba67b6d38ec1406e92
- https://git.kernel.org/stable/c/3251ce3979f41bd228f77a7615f9dd616d06a110
- https://git.kernel.org/stable/c/36caab990b69ef4eec1d81c52a19f080b7daa059
- https://git.kernel.org/stable/c/706cc36477139c1616a9b2b96610a8bb520b7119
- https://git.kernel.org/stable/c/70eac9ba7ce25d99c1d99bbf4ddb058940f631f9
- https://git.kernel.org/stable/c/a4c5785feb979cd996a99cfaad8bf353b2e79301
- https://git.kernel.org/stable/c/ee4d9e4ddf3f9c4ee2ec0a3aad6196ee36d30e57
- https://git.kernel.org/stable/c/f58e4270c73e7f086322978d585ea67c8076ce49
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38461
In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_* TOCTOU Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer. This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
- https://git.kernel.org/stable/c/36a439049b34cca0b3661276049b84a1f76cc21a
- https://git.kernel.org/stable/c/687aa0c5581b8d4aa87fd92973e4ee576b550cdf
- https://git.kernel.org/stable/c/7b73bddf54777fb62d4d8c7729d0affe6df04477
- https://git.kernel.org/stable/c/8667e8d0eb46bc54fdae30ba2f4786407d3d88eb
- https://git.kernel.org/stable/c/9ce53e744f18e73059d3124070e960f3aa9902bf
- https://git.kernel.org/stable/c/9d24bb6780282b0255b9929abe5e8f98007e2c6e
- https://git.kernel.org/stable/c/ae2c712ba39c7007de63cb0c75b51ce1caaf1da5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38462
In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_{g2h,h2g} TOCTOU vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload. transport_{g2h,h2g} may become NULL after the NULL check. Introduce vsock_transport_local_cid() to protect from a potential null-ptr-deref. KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_find_cid+0x47/0x90 Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0 Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
- https://git.kernel.org/stable/c/209fd720838aaf1420416494c5505096478156b4
- https://git.kernel.org/stable/c/3734d78210cceb2ee5615719a62a5c55ed381ff8
- https://git.kernel.org/stable/c/401239811fa728fcdd53e360a91f157ffd23e1f4
- https://git.kernel.org/stable/c/5752d8dbb3dfd7f1a9faf0f65377e60826ea9a17
- https://git.kernel.org/stable/c/6a1bcab67bea797d83aa9dd948a0ac6ed52d121d
- https://git.kernel.org/stable/c/80d7dc15805a93d520a249ac6d13d4f4df161c1b
- https://git.kernel.org/stable/c/c5496ee685c48ed1cc183cd4263602579bb4a615
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38463
In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtraction will result in copy holding a very large positive integer. In the subsequent logic, this large value is used to update sk->sk_forward_alloc, which can easily cause it to overflow. The syzkaller reproducer uses TCP_REPAIR to reliably create this condition. However, this can also occur in real-world scenarios. The tcp_bound_to_half_wnd() function can also reduce size_goal to a small value. This would cause the subsequent tcp_wmem_schedule() to set sk->sk_forward_alloc to a value close to INT_MAX. Further memory allocation requests would then cause sk_forward_alloc to wrap around and become negative. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47
Modified: 2025-12-22
CVE-2025-38464
In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_conn_close(). syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0] tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn. The problem is that tipc_conn_close() is called after releasing the IDR lock. At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref. Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive. Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop(). [0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435 CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
- https://git.kernel.org/stable/c/03dcdd2558e1e55bf843822fe4363dcb48743f2b
- https://git.kernel.org/stable/c/15a6f4971e2f157d57e09ea748d1fbc714277aa4
- https://git.kernel.org/stable/c/1dbf7cd2454a28b1da700085b99346b5445aeabb
- https://git.kernel.org/stable/c/3b89e17b2fd64012682bed158d9eb3d2e96dec42
- https://git.kernel.org/stable/c/50aa2d121bc2cfe2d825f8a331ea75dfaaab6a50
- https://git.kernel.org/stable/c/667eeab4999e981c96b447a4df5f20bdf5c26f13
- https://git.kernel.org/stable/c/be4b8392da7978294f2f368799d29dd509fb6c4d
- https://git.kernel.org/stable/c/dab8ded2e5ff41012a6ff400b44dbe76ccf3592a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38465
In the Linux kernel, the following vulnerability has been resolved: netlink: Fix wraparounds of sk->sk_rmem_alloc. Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc); , which has the same problem fixed by commit 5a465a0da13e ("udp: Fix multiple wraparounds of sk->sk_rmem_alloc."). For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition is always false as the two operands are of int. Then, a single socket can eat as many skb as possible until OOM happens, and we can see multiple wraparounds of sk->sk_rmem_alloc. Let's fix it by using atomic_add_return() and comparing the two variables as unsigned int. Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 * After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576
- https://git.kernel.org/stable/c/4b8e18af7bea92f8b7fb92d40aeae729209db250
- https://git.kernel.org/stable/c/55baecb9eb90238f60a8350660d6762046ebd3bd
- https://git.kernel.org/stable/c/76602d8e13864524382b0687dc32cd8f19164d5a
- https://git.kernel.org/stable/c/9da025150b7c14a8390fc06aea314c0a4011e82c
- https://git.kernel.org/stable/c/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc
- https://git.kernel.org/stable/c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98
- https://git.kernel.org/stable/c/cd7ff61bfffd7000143c42bbffb85eeb792466d6
- https://git.kernel.org/stable/c/fd69af06101090eaa60b3d216ae715f9c0a58e5b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38466
In the Linux kernel, the following vulnerability has been resolved: perf: Revert to requiring CAP_SYS_ADMIN for uprobes Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream. Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction. As such, require CAP_SYS_ADMIN for uprobes.
- https://git.kernel.org/stable/c/183bdb89af1b5193b1d1d9316986053b15ca6fa4
- https://git.kernel.org/stable/c/8e8bf7bc6aa6f583336c2fda280b6cea0aed5612
- https://git.kernel.org/stable/c/a0a8009083e569b5526c64f7d3f2a62baca95164
- https://git.kernel.org/stable/c/ba677dbe77af5ffe6204e0f3f547f3ba059c6302
- https://git.kernel.org/stable/c/c0aec35f861fa746ca45aa816161c74352e6ada8
- https://git.kernel.org/stable/c/d5074256b642cdeb46a70ce2f15193e766edca68
- https://git.kernel.org/stable/c/d7ef1afd5b3f43f4924326164cee5397b66abd9c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38467
In the Linux kernel, the following vulnerability has been resolved: drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling If there's support for another console device (such as a TTY serial), the kernel occasionally panics during boot. The panic message and a relevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...] Otherwise, the panics don't happen. This indicates that it's some sort of race condition. Add a check to validate if the drm device can handle vblanks before calling drm_crtc_handle_vblank() to avoid this.
- https://git.kernel.org/stable/c/391e5ea5b877230b844c9bd8bbcd91b681b1ce2d
- https://git.kernel.org/stable/c/87825fbd1e176cd5b896940f3959e7c9a916945d
- https://git.kernel.org/stable/c/996740652e620ef8ee1e5c65832cf2ffa498577d
- https://git.kernel.org/stable/c/a2130463fc9451005660b0eda7b61d5f746f7d74
- https://git.kernel.org/stable/c/a40a35166f7e4f6dcd4b087d620c8228922dcb0a
- https://git.kernel.org/stable/c/b4e72c0bf878f02faa00a7dc7c9ffc4ff7c116a7
- https://git.kernel.org/stable/c/b846350aa272de99bf6fecfa6b08e64ebfb13173
- https://git.kernel.org/stable/c/e9d9b25f376737b81f06de9c5aa422b488f47184
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38468
In the Linux kernel, the following vulnerability has been resolved: net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree htb_lookup_leaf has a BUG_ON that can trigger with the following: tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 htb rate 64bit tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2:1 handle 3: blackhole ping -I lo -c1 -W0.001 127.0.0.1 The root cause is the following: 1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc 2. netem_dequeue calls enqueue on the child qdisc 3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase 5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ON The function graph for this scenario is shown here: 0) | htb_enqueue() { 0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() { 0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() { 0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() { 0) | qdisc_lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() { 0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() { 0) | BUG_ON(); ------------------------------------------ The full original bug report can be seen here [1]. We can fix this just by returning NULL instead of the BUG_ON, as htb_dequeue_tree returns NULL when htb_lookup_leaf returns NULL. [1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/
- https://git.kernel.org/stable/c/0e1d5d9b5c5966e2e42e298670808590db5ed628
- https://git.kernel.org/stable/c/3691f84269a23f7edd263e9b6edbc27b7ae332f4
- https://git.kernel.org/stable/c/5c0506cd1b1a3b145bda2612bbf7fe78d186c355
- https://git.kernel.org/stable/c/7ff2d83ecf2619060f30ecf9fad4f2a700fca344
- https://git.kernel.org/stable/c/850226aef8d28a00cf966ef26d2f8f2bff344535
- https://git.kernel.org/stable/c/890a5d423ef0a7bd13447ceaffad21189f557301
- https://git.kernel.org/stable/c/e5c480dc62a3025b8428d4818e722da30ad6804f
- https://git.kernel.org/stable/c/fed3570e548a6c9f95c5f4c9e1a7afc1679fd90d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38469
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/xen: Fix cleanup logic in emulation of Xen schedop poll hypercalls kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host for more than one event channel potr (nr_ports > 1). After the kmalloc_array(), the error paths need to go through the "out" label, but the call to kvm_read_guest_virt() does not. [Adjusted commit message. - Paolo]
Modified: 2025-12-22
CVE-2025-38470
In the Linux kernel, the following vulnerability has been resolved:
net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime
Assuming the "rx-vlan-filter" feature is enabled on a net device, the
8021q module will automatically add or remove VLAN 0 when the net device
is put administratively up or down, respectively. There are a couple of
problems with the above scheme.
The first problem is a memory leak that can happen if the "rx-vlan-filter"
feature is disabled while the device is running:
# ip link add bond1 up type bond mode 0
# ethtool -K bond1 rx-vlan-filter off
# ip link del dev bond1
When the device is put administratively down the "rx-vlan-filter"
feature is disabled, so the 8021q module will not remove VLAN 0 and the
memory will be leaked [1].
Another problem that can happen is that the kernel can automatically
delete VLAN 0 when the device is put administratively down despite not
adding it when the device was put administratively up since during that
time the "rx-vlan-filter" feature was disabled. null-ptr-unref or
bug_on[2] will be triggered by unregister_vlan_dev() for refcount
imbalance if toggling filtering during runtime:
$ ip link add bond0 type bond mode 0
$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q
$ ethtool -K bond0 rx-vlan-filter off
$ ifconfig bond0 up
$ ethtool -K bond0 rx-vlan-filter on
$ ifconfig bond0 down
$ ip link del vlan0
Root cause is as below:
step1: add vlan0 for real_dev, such as bond, team.
register_vlan_dev
vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1
step2: disable vlan filter feature and enable real_dev
step3: change filter from 0 to 1
vlan_device_event
vlan_filter_push_vids
ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0
step4: real_dev down
vlan_device_event
vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0
vlan_info_rcu_free //free vlan0
step5: delete vlan0
unregister_vlan_dev
BUG_ON(!vlan_info); //vlan_info is null
Fix both problems by noting in the VLAN info whether VLAN 0 was
automatically added upon NETDEV_UP and based on that decide whether it
should be deleted upon NETDEV_DOWN, regardless of the state of the
"rx-vlan-filter" feature.
[1]
unreferenced object 0xffff8880068e3100 (size 256):
comm "ip", pid 384, jiffies 4296130254
hex dump (first 32 bytes):
00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 81ce31fa):
__kmalloc_cache_noprof+0x2b5/0x340
vlan_vid_add+0x434/0x940
vlan_device_event.cold+0x75/0xa8
notifier_call_chain+0xca/0x150
__dev_notify_flags+0xe3/0x250
rtnl_configure_link+0x193/0x260
rtnl_newlink_create+0x383/0x8e0
__rtnl_newlink+0x22c/0xa40
rtnl_newlink+0x627/0xb00
rtnetlink_rcv_msg+0x6fb/0xb70
netlink_rcv_skb+0x11f/0x350
netlink_unicast+0x426/0x710
netlink_sendmsg+0x75a/0xc20
__sock_sendmsg+0xc1/0x150
____sys_sendmsg+0x5aa/0x7b0
___sys_sendmsg+0xfc/0x180
[2]
kernel BUG at net/8021q/vlan.c:99!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))
RSP: 0018:ffff88810badf310 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8
RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80
R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000
R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e
FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/047b61a24d7c866c502aeeea482892969a68f216
- https://git.kernel.org/stable/c/35142b3816832889e50164d993018ea5810955ae
- https://git.kernel.org/stable/c/579d4f9ca9a9a605184a9b162355f6ba131f678d
- https://git.kernel.org/stable/c/8984bcbd1edf5bee5be06ad771d157333b790c33
- https://git.kernel.org/stable/c/93715aa2d80e6c5cea1bb486321fc4585076928b
- https://git.kernel.org/stable/c/ba48d3993af23753e1f1f01c8d592de9c7785f24
- https://git.kernel.org/stable/c/bb515c41306454937464da055609b5fb0a27821b
- https://git.kernel.org/stable/c/d43ef15bf4856c8c4c6c3572922331a5f06deb77
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38471
In the Linux kernel, the following vulnerability has been resolved: tls: always refresh the queue when reading sock After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry. BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls] (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529 CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasan_report+0xca/0x100 tls_strp_check_rcv+0x898/0x9a0 [tls] tls_rx_rec_wait+0x2c9/0x8d0 [tls] tls_sw_recvmsg+0x40f/0x1aa0 [tls] inet_recvmsg+0x1c3/0x1f0 Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.full_len").
- https://git.kernel.org/stable/c/1f3a429c21e0e43e8b8c55d30701e91411a4df02
- https://git.kernel.org/stable/c/4ab26bce3969f8fd925fe6f6f551e4d1a508c68b
- https://git.kernel.org/stable/c/730fed2ff5e259495712518e18d9f521f61972bb
- https://git.kernel.org/stable/c/c76f6f437c46b2390888e0e1dc7aafafa9f4e0c6
- https://git.kernel.org/stable/c/cdb767915fc9a15d88d19d52a1455f1dc3e5ddc8
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38472
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack: fix crash due to removal of uninitialised entry
A crash in conntrack was reported while trying to unlink the conntrack
entry from the hash bucket list:
[exception RIP: __nf_ct_delete_from_lists+172]
[..]
#7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]
#8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack]
#9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack]
[..]
The nf_conn struct is marked as allocated from slab but appears to be in
a partially initialised state:
ct hlist pointer is garbage; looks like the ct hash value
(hence crash).
ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected
ct->timeout is 30000 (=30s), which is unexpected.
Everything else looks like normal udp conntrack entry. If we ignore
ct->status and pretend its 0, the entry matches those that are newly
allocated but not yet inserted into the hash:
- ct hlist pointers are overloaded and store/cache the raw tuple hash
- ct->timeout matches the relative time expected for a new udp flow
rather than the absolute 'jiffies' value.
If it were not for the presence of IPS_CONFIRMED,
__nf_conntrack_find_get() would have skipped the entry.
Theory is that we did hit following race:
cpu x cpu y cpu z
found entry E found entry E
E is expired
- https://git.kernel.org/stable/c/2d72afb340657f03f7261e9243b44457a9228ac7
- https://git.kernel.org/stable/c/76179961c423cd698080b5e4d5583cf7f4fcdde9
- https://git.kernel.org/stable/c/938ce0e8422d3793fe30df2ed0e37f6bc0598379
- https://git.kernel.org/stable/c/a47ef874189d47f934d0809ae738886307c0ea22
- https://git.kernel.org/stable/c/fc38c249c622ff5e3011b8845fd49dbfd9289afc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38473
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0] l2cap_sock_resume_cb() has a similar problem that was fixed by commit 1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()"). Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed under l2cap_sock_resume_cb(), we can avoid the issue simply by checking if chan->data is NULL. Let's not access to the killed socket in l2cap_sock_resume_cb(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: hci0 hci_rx_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
- https://git.kernel.org/stable/c/262cd18f5f7ede6a586580cadc5d0799e52e2e7c
- https://git.kernel.org/stable/c/2b27b389006623673e8cfff4ce1e119cce640b05
- https://git.kernel.org/stable/c/3a4eca2a1859955c65f07a570156bd2d9048ce33
- https://git.kernel.org/stable/c/6d63901dcd592a1e3f71d7c6d78f9be5e8d7eef0
- https://git.kernel.org/stable/c/a0075accbf0d76c2dad1ad3993d2e944505d99a0
- https://git.kernel.org/stable/c/ac3a8147bb24314fb3e84986590148e79f9872ec
- https://git.kernel.org/stable/c/b97be7ee8a1cd96b89817cbd64a9f5cc16c17d08
- https://git.kernel.org/stable/c/c4f16f6b071a74ac7eefe5c28985285cbbe2cd96
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-22
CVE-2025-38474
In the Linux kernel, the following vulnerability has been resolved: usb: net: sierra: check for no status endpoint The driver checks for having three endpoints and having bulk in and out endpoints, but not that the third endpoint is interrupt input. Rectify the omission.
- https://git.kernel.org/stable/c/0a263ccb905b4ae2af381cd4280bd8d2477b98b8
- https://git.kernel.org/stable/c/4c4ca3c46167518f8534ed70f6e3b4bf86c4d158
- https://git.kernel.org/stable/c/5408cc668e596c81cdd29e137225432aa40d1785
- https://git.kernel.org/stable/c/5849980faea1c792d1d5e54fdbf1e69ac0a9bfb9
- https://git.kernel.org/stable/c/5dd6a441748dad2f02e27b256984ca0b2d4546b6
- https://git.kernel.org/stable/c/65c666aff44eb7f9079c55331abd9687fb77ba2d
- https://git.kernel.org/stable/c/a6a238c4126eb3ddb495d3f960193ca5bb778d92
- https://git.kernel.org/stable/c/bfe8ef373986e8f185d3d6613eb1801a8749837a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38475
In the Linux kernel, the following vulnerability has been resolved: smc: Fix various oops due to inet_sock type confusion. syzbot reported weird splats [0][1] in cipso_v4_sock_setattr() while freeing inet_sk(sk)->inet_opt. The address was freed multiple times even though it was read-only memory. cipso_v4_sock_setattr() did nothing wrong, and the root cause was type confusion. The cited commit made it possible to create smc_sock as an INET socket. The issue is that struct smc_sock does not have struct inet_sock as the first member but hijacks AF_INET and AF_INET6 sk_family, which confuses various places. In this case, inet_sock.inet_opt was actually smc_sock.clcsk_data_ready(), which is an address of a function in the text segment. $ pahole -C inet_sock vmlinux struct inet_sock { ... struct ip_options_rcu * inet_opt; /* 784 8 */ $ pahole -C smc_sock vmlinux struct smc_sock { ... void (*clcsk_data_ready)(struct sock *); /* 784 8 */ The same issue for another field was reported before. [2][3] At that time, an ugly hack was suggested [4], but it makes both INET and SMC code error-prone and hard to change. Also, yet another variant was fixed by a hacky commit 98d4435efcbf3 ("net/smc: prevent NULL pointer dereference in txopt_get"). Instead of papering over the root cause by such hacks, we should not allow non-INET socket to reuse the INET infra. Let's add inet_sock as the first member of smc_sock. [0]: kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73 WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 Modules linked in: CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 sp : ffff8000a03a7730 x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3 x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00 x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000 x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360 x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000 Call trace: kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 [ ---truncated---
Modified: 2025-12-22
CVE-2025-38476
In the Linux kernel, the following vulnerability has been resolved:
rpl: Fix use-after-free in rpl_do_srh_inline().
Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers
the splat below [0].
rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after
skb_cow_head(), which is illegal as the header could be freed then.
Let's fix it by making oldhdr to a local struct instead of a pointer.
[0]:
[root@fedora net]# ./lwt_dst_cache_ref_loop.sh
...
TEST: rpl (input)
[ 57.631529] ==================================================================
BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)
Read of size 40 at addr ffff888122bf96d8 by task ping6/1543
CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/034b428aa3583373a5a20b1c5931bb2b3cae1f36
- https://git.kernel.org/stable/c/06ec83b6c792fde1f710c1de3e836da6e257c4c4
- https://git.kernel.org/stable/c/62dcd9d6e61c39122d2f251a26829e2e55b0a11d
- https://git.kernel.org/stable/c/8ba6c2362b85089b8972ac5f20b24fc71a4b8ffc
- https://git.kernel.org/stable/c/b640daa2822a39ff76e70200cb2b7b892b896dce
- https://git.kernel.org/stable/c/c09e21dfc08d8afb92d9ea3bee3457adbe3ef297
- https://git.kernel.org/stable/c/e8101506ab86dd78f823b7028f2036a380f3a12a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38477
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: Fix race condition on qfq_aggregate A race condition can occur when 'agg' is modified in qfq_change_agg (called during qfq_enqueue) while other threads access it concurrently. For example, qfq_dump_class may trigger a NULL dereference, and qfq_delete_class may cause a use-after-free. This patch addresses the issue by: 1. Moved qfq_destroy_class into the critical section. 2. Added sch_tree_lock protection to qfq_dump_class and qfq_dump_class_stats.
- https://git.kernel.org/stable/c/466e10194ab81caa2ee6a332d33ba16bcceeeba6
- https://git.kernel.org/stable/c/5e28d5a3f774f118896aec17a3a20a9c5c9dfc64
- https://git.kernel.org/stable/c/a6d735100f602c830c16d69fb6d780eebd8c9ae1
- https://git.kernel.org/stable/c/aa7a22c4d678bf649fd3a1d27debec583563414d
- https://git.kernel.org/stable/c/c000a3a330d97f6c073ace5aa5faf94b9adb4b79
- https://git.kernel.org/stable/c/c6df794000147a3a02f79984aada4ce83f8d0a1e
- https://git.kernel.org/stable/c/d841aa5518508ab195b6781ad0d73ee378d713dd
- https://git.kernel.org/stable/c/fbe48f06e64134dfeafa89ad23387f66ebca3527
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-23
CVE-2025-38478
In the Linux kernel, the following vulnerability has been resolved: comedi: Fix initialization of data for instructions that write to subdevice Some Comedi subdevice instruction handlers are known to access instruction data elements beyond the first `insn->n` elements in some cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions allocate at least `MIN_SAMPLES` (16) data elements to deal with this, but they do not initialize all of that. For Comedi instruction codes that write to the subdevice, the first `insn->n` data elements are copied from user-space, but the remaining elements are left uninitialized. That could be a problem if the subdevice instruction handler reads the uninitialized data. Ensure that the first `MIN_SAMPLES` elements are initialized before calling these instruction handlers, filling the uncopied elements with 0. For `do_insnlist_ioctl()`, the same data buffer elements are used for handling a list of instructions, so ensure the first `MIN_SAMPLES` elements are initialized for each instruction that writes to the subdevice.
- https://git.kernel.org/stable/c/020eed5681d0f9bced73970368078a92d6cfaa9c
- https://git.kernel.org/stable/c/13e4d9038a1e869445a996a3f604a84ef52fe8f4
- https://git.kernel.org/stable/c/46d8c744136ce2454aa4c35c138cc06817f92b8e
- https://git.kernel.org/stable/c/673ee92bd2d31055bca98a1d96b653f5284289c4
- https://git.kernel.org/stable/c/6f38c6380c3b38a05032b8881e41137385a6ce02
- https://git.kernel.org/stable/c/c42116dc70af6664526f7aa82cf937824ab42649
- https://git.kernel.org/stable/c/d3436638738ace8f101af7bdee2eae1bc38e9b29
- https://git.kernel.org/stable/c/fe8713fb4e4e82a4f91910d9a41bf0613e69a0b9
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38480
In the Linux kernel, the following vulnerability has been resolved: comedi: Fix use of uninitialized data in insn_rw_emulate_bits() For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital" subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and `COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have `insn_read` and `insn_write` handler functions, but to have an `insn_bits` handler function for handling Comedi `INSN_BITS` instructions. In that case, the subdevice's `insn_read` and/or `insn_write` function handler pointers are set to point to the `insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`. For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the supplied `data[0]` value is a valid copy from user memory. It will at least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in "comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements are allocated. However, if `insn->n` is 0 (which is allowable for `INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain uninitialized data, and certainly contains invalid data, possibly from a different instruction in the array of instructions handled by `do_insnlist_ioctl()`. This will result in an incorrect value being written to the digital output channel (or to the digital input/output channel if configured as an output), and may be reflected in the internal saved state of the channel. Fix it by returning 0 early if `insn->n` is 0, before reaching the code that accesses `data[0]`. Previously, the function always returned 1 on success, but it is supposed to be the number of data samples actually read or written up to `insn->n`, which is 0 in this case.
- https://git.kernel.org/stable/c/10f9024a8c824a41827fff1fefefb314c98e2c88
- https://git.kernel.org/stable/c/16256d7efcf7acc9f39abe21522c4c6b77f67c00
- https://git.kernel.org/stable/c/2af1e7d389c2619219171d23f5b96dbcbb7f9656
- https://git.kernel.org/stable/c/3050d197d6bc9ef128944a70210f42d2430b3000
- https://git.kernel.org/stable/c/3ab55ffaaf75d0c7b68e332c1cdcc1b0e0044870
- https://git.kernel.org/stable/c/4c2981bf30401adfcdbfece4ab6f411f7c5875a1
- https://git.kernel.org/stable/c/c53570e62b5b28bdb56bb563190227f8307817a5
- https://git.kernel.org/stable/c/e9cb26291d009243a4478a7ffb37b3a9175bfce9
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38481
In the Linux kernel, the following vulnerability has been resolved: comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to hold the array of `struct comedi_insn`, getting the length from the `n_insns` member of the `struct comedi_insnlist` supplied by the user. The allocation will fail with a WARNING and a stack dump if it is too large. Avoid that by failing with an `-EINVAL` error if the supplied `n_insns` value is unreasonable. Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Set this to the same value as `MAX_SAMPLES` (65536), which is the maximum allowed sum of the values of the member `n` in the array of `struct comedi_insn`, and sensible comedi instructions will have an `n` of at least 1.
- https://git.kernel.org/stable/c/08ae4b20f5e82101d77326ecab9089e110f224cc
- https://git.kernel.org/stable/c/454d732dfd0aef7d7aa950c409215ca06d717e93
- https://git.kernel.org/stable/c/69dc06b9514522de532e997a21d035cd29b0db44
- https://git.kernel.org/stable/c/992d600f284e719242a434166e86c1999649b71c
- https://git.kernel.org/stable/c/c68257588e87f45530235701a42496b7e9e56adb
- https://git.kernel.org/stable/c/c9d3d9667443caafa804cd07940aeaef8e53aa90
- https://git.kernel.org/stable/c/d4c73ce13f5b5a0fe0319f1f352ff602f0ace8e3
- https://git.kernel.org/stable/c/e3b8322cc8081d142ee4c1a43e1d702bdba1ed76
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38482
In the Linux kernel, the following vulnerability has been resolved: comedi: das6402: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: /* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */ if ((1 << it->options[1]) & 0x8cec) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.
- https://git.kernel.org/stable/c/3eab654f5d199ecd45403c6588cda63e491fcfca
- https://git.kernel.org/stable/c/4a3c18cde02e35aba87e0ad5672b3e1c72dda5a4
- https://git.kernel.org/stable/c/70f2b28b5243df557f51c054c20058ae207baaac
- https://git.kernel.org/stable/c/73f34d609397805c20d6b2ef5c07a4cbf7c4d63a
- https://git.kernel.org/stable/c/8a3637027ceeba4ca5e500b23cb7d24c25592513
- https://git.kernel.org/stable/c/a15e9c175f783298c4ee48146be6841335400406
- https://git.kernel.org/stable/c/a18a42e77545afcacd6a2b8d9fc16191b87454df
- https://git.kernel.org/stable/c/de8da1063cce9234d55c8270d9bdf4cf84411c80
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38483
In the Linux kernel, the following vulnerability has been resolved: comedi: das16m1: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: /* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ if ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test.
- https://git.kernel.org/stable/c/076b13ee60eb01ed0d140ef261f95534562a3077
- https://git.kernel.org/stable/c/539bdff832adac9ea653859fa0b6bc62e743329c
- https://git.kernel.org/stable/c/65c03e6fc524eb2868abedffd8a4613d78abc288
- https://git.kernel.org/stable/c/adb7df8a8f9d788423e161b779764527dd3ec2d0
- https://git.kernel.org/stable/c/b3c95fa508e5dc3da60520eea92a5241095ceef1
- https://git.kernel.org/stable/c/d1291c69f46d6572b2cf75960dd8975d7ab2176b
- https://git.kernel.org/stable/c/ed93c6f68a3be06e4e0c331c6e751f462dee3932
- https://git.kernel.org/stable/c/f211572818ed5bec2b3f5d4e0719ef8699b3c269
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38484
In the Linux kernel, the following vulnerability has been resolved: iio: backend: fix out-of-bound write The buffer is set to 80 character. If a caller write more characters, count is truncated to the max available space in "simple_write_to_buffer". But afterwards a string terminator is written to the buffer at offset count without boundary check. The zero termination is written OUT-OF-BOUND. Add a check that the given buffer is smaller then the buffer to prevent.
Modified: 2026-01-07
CVE-2025-38485
In the Linux kernel, the following vulnerability has been resolved: iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with iio_for_each_active_channel()) without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode in the middle of the interrupt that flushes the fifo. Fix this by calling synchronize_irq() to ensure that no interrupt is currently running when disabling buffer mode. Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [...] _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290 fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178 fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c irq_thread_fn from irq_thread+0x110/0x1f4 irq_thread from kthread+0xe0/0xfc kthread from ret_from_fork+0x14/0x2c
- https://git.kernel.org/stable/c/1803d372460aaa9ae0188a30c9421d3f157f2f04
- https://git.kernel.org/stable/c/1fe16dc1a2f5057772e5391ec042ed7442966c9a
- https://git.kernel.org/stable/c/6ecd61c201b27ad2760b3975437ad2b97d725b98
- https://git.kernel.org/stable/c/bfcda3e1015791b3a63fb4d3aad408da9cf76e8f
- https://git.kernel.org/stable/c/dda42f23a8f5439eaac9521ce0531547d880cc54
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38487
In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled Mitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ...
- https://git.kernel.org/stable/c/166afe964e8433d52c641f5d1c09102bacee9a92
- https://git.kernel.org/stable/c/329a80adc0e5f815d0514a6d403aaaf0995cd9be
- https://git.kernel.org/stable/c/56448e78a6bb4e1a8528a0e2efe94eff0400c247
- https://git.kernel.org/stable/c/62e51f51d97477ea4e78c82e7076a171dac86c75
- https://git.kernel.org/stable/c/9e1d2b97f5e2a36a2fd30a8bd30ead9dac5e3a51
- https://git.kernel.org/stable/c/ac10ed9862104936a412f8b475c869e99f048448
- https://git.kernel.org/stable/c/b361598b7352f02456619a6105c7da952ef69f8f
- https://git.kernel.org/stable/c/dc5598482e2d3b234f6d72d6f5568e24f603e51a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38488
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in crypt_message when using async crypto The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...); Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory. This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences. The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected. Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for async completion notification - crypto_wait_req() to wait for operation completion This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.
- https://git.kernel.org/stable/c/15a0a5de49507062bc3be4014a403d8cea5533de
- https://git.kernel.org/stable/c/2a76bc2b24ed889a689fb1c9015307bf16aafb5b
- https://git.kernel.org/stable/c/5d047b12f86cc3b9fde1171c02d9bccf4dba0632
- https://git.kernel.org/stable/c/6550b2bef095d0dd2d2c8390d2ea4c3837028833
- https://git.kernel.org/stable/c/8ac90f6824fc44d2e55a82503ddfc95defb19ae0
- https://git.kernel.org/stable/c/9a1d3e8d40f151c2d5a5f40c410e6e433f62f438
- https://git.kernel.org/stable/c/b220bed63330c0e1733dc06ea8e75d5b9962b6b6
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38489
In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear. Restore the fix and add a comment.
Modified: 2025-11-19
CVE-2025-38490
In the Linux kernel, the following vulnerability has been resolved:
net: libwx: remove duplicate page_pool_put_full_page()
page_pool_put_full_page() should only be invoked when freeing Rx buffers
or building a skb if the size is too short. At other times, the pages
need to be reused. So remove the redundant page put. In the original
code, double free pages cause kernel panic:
[ 876.949834] __irq_exit_rcu+0xc7/0x130
[ 876.949836] common_interrupt+0xb8/0xd0
[ 876.949838]
[ 876.949838]
Modified: 2026-01-07
CVE-2025-38491
In the Linux kernel, the following vulnerability has been resolved:
mptcp: make fallback action and fallback decision atomic
Syzkaller reported the following splat:
WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]
WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]
WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline]
WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153
Modules linked in:
CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary)
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]
RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]
RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline]
RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153
Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00
RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45
RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001
RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000
FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0
Call Trace:
- https://git.kernel.org/stable/c/1d82a8fe6ee4afdc92f4e8808c9dad2a6095bbc5
- https://git.kernel.org/stable/c/54999dea879fecb761225e28f274b40662918c30
- https://git.kernel.org/stable/c/5586518bec27666c747cd52aabb62d485686d0bf
- https://git.kernel.org/stable/c/75a4c9ab8a7af0d76b31ccd1188ed178c38b35d2
- https://git.kernel.org/stable/c/f8a1d9b18c5efc76784f5a326e905f641f839894
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38493
In the Linux kernel, the following vulnerability has been resolved:
tracing/osnoise: Fix crash in timerlat_dump_stack()
We have observed kernel panics when using timerlat with stack saving,
with the following dmesg output:
memcpy: detected buffer overflow: 88 byte write of buffer size 0
WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0
CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy)
Call Trace:
Modified: 2026-03-17
CVE-2025-38494
In the Linux kernel, the following vulnerability has been resolved: HID: core: do not bypass hid_hw_raw_request hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.
- https://git.kernel.org/stable/c/0e5017d84d650ca0eeaf4a3fe9264c5dbc886b81
- https://git.kernel.org/stable/c/19d1314d46c0d8a5c08ab53ddeb62280c77698c0
- https://git.kernel.org/stable/c/40e25aa7e4e0f2440c73a683ee448e41c7c344ed
- https://git.kernel.org/stable/c/a62a895edb2bfebffa865b5129a66e3b4287f34f
- https://git.kernel.org/stable/c/c2ca42f190b6714d6c481dfd3d9b62ea091c946b
- https://git.kernel.org/stable/c/d18f63e848840100dbc351a82e7042eac5a28cf5
- https://git.kernel.org/stable/c/dd8e8314f2ce225dade5248dcfb9e2ac0edda624
- https://git.kernel.org/stable/c/f10923b8d32a473b229477b63f23bbd72b1e9910
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38495
In the Linux kernel, the following vulnerability has been resolved: HID: core: ensure the allocated report buffer can contain the reserved report ID When the report ID is not used, the low level transport drivers expect the first byte to be 0. However, currently the allocated buffer not account for that extra byte, meaning that instead of having 8 guaranteed bytes for implement to be working, we only have 7.
- https://git.kernel.org/stable/c/4f15ee98304b96e164ff2340e1dfd6181c3f42aa
- https://git.kernel.org/stable/c/7228e36c7875e4b035374cf68ca5e44dffa596b2
- https://git.kernel.org/stable/c/7fa83d0043370003e9a0b46ab7ae8f53b00fab06
- https://git.kernel.org/stable/c/9f2892f7233a8f1320fe671d0f95f122191bfbcd
- https://git.kernel.org/stable/c/a262370f385e53ff7470efdcdaf40468e5756717
- https://git.kernel.org/stable/c/a47d9d9895bad9ce0e840a39836f19ca0b2a343a
- https://git.kernel.org/stable/c/d3ed1d84a84538a39b3eb2055d6a97a936c108f2
- https://git.kernel.org/stable/c/fcda39a9c5b834346088c14b1374336b079466c1
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38496
In the Linux kernel, the following vulnerability has been resolved:
dm-bufio: fix sched in atomic context
If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP
is enabled for dm-bufio. However, when bufio tries to evict buffers, there
is a chance to trigger scheduling in spin_lock_bh, the following warning
is hit:
BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2
preempt_count: 201, expected: 0
RCU nest depth: 0, expected: 0
4 locks held by kworker/2:2/123:
#0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970
#1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970
#2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710
#3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710
Preemption disabled at:
[<0000000000000000>] 0x0
CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: dm_bufio_cache do_global_cleanup
Call Trace:
Modified: 2026-01-07
CVE-2025-38497
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Fix OOB read on empty string write When writing an empty string to either 'qw_sign' or 'landingPage' sysfs attributes, the store functions attempt to access page[l - 1] before validating that the length 'l' is greater than zero. This patch fixes the vulnerability by adding a check at the beginning of os_desc_qw_sign_store() and webusb_landingPage_store() to handle the zero-length input case gracefully by returning immediately.
- https://git.kernel.org/stable/c/15a87206879951712915c03c8952a73d6a74721e
- https://git.kernel.org/stable/c/22b7897c289cc25d99c603f5144096142a30d897
- https://git.kernel.org/stable/c/2798111f8e504ac747cce911226135d50b8de468
- https://git.kernel.org/stable/c/3014168731b7930300aab656085af784edc861f6
- https://git.kernel.org/stable/c/58bdd5160184645771553ea732da5c2887fc9bd1
- https://git.kernel.org/stable/c/783ea37b237a9b524f1e5ca018ea17d772ee0ea0
- https://git.kernel.org/stable/c/78b41148cfea2a3f04d87adf3a71b21735820a37
- https://git.kernel.org/stable/c/d68b7c8fefbaeae8f065b84e40cf64baf4cc0c76
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38498
In the Linux kernel, the following vulnerability has been resolved: do_change_type(): refuse to operate on unmounted/not ours mounts Ensure that propagation settings can only be changed for mounts located in the caller's mount namespace. This change aligns permission checking with the rest of mount(2).
- https://git.kernel.org/stable/c/064014f7812744451d5d0592f3d2bcd727f2ee93
- https://git.kernel.org/stable/c/12f147ddd6de7382dad54812e65f3f08d05809fc
- https://git.kernel.org/stable/c/19554c79a2095ddde850906a067915c1ef3a4114
- https://git.kernel.org/stable/c/432a171d60056489270c462e651e6c3a13f855b1
- https://git.kernel.org/stable/c/4f091ad0862b02dc42a19a120b7048de848561f8
- https://git.kernel.org/stable/c/787937c4e373f1722c4343e5a5a4eb0f8543e589
- https://git.kernel.org/stable/c/9c1ddfeb662b668fff69c5f1cfdd9f5d23d55d23
- https://git.kernel.org/stable/c/c7d11fdf8e5db5f34a6c062c7e6ba3a0971879d2
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38499
In the Linux kernel, the following vulnerability has been resolved: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above.
- https://git.kernel.org/stable/c/36fecd740de2d542d2091d65d36554ee2bcf9c65
- https://git.kernel.org/stable/c/38628ae06e2a37770cd794802a3f1310cf9846e3
- https://git.kernel.org/stable/c/c28f922c9dcee0e4876a2c095939d77fe7e15116
- https://git.kernel.org/stable/c/d717325b5ecf2a40daca85c61923e17f32306179
- https://git.kernel.org/stable/c/dc6a664089f10eab0fb36b6e4f705022210191d2
- https://git.kernel.org/stable/c/e77078e52fbf018ab986efb3c79065ab35025607
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38500
In the Linux kernel, the following vulnerability has been resolved:
xfrm: interface: fix use-after-free after changing collect_md xfrm interface
collect_md property on xfrm interfaces can only be set on device creation,
thus xfrmi_changelink() should fail when called on such interfaces.
The check to enforce this was done only in the case where the xi was
returned from xfrmi_locate() which doesn't look for the collect_md
interface, and thus the validation was never reached.
Calling changelink would thus errornously place the special interface xi
in the xfrmi_net->xfrmi hash, but since it also exists in the
xfrmi_net->collect_md_xfrmi pointer it would lead to a double free when
the net namespace was taken down [1].
Change the check to use the xi from netdev_priv which is available earlier
in the function to prevent changes in xfrm collect_md interfaces.
[1] resulting oops:
[ 8.516540] kernel BUG at net/core/dev.c:12029!
[ 8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[ 8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary)
[ 8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 8.516569] Workqueue: netns cleanup_net
[ 8.516579] RIP: 0010:unregister_netdevice_many_notify+0x101/0xab0
[ 8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24
[ 8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206
[ 8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60
[ 8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122
[ 8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100
[ 8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00
[ 8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00
[ 8.516615] FS: 0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000
[ 8.516619] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0
[ 8.516625] PKRU: 55555554
[ 8.516627] Call Trace:
[ 8.516632]
- https://git.kernel.org/stable/c/5918c3f4800a3aef2173865e5903370f21e24f47
- https://git.kernel.org/stable/c/69a31f7a6a81f5ffd3812c442e09ff0be22960f1
- https://git.kernel.org/stable/c/a8d4748b954584ab7bd800f1a4e46d5b0eeb5ce4
- https://git.kernel.org/stable/c/a90b2a1aaacbcf0f91d7e4868ad6c51c5dee814b
- https://git.kernel.org/stable/c/bfebdb85496e1da21d3cf05de099210915c3e706
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-22
CVE-2025-38503
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix assertion when building free space tree When building the free space tree with the block group tree feature enabled, we can hit an assertion failure like this: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]--- This happens because we are processing an empty block group, which has no extents allocated from it, there are no items for this block group, including the block group item since block group items are stored in a dedicated tree when using the block group tree feature. It also means this is the block group with the highest start offset, so there are no higher keys in the extent root, hence btrfs_search_slot_for_read() returns 1 (no higher key found). Fix this by asserting 'ret' is 0 only if the block group tree feature is not enabled, in which case we should find a block group item for the block group since it's stored in the extent root and block group item keys are greater than extent item keys (the value for BTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and BTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively). In case 'ret' is 1, we just need to add a record to the free space tree which spans the whole block group, and we can achieve this by making 'ret == 0' as the while loop's condition.
- https://git.kernel.org/stable/c/0bcc14f36c7ad37121cf5c0ae18cdde5bfad9c4e
- https://git.kernel.org/stable/c/1961d20f6fa8903266ed9bd77c691924c22c8f02
- https://git.kernel.org/stable/c/6bbe6530b1db7b4365ce9e86144c18c5d73b2c5b
- https://git.kernel.org/stable/c/7c77df23324f60bcff0ea44392e2c82e9486640c
- https://git.kernel.org/stable/c/f4428b2d4c68732653e93f748f538bdee639ff80
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-19
CVE-2025-38505
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: discard erroneous disassoc frames on STA interface When operating in concurrent STA/AP mode with host MLME enabled, the firmware incorrectly sends disassociation frames to the STA interface when clients disconnect from the AP interface. This causes kernel warnings as the STA interface processes disconnect events that don't apply to it: [ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT [ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT) [ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211] [ 1303.370221] sp : ffff800083053be0 [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000 [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 [ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000 [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de [ 1303.446221] Call trace: [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P) [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211] [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex] [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex] [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex] [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex] [ 1303.483734] process_one_work+0x14c/0x28c [ 1303.487845] worker_thread+0x2cc/0x3d4 [ 1303.491680] kthread+0x12c/0x208 [ 1303.495014] ret_from_fork+0x10/0x20 Add validation in the STA receive path to verify that disassoc/deauth frames originate from the connected AP. Frames that fail this check are discarded early, preventing them from reaching the MLME layer and triggering WARN_ON(). This filtering logic is similar with that used in the ieee80211_rx_mgmt_disassoc() function in mac80211, which drops disassoc frames that don't match the current BSSID (!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), ensuring only relevant frames are processed. Tested on: - 8997 with FW 16.68.1.p197
Modified: 2025-11-19
CVE-2025-38506
In the Linux kernel, the following vulnerability has been resolved:
KVM: Allow CPU to reschedule while setting per-page memory attributes
When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),
the host can experience CPU soft lockups when running an operation in
kvm_vm_set_mem_attributes() to set memory attributes on the whole
range of guest memory.
watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]
CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)
Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024
RIP: 0010:xas_create+0x78/0x1f0
Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87
RSP: 0018:ffffad890a34b940 EFLAGS: 00000286
RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000
RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868
R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868
FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0
PKRU: 55555554
Call Trace:
Modified: 2025-11-19
CVE-2025-38507
In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: avoid bluetooth suspend/resume stalls Ensure we don't stall or panic the kernel when using bluetooth-connected controllers. This was reported as an issue on android devices using kernel 6.6 due to the resume hook which had been added for usb joycons. First, set a new state value to JOYCON_CTLR_STATE_SUSPENDED in a newly-added nintendo_hid_suspend. This makes sure we will not stall out the kernel waiting for input reports during led classdev suspend. The stalls could happen if connectivity is unreliable or lost to the controller prior to suspend. Second, since we lose connectivity during suspend, do not try joycon_init() for bluetooth controllers in the nintendo_hid_resume path. Tested via multiple suspend/resume flows when using the controller both in USB and bluetooth modes.
Modified: 2026-01-07
CVE-2025-38510
In the Linux kernel, the following vulnerability has been resolved:
kasan: remove kasan_find_vm_area() to prevent possible deadlock
find_vm_area() couldn't be called in atomic_context. If find_vm_area() is
called to reports vm area information, kasan can trigger deadlock like:
CPU0 CPU1
vmalloc();
alloc_vmap_area();
spin_lock(&vn->busy.lock)
spin_lock_bh(&some_lock);
- https://git.kernel.org/stable/c/0c3566d831def922cd56322c772a7b20d8b0e0c0
- https://git.kernel.org/stable/c/2d89dab1ea6086e6cbe6fe92531b496fb6808cb9
- https://git.kernel.org/stable/c/595f78d99b9051600233c0a5c4c47e1097e6ed01
- https://git.kernel.org/stable/c/6ee9b3d84775944fb8c8a447961cd01274ac671c
- https://git.kernel.org/stable/c/8377d7744bdce5c4b3f1b58924eebd3fdc078dfc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38511
In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Clear all LMTT pages on alloc Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages. Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap. While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle. (cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)
Modified: 2026-01-07
CVE-2025-38512
In the Linux kernel, the following vulnerability has been resolved: wifi: prevent A-MSDU attacks in mesh networks This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks. This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt. This defense was tested with mac80211_hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field. It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented. Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation: https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
- https://git.kernel.org/stable/c/6e3b09402cc6c3e3474fa548e8adf6897dda05de
- https://git.kernel.org/stable/c/737bb912ebbe4571195c56eba557c4d7315b26fb
- https://git.kernel.org/stable/c/e01851f6e9a665a6011b14714b271d3e6b0b8d32
- https://git.kernel.org/stable/c/e2c8a3c0388aef6bfc4aabfba07bc7dff16eea80
- https://git.kernel.org/stable/c/ec6392061de6681148b63ee6c8744da833498cdd
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38513
In the Linux kernel, the following vulnerability has been resolved:
wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()
There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For
example, the following is possible:
T0 T1
zd_mac_tx_to_dev()
/* len == skb_queue_len(q) */
while (len > ZD_MAC_MAX_ACK_WAITERS) {
filter_ack()
spin_lock_irqsave(&q->lock, flags);
/* position == skb_queue_len(q) */
for (i=1; i
- https://git.kernel.org/stable/c/014c34dc132015c4f918ada4982e952947ac1047
- https://git.kernel.org/stable/c/5420de65efbeb6503bcf1d43451c9df67ad60298
- https://git.kernel.org/stable/c/602b4eb2f25668de15de69860ec99caf65b3684d
- https://git.kernel.org/stable/c/74b1ec9f5d627d2bdd5e5b6f3f81c23317657023
- https://git.kernel.org/stable/c/adf08c96b963c7cd7ec1ee1c0c556228d9bedaae
- https://git.kernel.org/stable/c/b24f65c184540dfb967479320ecf7e8c2e9220dc
- https://git.kernel.org/stable/c/c1958270de947604cc6de05fc96dbba256b49cf0
- https://git.kernel.org/stable/c/fcd9c923b58e86501450b9b442ccc7ce4a8d0fda
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-22
CVE-2025-38514
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix oops due to non-existence of prealloc backlog struct If an AF_RXRPC service socket is opened and bound, but calls are preallocated, then rxrpc_alloc_incoming_call() will oops because the rxrpc_backlog struct doesn't get allocated until the first preallocation is made. Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no backlog struct. This will cause the incoming call to be aborted.
- https://git.kernel.org/stable/c/0eef29385d715d4c7fd707b18d4a9b76c76dd5e6
- https://git.kernel.org/stable/c/2c2e9ebeb036f9b1b09325ec5cfdfe0e78f357c3
- https://git.kernel.org/stable/c/880a88f318cf1d2a0f4c0a7ff7b07e2062b434a4
- https://git.kernel.org/stable/c/bf0ca6a1bc4fb904b598137c6718785a107e3adf
- https://git.kernel.org/stable/c/d1ff5f9d2c5405681457262e23c720b08977c11f
- https://git.kernel.org/stable/c/efc1b2b7c1a308b60df8f36bc2d7ce16d3999364
- https://git.kernel.org/stable/c/f5e72b7824d08c206ce106d30cb37c4642900ccc
- https://git.kernel.org/stable/c/f7afb3ff01c42c49e8a143cdce400b95844bb506
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38515
In the Linux kernel, the following vulnerability has been resolved: drm/sched: Increment job count before swapping tail spsc queue A small race exists between spsc_queue_push and the run-job worker, in which spsc_queue_push may return not-first while the run-job worker has already idled due to the job count being zero. If this race occurs, job scheduling stops, leading to hangs while waiting on the job’s DMA fences. Seal this race by incrementing the job count before appending to the SPSC queue. This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in an SVM test case.
- https://git.kernel.org/stable/c/549a9c78c3ea6807d0dc4162a4f5ba59f217d5a0
- https://git.kernel.org/stable/c/8af39ec5cf2be522c8eb43a3d8005ed59e4daaee
- https://git.kernel.org/stable/c/c64f5310530baf75328292f9b9f3f2961d185183
- https://git.kernel.org/stable/c/e2d6547dc8b9b332f9bc00875197287a6a4db65a
- https://git.kernel.org/stable/c/e62f51d0ec8a9baf324caf9a564f8e318d36a551
- https://git.kernel.org/stable/c/ef58a95457466849fa7b31fd3953801a5af0f58b
- https://git.kernel.org/stable/c/ef841f8e4e1ff67817ca899bedc5ebb00847c0a7
- https://git.kernel.org/stable/c/f9a4f28a4fc4ee453a92a9abbe36e26224d17749
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38516
In the Linux kernel, the following vulnerability has been resolved: pinctrl: qcom: msm: mark certain pins as invalid for interrupts On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: `gpiomon -c 0 113` on RB2. The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs. This function can be extended if we determine that there are more corner-cases like this.
- https://git.kernel.org/stable/c/1d57f7132662e96aace3b8a000616efde289aae1
- https://git.kernel.org/stable/c/275605a8b48002fe98675a5c06f3e39c09067ff2
- https://git.kernel.org/stable/c/3f8fc02c2582c1dfad1785e9c7bc8b4e1521af0a
- https://git.kernel.org/stable/c/6a89563ccf9cd0d745e2291302878a061508573f
- https://git.kernel.org/stable/c/93712205ce2f1fb047739494c0399a26ea4f0890
- https://git.kernel.org/stable/c/97c9c7daeeb00c6e1d5e84084041f79c2d2dce22
- https://git.kernel.org/stable/c/cb4b08a095b1fa4b3fca782757517e4e9a917d8e
- https://git.kernel.org/stable/c/cc145e02d6b8494c48f91958d52fa76b7e577f7b
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38517
In the Linux kernel, the following vulnerability has been resolved:
lib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users()
alloc_tag_top_users() attempts to lock alloc_tag_cttype->mod_lock even
when the alloc_tag_cttype is not allocated because:
1) alloc tagging is disabled because mem profiling is disabled
(!alloc_tag_cttype)
2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttype)
3) alloc tagging is enabled, but failed initialization
(!alloc_tag_cttype or IS_ERR(alloc_tag_cttype))
In all cases, alloc_tag_cttype is not allocated, and therefore
alloc_tag_top_users() should not attempt to acquire the semaphore.
This leads to a crash on memory allocation failure by attempting to
acquire a non-existent semaphore:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df]
CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G D 6.16.0-rc2 #1 VOLUNTARY
Tainted: [D]=DIE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:down_read_trylock+0xaa/0x3b0
Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff
RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016
RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000
RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070
RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1
R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37
R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000
FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0
Call Trace:
Modified: 2026-01-07
CVE-2025-38520
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Don't call mmput from MMU notifier callback If the process is exiting, the mmput inside mmu notifier callback from compactd or fork or numa balancing could release the last reference of mm struct to call exit_mmap and free_pgtable, this triggers deadlock with below backtrace. The deadlock will leak kfd process as mmu notifier release is not called and cause VRAM leaking. The fix is to take mm reference mmget_non_zero when adding prange to the deferred list to pair with mmput in deferred list work. If prange split and add into pchild list, the pchild work_item.mm is not used, so remove the mm parameter from svm_range_unmap_split and svm_range_add_child. The backtrace of hung task: INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu] (cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
- https://git.kernel.org/stable/c/145a56bd68f4bff098d59fbc7c263d20dfef4fc4
- https://git.kernel.org/stable/c/a7eb0a25010a674c8fdfbece38353ef7be8c5834
- https://git.kernel.org/stable/c/c1bde9d48e09933c361521720f77a8072083c83a
- https://git.kernel.org/stable/c/cf234231fcbc7d391e2135b9518613218cc5347f
- https://git.kernel.org/stable/c/e90ee15ce28c61f6d83a0511c3e02e2662478350
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-22
CVE-2025-38521
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix kernel crash when hard resetting the GPU The GPU hard reset sequence calls pm_runtime_force_suspend() and pm_runtime_force_resume(), which according to their documentation should only be used during system-wide PM transitions to sleep states. The main issue though is that depending on some internal runtime PM state as seen by pm_runtime_force_suspend() (whether the usage count is <= 1), pm_runtime_force_resume() might not resume the device unless needed. If that happens, the runtime PM resume callback pvr_power_device_resume() is not called, the GPU clocks are not re-enabled, and the kernel crashes on the next attempt to access GPU registers as part of the power-on sequence. Replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume() with direct calls to the driver's runtime PM callbacks, pvr_power_device_suspend() and pvr_power_device_resume(), to ensure clocks are re-enabled and avoid the kernel crash.
Modified: 2025-11-18
CVE-2025-38523
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix the smbd_response slab to allow usercopy
The handling of received data in the smbdirect client code involves using
copy_to_iter() to copy data from the smbd_reponse struct's packet trailer
to a folioq buffer provided by netfslib that encapsulates a chunk of
pagecache.
If, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks
then performed in copy_to_iter() oopsing with something like the following:
CIFS: Attempting to mount //172.31.9.1/test
CIFS: VFS: RDMA transport established
usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)!
------------[ cut here ]------------
kernel BUG at mm/usercopy.c:102!
...
RIP: 0010:usercopy_abort+0x6c/0x80
...
Call Trace:
Modified: 2025-11-18
CVE-2025-38524
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recv-recv race of completed call If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again. In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474! Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale.
Modified: 2025-11-18
CVE-2025-38526
In the Linux kernel, the following vulnerability has been resolved: ice: add NULL check in eswitch lag check The function ice_lag_is_switchdev_running() is being called from outside of the LAG event handler code. This results in the lag->upper_netdev being NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a check before it is dereferenced.
Modified: 2026-01-07
CVE-2025-38527
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in cifs_oplock_break A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free. Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.
- https://git.kernel.org/stable/c/09bce2138a30ef10d8821c8c3f73a4ab7a5726bc
- https://git.kernel.org/stable/c/0a4eec84d4d2c4085d4ed8630fd74e4b39033c1b
- https://git.kernel.org/stable/c/2baaf5bbab2ac474c4f92c10fcb3310f824db995
- https://git.kernel.org/stable/c/4256a483fe58af66a46cbf3dc48ff26e580d3308
- https://git.kernel.org/stable/c/705c79101ccf9edea5a00d761491a03ced314210
- https://git.kernel.org/stable/c/da11bd4b697b393a207f19a2ed7d382a811a3ddc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38528
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject %p% format string in bprintf-like helpers static const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt)); The above BPF program isn't rejected and causes a kernel warning at runtime: Please remove unsupported %\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0 This happens because bpf_bprintf_prepare skips over the second %, detected as punctuation, while processing %p. This patch fixes it by not skipping over punctuation. %\x00 is then processed in the next iteration and rejected.
- https://git.kernel.org/stable/c/1c5f5fd47bbda17cb885fe6f03730702cd53d3f8
- https://git.kernel.org/stable/c/61d5fa45ed13e42af14c7e959baba9908b8ee6d4
- https://git.kernel.org/stable/c/6952aeace93f8c9ea01849efecac24dd3152c9c9
- https://git.kernel.org/stable/c/97303e541e12f1fea97834ec64b98991e8775f39
- https://git.kernel.org/stable/c/e7be679124bae8cf4fa6e40d7e1661baddfb3289
- https://git.kernel.org/stable/c/f8242745871f81a3ac37f9f51853d12854fd0b58
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38529
In the Linux kernel, the following vulnerability has been resolved: comedi: aio_iiro_16: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.
- https://git.kernel.org/stable/c/43ddd82e6a91913cea1c078e782afd8de60c3a53
- https://git.kernel.org/stable/c/5ac7c60439236fb691b8c7987390e2327bbf18fa
- https://git.kernel.org/stable/c/66acb1586737a22dd7b78abc63213b1bcaa100e4
- https://git.kernel.org/stable/c/955e8835855fed8e87f7d8c8075564a1746c1b4c
- https://git.kernel.org/stable/c/a88692245c315bf8e225f205297a6f4b13d6856a
- https://git.kernel.org/stable/c/c593215385f0c0163015cca4512ed3ff42875d19
- https://git.kernel.org/stable/c/e0f3c0867d7d231c70984f05c97752caacd0daba
- https://git.kernel.org/stable/c/ff30dd3f15f443d2a0085b12ec2cc95d44f35fa7
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38530
In the Linux kernel, the following vulnerability has been resolved: comedi: pcl812: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts.
- https://git.kernel.org/stable/c/0489c30d080f07cc7f09d04de723d8c2ccdb61ef
- https://git.kernel.org/stable/c/16c173abee315953fd17a279352fec4a1faee862
- https://git.kernel.org/stable/c/29ef03e5b84431171d6b77b822985b54bc44b793
- https://git.kernel.org/stable/c/374d9b3eb4b08407997ef1fce96119d31e0c0bc4
- https://git.kernel.org/stable/c/5bfa301e1e59a9b1a7b62a800b54852337c97416
- https://git.kernel.org/stable/c/7e470d8efd10725b189ca8951973a8425932398a
- https://git.kernel.org/stable/c/a27e27eee313fe1c450b6af1e80e64412546cab4
- https://git.kernel.org/stable/c/b14b076ce593f72585412fc7fd3747e03a5e3632
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-04-27
CVE-2025-38531
In the Linux kernel, the following vulnerability has been resolved: iio: common: st_sensors: Fix use of uninitialize device structs Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device. This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well. The issue is reported and traced here: [1]
Modified: 2025-11-18
CVE-2025-38532
In the Linux kernel, the following vulnerability has been resolved:
net: libwx: properly reset Rx ring descriptor
When device reset is triggered by feature changes such as toggling Rx
VLAN offload, wx->do_reset() is called to reinitialize Rx rings. The
hardware descriptor ring may retain stale values from previous sessions.
And only set the length to 0 in rx_desc[0] would result in building
malformed SKBs. Fix it to ensure a clean slate after device reset.
[ 549.186435] [ C16] ------------[ cut here ]------------
[ 549.186457] [ C16] kernel BUG at net/core/skbuff.c:2814!
[ 549.186468] [ C16] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[ 549.186472] [ C16] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Kdump: loaded Not tainted 6.16.0-rc4+ #23 PREEMPT(voluntary)
[ 549.186476] [ C16] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024
[ 549.186478] [ C16] RIP: 0010:__pskb_pull_tail+0x3ff/0x510
[ 549.186484] [ C16] Code: 06 f0 ff 4f 34 74 7b 4d 8b 8c 24 c8 00 00 00 45 8b 84 24 c0 00 00 00 e9 c8 fd ff ff 48 c7 44 24 08 00 00 00 00 e9 5e fe ff ff <0f> 0b 31 c0 e9 23 90 5b ff 41 f7 c6 ff 0f 00 00 75 bf 49 8b 06 a8
[ 549.186487] [ C16] RSP: 0018:ffffb391c0640d70 EFLAGS: 00010282
[ 549.186490] [ C16] RAX: 00000000fffffff2 RBX: ffff8fe7e4d40200 RCX: 00000000fffffff2
[ 549.186492] [ C16] RDX: ffff8fe7c3a4bf8e RSI: 0000000000000180 RDI: ffff8fe7c3a4bf40
[ 549.186494] [ C16] RBP: ffffb391c0640da8 R08: ffff8fe7c3a4c0c0 R09: 000000000000000e
[ 549.186496] [ C16] R10: ffffb391c0640d88 R11: 000000000000000e R12: ffff8fe7e4d40200
[ 549.186497] [ C16] R13: 00000000fffffff2 R14: ffff8fe7fa01a000 R15: 00000000fffffff2
[ 549.186499] [ C16] FS: 0000000000000000(0000) GS:ffff8fef5ae40000(0000) knlGS:0000000000000000
[ 549.186502] [ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 549.186503] [ C16] CR2: 00007f77d81d6000 CR3: 000000051a032000 CR4: 0000000000750ef0
[ 549.186505] [ C16] PKRU: 55555554
[ 549.186507] [ C16] Call Trace:
[ 549.186510] [ C16]
Modified: 2025-11-18
CVE-2025-38533
In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix the using of Rx buffer DMA The wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Althrough such error has not yet occurred, it is worth fixing in the code.
Modified: 2026-01-07
CVE-2025-38535
In the Linux kernel, the following vulnerability has been resolved: phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code assumed that the regulator should be disabled. However, if the regulator is marked as always-on, regulator_is_enabled() continues to return true, leading to an incorrect attempt to disable a regulator which is not enabled. This can result in warnings such as: [ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004 _regulator_disable+0xe4/0x1a0 [ 250.155652] unbalanced disables for VIN_SYS_5V0 To fix this, we move the regulator control logic into tegra186_xusb_padctl_id_override() function since it's directly related to the ID override state. The regulator is now only disabled when the role transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID register. This ensures that regulator enable/disable operations are properly balanced and only occur when actually transitioning to/from host mode.
- https://git.kernel.org/stable/c/1bb85b5c2bd43b687c3d54eb6328917f90dd38fc
- https://git.kernel.org/stable/c/5367cdeb75cb6c687ca468450bceb2602ab239d8
- https://git.kernel.org/stable/c/cdcb0ffd6448f6be898956913a42bd08e59fb2ae
- https://git.kernel.org/stable/c/ceb645ac6ce052609ee5c8f819a80e8881789b04
- https://git.kernel.org/stable/c/cefc1caee9dd06c69e2d807edc5949b329f52b22
- https://git.kernel.org/stable/c/eaa420339658615d26c1cc95cd6cf720b9aebfca
- https://git.kernel.org/stable/c/ec7f98ff05f0649af0adeb4808c7ba23d6111ef9
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38537
In the Linux kernel, the following vulnerability has been resolved: net: phy: Don't register LEDs for genphy If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them.
Modified: 2026-01-07
CVE-2025-38538
In the Linux kernel, the following vulnerability has been resolved: dmaengine: nbpfaxi: Fix memory corruption in probe() The nbpf->chan[] array is allocated earlier in the nbpf_probe() function and it has "num_channels" elements. These three loops iterate one element farther than they should and corrupt memory. The changes to the second loop are more involved. In this case, we're copying data from the irqbuf[] array into the nbpf->chan[] array. If the data in irqbuf[i] is the error IRQ then we skip it, so the iterators are not in sync. I added a check to ensure that we don't go beyond the end of the irqbuf[] array. I'm pretty sure this can't happen, but it seemed harmless to add a check. On the other hand, after the loop has ended there is a check to ensure that the "chan" iterator is where we expect it to be. In the original code we went one element beyond the end of the array so the iterator wasn't in the correct place and it would always return -EINVAL. However, now it will always be in the correct place. I deleted the check since we know the result.
- https://git.kernel.org/stable/c/122160289adf8ebf15060f1cbf6265b55a914948
- https://git.kernel.org/stable/c/188c6ba1dd925849c5d94885c8bbdeb0b3dcf510
- https://git.kernel.org/stable/c/24861ef8b517a309a4225f2793be0cd8fa0bec9e
- https://git.kernel.org/stable/c/4bb016438335ec02b01f96bf1367378c2bfe03e5
- https://git.kernel.org/stable/c/84fff8e6f11b9af1407e273995b5257d99ff0cff
- https://git.kernel.org/stable/c/aec396b4f736f3f8d2c28a9cd2924a4ada57ae87
- https://git.kernel.org/stable/c/d6bbd67ab5de37a74ac85c83c5a26664b62034dd
- https://git.kernel.org/stable/c/f366b36c5e3ce29c9a3c8eed3d1631908e4fc8bb
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38539
In the Linux kernel, the following vulnerability has been resolved: tracing: Add down_write(trace_event_sem) when adding trace event When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values. If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel. The addition of the event should take the trace_event_sem for write while it adds the new event. Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list.
- https://git.kernel.org/stable/c/33e20747b47ddc03569b6bc27a2d6894c1428182
- https://git.kernel.org/stable/c/6bc94f20a4c304997288f9a45278c9d0c06987d3
- https://git.kernel.org/stable/c/70fecd519caad0c1741c3379d5348c9000a5b29d
- https://git.kernel.org/stable/c/7803b28c9aa8d8bd4e19ebcf5f0db9612b0f333b
- https://git.kernel.org/stable/c/b5e8acc14dcb314a9b61ff19dcd9fdd0d88f70df
- https://git.kernel.org/stable/c/ca60064ea03f14e06c763de018403cb56ba3207d
- https://git.kernel.org/stable/c/db45632479ceecb669612ed8dbce927e3c6279fc
- https://git.kernel.org/stable/c/e70f5ee4c8824736332351b703c46f9469ed7f6c
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-22
CVE-2025-38540
In the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.
- https://git.kernel.org/stable/c/1b297ab6f38ca60a4ca7298b297944ec6043b2f4
- https://git.kernel.org/stable/c/2b0931eee48208c25bb77486946dea8e96aa6a36
- https://git.kernel.org/stable/c/35f1a5360ac68d9629abbb3930a0a07901cba296
- https://git.kernel.org/stable/c/3ce1d87d1f5d80322757aa917182deb7370963b9
- https://git.kernel.org/stable/c/54bae4c17c11688339eb73a04fd24203bb6e7494
- https://git.kernel.org/stable/c/7ac00f019698f614a49cce34c198d0568ab0e1c2
- https://git.kernel.org/stable/c/a2a91abd19c574b598b1c69ad76ad9c7eedaf062
- https://git.kernel.org/stable/c/c72536350e82b53a1be0f3bfdf1511bba2827102
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38541
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: Fix null-ptr-deref in mt7925_thermal_init() devm_kasprintf() returns NULL on error. Currently, mt7925_thermal_init() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.
Modified: 2026-01-07
CVE-2025-38542
In the Linux kernel, the following vulnerability has been resolved: net: appletalk: Fix device refcount leak in atrtr_create() When updating an existing route entry in atrtr_create(), the old device reference was not being released before assigning the new device, leading to a device refcount leak. Fix this by calling dev_put() to release the old device reference before holding the new one.
- https://git.kernel.org/stable/c/473f3eadfc73b0fb6d8dee5829d19a5772e387f7
- https://git.kernel.org/stable/c/4a17370da6e476d3d275534e9e9cd2d02c57ca46
- https://git.kernel.org/stable/c/64124cf0aab0dd1e18c0fb5ae66e45741e727f8b
- https://git.kernel.org/stable/c/711c80f7d8b163d3ecd463cd96f07230f488e750
- https://git.kernel.org/stable/c/a7852b01793669248dce0348d14df89e77a32afd
- https://git.kernel.org/stable/c/b2f5dfa87367fdce9f8b995bc6c38f64f9ea2c90
- https://git.kernel.org/stable/c/b92bedf71f25303e203a4e657489d76691a58119
- https://git.kernel.org/stable/c/d2e9f50f0bdad73b64a871f25186b899624518c4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38543
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: nvdec: Fix dma_alloc_coherent error check Check for NULL return value with dma_alloc_coherent, in line with Robin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.
- https://git.kernel.org/stable/c/2e0812eedccd0629d73c9d0b1184a5db055df1da
- https://git.kernel.org/stable/c/44306a684cd1699b8562a54945ddc43e2abc9eab
- https://git.kernel.org/stable/c/61b8d20962d00b7df117011c52f97cbb9c76a669
- https://git.kernel.org/stable/c/a560de522374af931fa994d161db3667b0bb2545
- https://git.kernel.org/stable/c/d1240029f97ac8c06db4dd4407bbbf83e8d08570
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38544
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix bug due to prealloc collision When userspace is using AF_RXRPC to provide a server, it has to preallocate incoming calls and assign to them call IDs that will be used to thread related recvmsg() and sendmsg() together. The preallocated call IDs will automatically be attached to calls as they come in until the pool is empty. To the kernel, the call IDs are just arbitrary numbers, but userspace can use the call ID to hold a pointer to prepared structs. In any case, the user isn't permitted to create two calls with the same call ID (call IDs become available again when the call ends) and EBADSLT should result from sendmsg() if an attempt is made to preallocate a call with an in-use call ID. However, the cleanup in the error handling will trigger both assertions in rxrpc_cleanup_call() because the call isn't marked complete and isn't marked as having been released. Fix this by setting the call state in rxrpc_service_prealloc_one() and then marking it as being released before calling the cleanup function.
Modified: 2025-11-18
CVE-2025-38545
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for skb_shared_info While transitioning from netdev_alloc_ip_align() to build_skb(), memory for the "skb_shared_info" member of an "skb" was not allocated. Fix this by allocating "PAGE_SIZE" as the skb length, accounting for the packet length, headroom and tailroom, thereby including the required memory space for skb_shared_info.
Modified: 2026-01-07
CVE-2025-38546
In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix memory leak of struct clip_vcc. ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it to vcc->user_back. The code assumes that vcc_destroy_socket() passes NULL skb to vcc->push() when the socket is close()d, and then clip_push() frees clip_vcc. However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() in atm_init_atmarp(), resulting in memory leak. Let's serialise two ioctl() by lock_sock() and check vcc->push() in atm_init_atmarp() to prevent memleak.
- https://git.kernel.org/stable/c/0c17ff462d98c997d707ee5cf4e4a9b1b52b9d90
- https://git.kernel.org/stable/c/1c075e88d5859a2c6b43b27e0e46fb281cef8039
- https://git.kernel.org/stable/c/1fb9fb5a4b5cec2d56e26525ef8c519de858fa60
- https://git.kernel.org/stable/c/2fb37ab3226606cbfc9b2b6f9e301b0b735734c5
- https://git.kernel.org/stable/c/62dba28275a9a3104d4e33595c7b3328d4032d8d
- https://git.kernel.org/stable/c/9e4dbeee56f614e3f1e166e5d0655a999ea185ef
- https://git.kernel.org/stable/c/9f771816f14da6d6157a8c30069091abf6b566fb
- https://git.kernel.org/stable/c/cb2e4a2f8f268d8fba6662f663a2e57846f14a8d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38547
In the Linux kernel, the following vulnerability has been resolved: iio: adc: axp20x_adc: Add missing sentinel to AXP717 ADC channel maps The AXP717 ADC channel maps is missing a sentinel entry at the end. This causes a KASAN warning. Add the missing sentinel entry.
Modified: 2026-01-07
CVE-2025-38548
In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Validate the size of the received input buffer Add buffer_recv_size to store the size of the received bytes. Validate buffer_recv_size in send_usb_cmd().
- https://git.kernel.org/stable/c/0db770e2922389753ddbd6663a5516a32b97b743
- https://git.kernel.org/stable/c/2771d2ee3d95700f34e1e4df6a445c90565cd4e9
- https://git.kernel.org/stable/c/2e6f4d9cfbda52700c126c5a2b93dd2042e8680c
- https://git.kernel.org/stable/c/3c4bdc8a852e446080adc8ceb90ddd67a56e1bb8
- https://git.kernel.org/stable/c/495a4f0dce9c8c4478c242209748f1ee9e4d5820
- https://git.kernel.org/stable/c/4eb5cc48399f89b63acdbfe912fa5c8fe2900147
- https://git.kernel.org/stable/c/eda5e38cc4dd2dcb422840540374910ef2818494
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38549
In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths When processing mount options, efivarfs allocates efivarfs_fs_info (sfi) early in fs_context initialization. However, sfi is associated with the superblock and typically freed when the superblock is destroyed. If the fs_context is released (final put) before fill_super is called—such as on error paths or during reconfiguration—the sfi structure would leak, as ownership never transfers to the superblock. Implement the .free callback in efivarfs_context_ops to ensure any allocated sfi is properly freed if the fs_context is torn down before fill_super, preventing this memory leak.
Modified: 2026-01-07
CVE-2025-38550
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Delay put pmc->idev in mld_del_delrec() pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec() does, the reference should be put after ip6_mc_clear_src() return.
- https://git.kernel.org/stable/c/5f18e0130194550dff734e155029ae734378b5ea
- https://git.kernel.org/stable/c/6e4eec86fe5f6b3fdbc702d1d36ac2a6e7ec0806
- https://git.kernel.org/stable/c/728db00a14cacb37f36e9382ab5fad55caf890cc
- https://git.kernel.org/stable/c/7929d27c747eafe8fca3eecd74a334503ee4c839
- https://git.kernel.org/stable/c/ae3264a25a4635531264728859dbe9c659fad554
- https://git.kernel.org/stable/c/dcbc346f50a009d8b7f4e330f9f2e22d6442fa26
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-18
CVE-2025-38551
In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix recursived rtnl_lock() during probe() The deadlock appears in a stack trace like: virtnet_probe() rtnl_lock() virtio_config_changed_work() netdev_notify_peers() rtnl_lock() It happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the virtio-net driver is still probing. The config_work in probe() will get scheduled until virtnet_open() enables the config change notification via virtio_config_driver_enable().
Modified: 2026-01-07
CVE-2025-38552
In the Linux kernel, the following vulnerability has been resolved: mptcp: plug races between subflow fail and subflow creation We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger. The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock. The socket fallback makes such flag true, and also receiving or sending an MP_FAIL option. The field 'allow_infinite_fallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.
- https://git.kernel.org/stable/c/659da22dee5ff316ba63bdaeeac7b58b5442f6c2
- https://git.kernel.org/stable/c/7c96d519ee15a130842a6513530b4d20acd2bfcd
- https://git.kernel.org/stable/c/c476d627584b7589a134a8b48dd5c6639e4401c5
- https://git.kernel.org/stable/c/def5b7b2643ebba696fc60ddf675dca13f073486
- https://git.kernel.org/stable/c/f81b6fbe13c7fc413b5158cdffc6a59391a2a8db
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-25
CVE-2025-38662
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_priv Given mt8365_dai_set_priv allocate priv_size space to copy priv_data which means we should pass mt8365_i2s_priv[i] or "struct mtk_afe_i2s_priv" instead of afe_priv which has the size of "struct mt8365_afe_private". Otherwise the KASAN complains about. [ 59.389765] BUG: KASAN: global-out-of-bounds in mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm] ... [ 59.394789] Call trace: [ 59.395167] dump_backtrace+0xa0/0x128 [ 59.395733] show_stack+0x20/0x38 [ 59.396238] dump_stack_lvl+0xe8/0x148 [ 59.396806] print_report+0x37c/0x5e0 [ 59.397358] kasan_report+0xac/0xf8 [ 59.397885] kasan_check_range+0xe8/0x190 [ 59.398485] asan_memcpy+0x3c/0x98 [ 59.399022] mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm] [ 59.399928] mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm] [ 59.400893] mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm] [ 59.401873] platform_probe+0xcc/0x228 [ 59.402442] really_probe+0x340/0x9e8 [ 59.402992] driver_probe_device+0x16c/0x3f8 [ 59.403638] driver_probe_device+0x64/0x1d8 [ 59.404256] driver_attach+0x1dc/0x4c8 [ 59.404840] bus_for_each_dev+0x100/0x190 [ 59.405442] driver_attach+0x44/0x68 [ 59.405980] bus_add_driver+0x23c/0x500 [ 59.406550] driver_register+0xf8/0x3d0 [ 59.407122] platform_driver_register+0x68/0x98 [ 59.407810] mt8365_afe_pcm_driver_init+0x2c/0xff8 [snd_soc_mt8365_pcm]
Modified: 2026-01-07
CVE-2025-38663
In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid file types when reading inodes To prevent inodes with invalid file types from tripping through the vfs and causing malfunctions or assertion failures, add a missing sanity check when reading an inode from a block device. If the file type is not valid, treat it as a filesystem error.
- https://git.kernel.org/stable/c/1a5c204e175a78556b8ef1f7683249fa5197295a
- https://git.kernel.org/stable/c/2cf0c4130bf340be3935d097a3dcbfefdcf65815
- https://git.kernel.org/stable/c/42cd46b3a8b1497b9258dc7ac445dbd6beb73e2f
- https://git.kernel.org/stable/c/4aead50caf67e01020c8be1945c3201e8a972a27
- https://git.kernel.org/stable/c/79663a15a1c70ca84f86f2dbba07b423fe7d5d4f
- https://git.kernel.org/stable/c/98872a934ea6a95985fb6a3655a78a5f0c114e82
- https://git.kernel.org/stable/c/bf585ee198bba4ff25b0d80a0891df4656cb0d08
- https://git.kernel.org/stable/c/dd298c0b889acd3ecaf48b6e840c9ab91882e342
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38664
In the Linux kernel, the following vulnerability has been resolved: ice: Fix a null pointer dereference in ice_copy_and_init_pkg() Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.
- https://git.kernel.org/stable/c/0fde7dccbf4c8a6d7940ecaf4c3d80a12f405dd7
- https://git.kernel.org/stable/c/1c30093d58cd3d02d8358e2b1f4a06a0aae0bf5b
- https://git.kernel.org/stable/c/3028f2a4e746b499043bbb8ab816f975473a0535
- https://git.kernel.org/stable/c/35370d3b44efe194fd5ad55bac987e629597d782
- https://git.kernel.org/stable/c/435462f8ab2b9c5340a5414ce02f70117d0cfede
- https://git.kernel.org/stable/c/4ff12d82dac119b4b99b5a78b5af3bf2474c0a36
- https://git.kernel.org/stable/c/6d640a8ea62435a7f6f89869bee4fa99423d07ca
- https://git.kernel.org/stable/c/7c5a13c76dd37e9e4f8d48b87376a54f4399ce15
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38665
In the Linux kernel, the following vulnerability has been resolved: can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode Andrei Lalaev reported a NULL pointer deref when a CAN device is restarted from Bus Off and the driver does not implement the struct can_priv::do_set_mode callback. There are 2 code path that call struct can_priv::do_set_mode: - directly by a manual restart from the user space, via can_changelink() - delayed automatic restart after bus off (deactivated by default) To prevent the NULL pointer deference, refuse a manual restart or configure the automatic restart delay in can_changelink() and report the error via extack to user space. As an additional safety measure let can_restart() return an error if can_priv::do_set_mode is not set instead of dereferencing it unchecked.
- https://git.kernel.org/stable/c/0ca816a96fdcf32644c80cbe7a82c7b6ce6ddda5
- https://git.kernel.org/stable/c/6acceb46180f9e160d4f0c56fcaf39ba562822ae
- https://git.kernel.org/stable/c/6bbcf37c5114926c99a1d1e6993a5b35689d2599
- https://git.kernel.org/stable/c/c1f3f9797c1f44a762e6f5f72520b2e520537b52
- https://git.kernel.org/stable/c/cf81a60a973358dea163f6b14062f17831ceb894
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-07
CVE-2025-38666
In the Linux kernel, the following vulnerability has been resolved:
net: appletalk: Fix use-after-free in AARP proxy probe
The AARP proxy‐probe routine (aarp_proxy_probe_network) sends a probe,
releases the aarp_lock, sleeps, then re-acquires the lock. During that
window an expire timer thread (__aarp_expire_timer) can remove and
kfree() the same entry, leading to a use-after-free.
race condition:
cpu 0 | cpu 1
atalk_sendmsg() | atif_proxy_probe_device()
aarp_send_ddp() | aarp_proxy_probe_network()
mod_timer() | lock(aarp_lock) // LOCK!!
timeout around 200ms | alloc(aarp_entry)
and then call | proxies[hash] = aarp_entry
aarp_expire_timeout() | aarp_send_probe()
| unlock(aarp_lock) // UNLOCK!!
lock(aarp_lock) // LOCK!! | msleep(100);
__aarp_expire_timer(&proxies[ct]) |
free(aarp_entry) |
unlock(aarp_lock) // UNLOCK!! |
| lock(aarp_lock) // LOCK!!
| UAF aarp_entry !!
==================================================================
BUG: KASAN: slab-use-after-free in aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493
Read of size 4 at addr ffff8880123aa360 by task repro/13278
CPU: 3 UID: 0 PID: 13278 Comm: repro Not tainted 6.15.2 #3 PREEMPT(full)
Call Trace:
- https://git.kernel.org/stable/c/186942d19c0222617ef61f50e1dba91e269a5963
- https://git.kernel.org/stable/c/2a6209e4649d45fd85d4193abc481911858ffc6f
- https://git.kernel.org/stable/c/5f02ea0f63dd38c41539ea290fcc1693c73aa8e5
- https://git.kernel.org/stable/c/6c4a92d07b0850342d3becf2e608f805e972467c
- https://git.kernel.org/stable/c/82d19a70ced28b17a38ebf1b6978c6c7db894979
- https://git.kernel.org/stable/c/b35694ffabb2af308a1f725d70f60fd8a47d1f3e
- https://git.kernel.org/stable/c/e4f1564c5b699eb89b3040688fd6b4e57922f1f6
- https://git.kernel.org/stable/c/f90b6bb203f3f38bf2b3d976113d51571df9a482
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-08
CVE-2025-38668
In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix NULL dereference on unbind due to stale coupling data Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind. This can happen during runtime PM or other regulator operations that rely on coupling metadata. For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state. Ensure n_coupled is set to 0 to prevent access to invalid pointers.
- https://git.kernel.org/stable/c/233d3c54c9620e95193923859ea1d0b0f5d748ca
- https://git.kernel.org/stable/c/5d4261dbb3335221fd9c6e69f909ba79ee6663a7
- https://git.kernel.org/stable/c/6c49eac796681e250e34156bafb643930310bd4a
- https://git.kernel.org/stable/c/7574892e259bbb16262ebfb4b65a2054a5e03a49
- https://git.kernel.org/stable/c/800a2cfb2df7f96b3fb48910fc595e0215f6b019
- https://git.kernel.org/stable/c/ca46946a482238b0cdea459fb82fc837fb36260e
- https://git.kernel.org/stable/c/ca9bef9ba1a6be640c87bf802d2e9e696021576a
- https://git.kernel.org/stable/c/d7e59c5fd7a0f5e16e75a30a89ea2c4ab88612b8
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-22
CVE-2025-38670
In the Linux kernel, the following vulnerability has been resolved: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks. In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SP_EL0), clobbering it. In `call_on_irq_stack()`, it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls `call_on_irq_stack()` and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use ! This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK or FPAC if enabled. This is possible on a default config, but unlikely. However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very* frequently depending on the system configuration and workload, leading to unpredictable kernel panics. Completely mask DAIF in `cpu_switch_to()` and restore it when returning. Do the same in `call_on_irq_stack()`, but restore and mask around the branch. Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency of behaviour between all configurations. Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF.
- https://git.kernel.org/stable/c/0f67015d72627bad72da3c2084352e0aa134416b
- https://git.kernel.org/stable/c/407047893a64399f2d2390ff35cc6061107d805d
- https://git.kernel.org/stable/c/708fd522b86d2a9544c34ec6a86fa3fc23336525
- https://git.kernel.org/stable/c/9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61
- https://git.kernel.org/stable/c/a6b0cb523eaa01efe8a3f76ced493ba60674c6e6
- https://git.kernel.org/stable/c/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb
- https://git.kernel.org/stable/c/f7e0231eeaa33245c649fac0303cf97209605446
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-08
CVE-2025-38671
In the Linux kernel, the following vulnerability has been resolved: i2c: qup: jump out of the loop in case of timeout Original logic only sets the return value but doesn't jump out of the loop if the bus is kept active by a client. This is not expected. A malicious or buggy i2c client can hang the kernel in this case and should be avoided. This is observed during a long time test with a PCA953x GPIO extender. Fix it by changing the logic to not only sets the return value, but also jumps out of the loop and return to the caller with -ETIMEDOUT.
- https://git.kernel.org/stable/c/0d33913fce67a93c1eb83396c3c9d6b411dcab33
- https://git.kernel.org/stable/c/42c4471b30fa203249f476dd42321cd7efb7f6a8
- https://git.kernel.org/stable/c/89459f168b78e5c801dc8b7ad037b62898bc4f57
- https://git.kernel.org/stable/c/a7982a14b3012527a9583d12525cd0dc9f8d8934
- https://git.kernel.org/stable/c/acfa2948be630ad857535cb36153697f3cbf9ca9
- https://git.kernel.org/stable/c/c523bfba46c4b4d7676fb050909533a766698ecd
- https://git.kernel.org/stable/c/cbec4406998185e0311ae97dfacc649f9cd79b0b
- https://git.kernel.org/stable/c/d05ec13aa3eb868a60dc961b489053a643863ddc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-11-25
CVE-2025-38675
In the Linux kernel, the following vulnerability has been resolved: xfrm: state: initialize state_ptrs earlier in xfrm_state_find In case of preemption, xfrm_state_look_at will find a different pcpu_id and look up states for that other CPU. If we matched a state for CPU2 in the state_cache while the lookup started on CPU1, we will jump to "found", but the "best" state that we got will be ignored and we will enter the "acquire" block. This block uses state_ptrs, which isn't initialized at this point. Let's initialize state_ptrs just after taking rcu_read_lock. This will also prevent a possible misuse in the future, if someone adjusts this function.
Modified: 2025-11-25
CVE-2025-39725
In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache. Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again. This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows: cpu0 cpu1 shrink_folio_list memory_failure TestSetPageHWPoison unmap_poisoned_folio --> trigger BUG_ON due to unmap_poisoned_folio couldn't handle large folio [tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]
Modified: 2025-11-25
CVE-2025-39726
In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.
Modified: 2026-01-14
CVE-2025-39890
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix memory leak in ath12k_service_ready_ext_event Currently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_caps is not freed in the failure case, causing a memory leak. The following trace is observed in kmemleak: unreferenced object 0xffff8b3eb5789c00 (size 1024): comm "softirq", pid 0, jiffies 4294942577 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{... 01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8.. backtrace (crc 44e1c357): __kmalloc_noprof+0x30b/0x410 ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k] ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k] ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k] ath12k_ce_recv_process_cb+0x218/0x300 [ath12k] ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k] process_one_work+0x219/0x680 bh_worker+0x198/0x1f0 tasklet_action+0x13/0x30 handle_softirqs+0xca/0x460 __irq_exit_rcu+0xbe/0x110 irq_exit_rcu+0x9/0x30 Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1