kernel-devel-longterm-6.18.16-1.1 on GA media SUSE Patch security@suse.de SUSE Security Team openSUSE-SU-2026:10301-1 Final 1 1 2026-03-07T00:00:00Z current 2026-03-07T00:00:00Z 2026-03-07T00:00:00Z cve-database/bin/generate-cvrf.pl 2017-02-24T01:00:00Z kernel-devel-longterm-6.18.16-1.1 on GA media These are all security issues fixed in the kernel-devel-longterm-6.18.16-1.1 package on the GA media of openSUSE Tumbleweed. The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0). openSUSE-Tumbleweed-2026-10301 Copyright SUSE LLC under the Creative Commons License 4.0 with Attribution (CC-BY-4.0) https://www.suse.com/support/security/rating/ SUSE Security Ratings https://www.suse.com/security/cve/CVE-2024-28956/ SUSE CVE CVE-2024-28956 page https://www.suse.com/security/cve/CVE-2025-39991/ SUSE CVE CVE-2025-39991 page https://www.suse.com/security/cve/CVE-2025-39992/ SUSE CVE CVE-2025-39992 page https://www.suse.com/security/cve/CVE-2025-39993/ SUSE CVE CVE-2025-39993 page https://www.suse.com/security/cve/CVE-2025-39994/ SUSE CVE CVE-2025-39994 page https://www.suse.com/security/cve/CVE-2025-39995/ SUSE CVE CVE-2025-39995 page https://www.suse.com/security/cve/CVE-2025-39996/ SUSE CVE CVE-2025-39996 page https://www.suse.com/security/cve/CVE-2025-39997/ SUSE CVE CVE-2025-39997 page https://www.suse.com/security/cve/CVE-2025-39998/ SUSE CVE CVE-2025-39998 page https://www.suse.com/security/cve/CVE-2025-39999/ SUSE CVE CVE-2025-39999 page https://www.suse.com/security/cve/CVE-2025-40000/ SUSE CVE CVE-2025-40000 page https://www.suse.com/security/cve/CVE-2025-40001/ SUSE CVE CVE-2025-40001 page https://www.suse.com/security/cve/CVE-2025-40002/ SUSE CVE CVE-2025-40002 page https://www.suse.com/security/cve/CVE-2025-40003/ SUSE CVE CVE-2025-40003 page https://www.suse.com/security/cve/CVE-2025-40004/ SUSE CVE CVE-2025-40004 page https://www.suse.com/security/cve/CVE-2025-40013/ SUSE CVE CVE-2025-40013 page https://www.suse.com/security/cve/CVE-2025-40015/ SUSE CVE CVE-2025-40015 page https://www.suse.com/security/cve/CVE-2025-40016/ SUSE CVE CVE-2025-40016 page https://www.suse.com/security/cve/CVE-2025-40017/ SUSE CVE CVE-2025-40017 page https://www.suse.com/security/cve/CVE-2025-40018/ SUSE CVE CVE-2025-40018 page https://www.suse.com/security/cve/CVE-2025-40019/ SUSE CVE CVE-2025-40019 page https://www.suse.com/security/cve/CVE-2025-40025/ SUSE CVE CVE-2025-40025 page https://www.suse.com/security/cve/CVE-2025-40026/ SUSE CVE CVE-2025-40026 page https://www.suse.com/security/cve/CVE-2025-40027/ SUSE CVE CVE-2025-40027 page https://www.suse.com/security/cve/CVE-2025-40028/ SUSE CVE CVE-2025-40028 page https://www.suse.com/security/cve/CVE-2025-40029/ SUSE CVE CVE-2025-40029 page https://www.suse.com/security/cve/CVE-2025-40030/ SUSE CVE CVE-2025-40030 page https://www.suse.com/security/cve/CVE-2025-40031/ SUSE CVE CVE-2025-40031 page https://www.suse.com/security/cve/CVE-2025-40032/ SUSE CVE CVE-2025-40032 page https://www.suse.com/security/cve/CVE-2025-40033/ SUSE CVE CVE-2025-40033 page https://www.suse.com/security/cve/CVE-2025-40034/ SUSE CVE CVE-2025-40034 page https://www.suse.com/security/cve/CVE-2025-40035/ SUSE CVE CVE-2025-40035 page https://www.suse.com/security/cve/CVE-2025-40036/ SUSE CVE CVE-2025-40036 page https://www.suse.com/security/cve/CVE-2025-40037/ SUSE CVE CVE-2025-40037 page https://www.suse.com/security/cve/CVE-2025-40038/ SUSE CVE CVE-2025-40038 page https://www.suse.com/security/cve/CVE-2025-40039/ SUSE CVE CVE-2025-40039 page https://www.suse.com/security/cve/CVE-2025-40040/ SUSE CVE CVE-2025-40040 page https://www.suse.com/security/cve/CVE-2025-40041/ SUSE CVE CVE-2025-40041 page https://www.suse.com/security/cve/CVE-2025-40042/ SUSE CVE CVE-2025-40042 page https://www.suse.com/security/cve/CVE-2025-40043/ SUSE CVE CVE-2025-40043 page https://www.suse.com/security/cve/CVE-2025-40044/ SUSE CVE CVE-2025-40044 page https://www.suse.com/security/cve/CVE-2025-40045/ SUSE CVE CVE-2025-40045 page https://www.suse.com/security/cve/CVE-2025-40046/ SUSE CVE CVE-2025-40046 page https://www.suse.com/security/cve/CVE-2025-40047/ SUSE CVE CVE-2025-40047 page https://www.suse.com/security/cve/CVE-2025-40048/ SUSE CVE CVE-2025-40048 page https://www.suse.com/security/cve/CVE-2025-40049/ SUSE CVE CVE-2025-40049 page https://www.suse.com/security/cve/CVE-2025-40050/ SUSE CVE CVE-2025-40050 page https://www.suse.com/security/cve/CVE-2025-40051/ SUSE CVE CVE-2025-40051 page https://www.suse.com/security/cve/CVE-2025-40052/ SUSE CVE CVE-2025-40052 page https://www.suse.com/security/cve/CVE-2025-40053/ SUSE CVE CVE-2025-40053 page https://www.suse.com/security/cve/CVE-2025-40054/ SUSE CVE CVE-2025-40054 page https://www.suse.com/security/cve/CVE-2025-40055/ SUSE CVE CVE-2025-40055 page https://www.suse.com/security/cve/CVE-2025-40056/ SUSE CVE CVE-2025-40056 page https://www.suse.com/security/cve/CVE-2025-40057/ SUSE CVE CVE-2025-40057 page https://www.suse.com/security/cve/CVE-2025-40058/ SUSE CVE CVE-2025-40058 page https://www.suse.com/security/cve/CVE-2025-40059/ SUSE CVE CVE-2025-40059 page https://www.suse.com/security/cve/CVE-2025-40060/ SUSE CVE CVE-2025-40060 page https://www.suse.com/security/cve/CVE-2025-40061/ SUSE CVE CVE-2025-40061 page https://www.suse.com/security/cve/CVE-2025-40062/ SUSE CVE CVE-2025-40062 page https://www.suse.com/security/cve/CVE-2025-40063/ SUSE CVE CVE-2025-40063 page https://www.suse.com/security/cve/CVE-2025-40064/ SUSE CVE CVE-2025-40064 page https://www.suse.com/security/cve/CVE-2025-40065/ SUSE CVE CVE-2025-40065 page https://www.suse.com/security/cve/CVE-2025-40066/ SUSE CVE CVE-2025-40066 page https://www.suse.com/security/cve/CVE-2025-40067/ SUSE CVE CVE-2025-40067 page https://www.suse.com/security/cve/CVE-2025-40068/ SUSE CVE CVE-2025-40068 page https://www.suse.com/security/cve/CVE-2025-40069/ SUSE CVE CVE-2025-40069 page https://www.suse.com/security/cve/CVE-2025-40070/ SUSE CVE CVE-2025-40070 page https://www.suse.com/security/cve/CVE-2025-40071/ SUSE CVE CVE-2025-40071 page https://www.suse.com/security/cve/CVE-2025-40072/ SUSE CVE CVE-2025-40072 page https://www.suse.com/security/cve/CVE-2025-40073/ SUSE CVE CVE-2025-40073 page https://www.suse.com/security/cve/CVE-2025-40074/ SUSE CVE CVE-2025-40074 page https://www.suse.com/security/cve/CVE-2025-40075/ SUSE CVE CVE-2025-40075 page https://www.suse.com/security/cve/CVE-2025-40076/ SUSE CVE CVE-2025-40076 page https://www.suse.com/security/cve/CVE-2025-40077/ SUSE CVE CVE-2025-40077 page https://www.suse.com/security/cve/CVE-2025-40078/ SUSE CVE CVE-2025-40078 page https://www.suse.com/security/cve/CVE-2025-40079/ SUSE CVE CVE-2025-40079 page https://www.suse.com/security/cve/CVE-2025-40080/ SUSE CVE CVE-2025-40080 page https://www.suse.com/security/cve/CVE-2025-40081/ SUSE CVE CVE-2025-40081 page https://www.suse.com/security/cve/CVE-2025-40082/ SUSE CVE CVE-2025-40082 page https://www.suse.com/security/cve/CVE-2025-40084/ SUSE CVE CVE-2025-40084 page https://www.suse.com/security/cve/CVE-2025-40085/ SUSE CVE CVE-2025-40085 page https://www.suse.com/security/cve/CVE-2025-40086/ SUSE CVE CVE-2025-40086 page https://www.suse.com/security/cve/CVE-2025-40087/ SUSE CVE CVE-2025-40087 page https://www.suse.com/security/cve/CVE-2025-40088/ SUSE CVE CVE-2025-40088 page https://www.suse.com/security/cve/CVE-2025-40089/ SUSE CVE CVE-2025-40089 page https://www.suse.com/security/cve/CVE-2025-40090/ SUSE CVE CVE-2025-40090 page https://www.suse.com/security/cve/CVE-2025-40091/ SUSE CVE CVE-2025-40091 page https://www.suse.com/security/cve/CVE-2025-40092/ SUSE CVE CVE-2025-40092 page https://www.suse.com/security/cve/CVE-2025-40093/ SUSE CVE CVE-2025-40093 page https://www.suse.com/security/cve/CVE-2025-40094/ SUSE CVE CVE-2025-40094 page https://www.suse.com/security/cve/CVE-2025-40095/ SUSE CVE CVE-2025-40095 page https://www.suse.com/security/cve/CVE-2025-40096/ SUSE CVE CVE-2025-40096 page https://www.suse.com/security/cve/CVE-2025-40097/ SUSE CVE CVE-2025-40097 page https://www.suse.com/security/cve/CVE-2025-40098/ SUSE CVE CVE-2025-40098 page https://www.suse.com/security/cve/CVE-2025-40099/ SUSE CVE CVE-2025-40099 page https://www.suse.com/security/cve/CVE-2025-40100/ SUSE CVE CVE-2025-40100 page https://www.suse.com/security/cve/CVE-2025-40101/ SUSE CVE CVE-2025-40101 page https://www.suse.com/security/cve/CVE-2025-40102/ SUSE CVE CVE-2025-40102 page https://www.suse.com/security/cve/CVE-2025-40103/ SUSE CVE CVE-2025-40103 page https://www.suse.com/security/cve/CVE-2025-40104/ SUSE CVE CVE-2025-40104 page https://www.suse.com/security/cve/CVE-2025-40105/ SUSE CVE CVE-2025-40105 page https://www.suse.com/security/cve/CVE-2025-40106/ SUSE CVE CVE-2025-40106 page https://www.suse.com/security/cve/CVE-2025-40300/ SUSE CVE CVE-2025-40300 page https://www.suse.com/security/cve/CVE-2025-68254/ SUSE CVE CVE-2025-68254 page https://www.suse.com/security/cve/CVE-2025-68255/ SUSE CVE CVE-2025-68255 page https://www.suse.com/security/cve/CVE-2025-68256/ SUSE CVE CVE-2025-68256 page https://www.suse.com/security/cve/CVE-2025-68257/ SUSE CVE CVE-2025-68257 page https://www.suse.com/security/cve/CVE-2025-68258/ SUSE CVE CVE-2025-68258 page https://www.suse.com/security/cve/CVE-2025-68259/ SUSE CVE CVE-2025-68259 page https://www.suse.com/security/cve/CVE-2025-68260/ SUSE CVE CVE-2025-68260 page https://www.suse.com/security/cve/CVE-2025-68261/ SUSE CVE CVE-2025-68261 page https://www.suse.com/security/cve/CVE-2025-68262/ SUSE CVE CVE-2025-68262 page https://www.suse.com/security/cve/CVE-2025-68263/ SUSE CVE CVE-2025-68263 page https://www.suse.com/security/cve/CVE-2025-68264/ SUSE CVE CVE-2025-68264 page https://www.suse.com/security/cve/CVE-2025-68323/ SUSE CVE CVE-2025-68323 page https://www.suse.com/security/cve/CVE-2025-68324/ SUSE CVE CVE-2025-68324 page https://www.suse.com/security/cve/CVE-2025-68325/ SUSE CVE CVE-2025-68325 page https://www.suse.com/security/cve/CVE-2025-68332/ SUSE CVE CVE-2025-68332 page https://www.suse.com/security/cve/CVE-2025-68335/ SUSE CVE CVE-2025-68335 page https://www.suse.com/security/cve/CVE-2025-68336/ SUSE CVE CVE-2025-68336 page https://www.suse.com/security/cve/CVE-2025-68337/ SUSE CVE CVE-2025-68337 page https://www.suse.com/security/cve/CVE-2025-68344/ SUSE CVE CVE-2025-68344 page https://www.suse.com/security/cve/CVE-2025-68345/ SUSE CVE CVE-2025-68345 page https://www.suse.com/security/cve/CVE-2025-68346/ SUSE CVE CVE-2025-68346 page https://www.suse.com/security/cve/CVE-2025-68347/ SUSE CVE CVE-2025-68347 page https://www.suse.com/security/cve/CVE-2025-68348/ SUSE CVE CVE-2025-68348 page https://www.suse.com/security/cve/CVE-2025-68349/ SUSE CVE CVE-2025-68349 page https://www.suse.com/security/cve/CVE-2025-68350/ SUSE CVE CVE-2025-68350 page https://www.suse.com/security/cve/CVE-2025-68351/ SUSE CVE CVE-2025-68351 page https://www.suse.com/security/cve/CVE-2025-68352/ SUSE CVE CVE-2025-68352 page https://www.suse.com/security/cve/CVE-2025-68353/ SUSE CVE CVE-2025-68353 page https://www.suse.com/security/cve/CVE-2025-68354/ SUSE CVE CVE-2025-68354 page https://www.suse.com/security/cve/CVE-2025-68355/ SUSE CVE CVE-2025-68355 page https://www.suse.com/security/cve/CVE-2025-68356/ SUSE CVE CVE-2025-68356 page https://www.suse.com/security/cve/CVE-2025-68357/ SUSE CVE CVE-2025-68357 page https://www.suse.com/security/cve/CVE-2025-68358/ SUSE CVE CVE-2025-68358 page https://www.suse.com/security/cve/CVE-2025-68359/ SUSE CVE CVE-2025-68359 page https://www.suse.com/security/cve/CVE-2025-68360/ SUSE CVE CVE-2025-68360 page https://www.suse.com/security/cve/CVE-2025-68361/ SUSE CVE CVE-2025-68361 page https://www.suse.com/security/cve/CVE-2025-68362/ SUSE CVE CVE-2025-68362 page https://www.suse.com/security/cve/CVE-2025-68363/ SUSE CVE CVE-2025-68363 page https://www.suse.com/security/cve/CVE-2025-68364/ SUSE CVE CVE-2025-68364 page https://www.suse.com/security/cve/CVE-2025-68365/ SUSE CVE CVE-2025-68365 page https://www.suse.com/security/cve/CVE-2025-68366/ SUSE CVE CVE-2025-68366 page https://www.suse.com/security/cve/CVE-2025-68367/ SUSE CVE CVE-2025-68367 page https://www.suse.com/security/cve/CVE-2025-68368/ SUSE CVE CVE-2025-68368 page https://www.suse.com/security/cve/CVE-2025-68369/ SUSE CVE CVE-2025-68369 page https://www.suse.com/security/cve/CVE-2025-68370/ SUSE CVE CVE-2025-68370 page https://www.suse.com/security/cve/CVE-2025-68371/ SUSE CVE CVE-2025-68371 page https://www.suse.com/security/cve/CVE-2025-68372/ SUSE CVE CVE-2025-68372 page https://www.suse.com/security/cve/CVE-2025-68373/ SUSE CVE CVE-2025-68373 page https://www.suse.com/security/cve/CVE-2025-68374/ SUSE CVE CVE-2025-68374 page https://www.suse.com/security/cve/CVE-2025-68375/ SUSE CVE CVE-2025-68375 page https://www.suse.com/security/cve/CVE-2025-68376/ SUSE CVE CVE-2025-68376 page https://www.suse.com/security/cve/CVE-2025-68377/ SUSE CVE CVE-2025-68377 page https://www.suse.com/security/cve/CVE-2025-68378/ SUSE CVE CVE-2025-68378 page https://www.suse.com/security/cve/CVE-2025-68379/ SUSE CVE CVE-2025-68379 page https://www.suse.com/security/cve/CVE-2025-68380/ SUSE CVE CVE-2025-68380 page https://www.suse.com/security/cve/CVE-2025-68724/ SUSE CVE CVE-2025-68724 page https://www.suse.com/security/cve/CVE-2025-68725/ SUSE CVE CVE-2025-68725 page https://www.suse.com/security/cve/CVE-2025-68726/ SUSE CVE CVE-2025-68726 page https://www.suse.com/security/cve/CVE-2025-68727/ SUSE CVE CVE-2025-68727 page https://www.suse.com/security/cve/CVE-2025-68728/ SUSE CVE CVE-2025-68728 page https://www.suse.com/security/cve/CVE-2025-68729/ SUSE CVE CVE-2025-68729 page https://www.suse.com/security/cve/CVE-2025-68730/ SUSE CVE CVE-2025-68730 page https://www.suse.com/security/cve/CVE-2025-68731/ SUSE CVE CVE-2025-68731 page https://www.suse.com/security/cve/CVE-2025-68732/ SUSE CVE CVE-2025-68732 page https://www.suse.com/security/cve/CVE-2025-68733/ SUSE CVE CVE-2025-68733 page https://www.suse.com/security/cve/CVE-2025-68735/ SUSE CVE CVE-2025-68735 page https://www.suse.com/security/cve/CVE-2025-68736/ SUSE CVE CVE-2025-68736 page https://www.suse.com/security/cve/CVE-2025-68737/ SUSE CVE CVE-2025-68737 page https://www.suse.com/security/cve/CVE-2025-68738/ SUSE CVE CVE-2025-68738 page https://www.suse.com/security/cve/CVE-2025-68739/ SUSE CVE CVE-2025-68739 page https://www.suse.com/security/cve/CVE-2025-68740/ SUSE CVE CVE-2025-68740 page https://www.suse.com/security/cve/CVE-2025-68741/ SUSE CVE CVE-2025-68741 page https://www.suse.com/security/cve/CVE-2025-68742/ SUSE CVE CVE-2025-68742 page https://www.suse.com/security/cve/CVE-2025-68743/ SUSE CVE CVE-2025-68743 page https://www.suse.com/security/cve/CVE-2025-68744/ SUSE CVE CVE-2025-68744 page https://www.suse.com/security/cve/CVE-2025-68745/ SUSE CVE CVE-2025-68745 page https://www.suse.com/security/cve/CVE-2025-68746/ SUSE CVE CVE-2025-68746 page https://www.suse.com/security/cve/CVE-2025-68747/ SUSE CVE CVE-2025-68747 page https://www.suse.com/security/cve/CVE-2025-68748/ SUSE CVE CVE-2025-68748 page https://www.suse.com/security/cve/CVE-2025-68749/ SUSE CVE CVE-2025-68749 page https://www.suse.com/security/cve/CVE-2025-68751/ SUSE CVE CVE-2025-68751 page https://www.suse.com/security/cve/CVE-2025-68752/ SUSE CVE CVE-2025-68752 page https://www.suse.com/security/cve/CVE-2025-68753/ SUSE CVE CVE-2025-68753 page https://www.suse.com/security/cve/CVE-2025-68754/ SUSE CVE CVE-2025-68754 page https://www.suse.com/security/cve/CVE-2025-68755/ SUSE CVE CVE-2025-68755 page https://www.suse.com/security/cve/CVE-2025-68756/ SUSE CVE CVE-2025-68756 page https://www.suse.com/security/cve/CVE-2025-68757/ SUSE CVE CVE-2025-68757 page https://www.suse.com/security/cve/CVE-2025-68758/ SUSE CVE CVE-2025-68758 page https://www.suse.com/security/cve/CVE-2025-68759/ SUSE CVE CVE-2025-68759 page https://www.suse.com/security/cve/CVE-2025-68760/ SUSE CVE CVE-2025-68760 page https://www.suse.com/security/cve/CVE-2025-68761/ SUSE CVE CVE-2025-68761 page https://www.suse.com/security/cve/CVE-2025-68762/ SUSE CVE CVE-2025-68762 page https://www.suse.com/security/cve/CVE-2025-68763/ SUSE CVE CVE-2025-68763 page https://www.suse.com/security/cve/CVE-2025-68764/ SUSE CVE CVE-2025-68764 page https://www.suse.com/security/cve/CVE-2025-68765/ SUSE CVE CVE-2025-68765 page https://www.suse.com/security/cve/CVE-2025-68766/ SUSE CVE CVE-2025-68766 page openSUSE Tumbleweed kernel-devel-longterm-6.18.16-1.1 kernel-source-longterm-6.18.16-1.1 kernel-devel-longterm-6.18.16-1.1 as a component of openSUSE Tumbleweed kernel-source-longterm-6.18.16-1.1 as a component of openSUSE Tumbleweed Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. CVE-2024-28956 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2024-28956.html CVE-2024-28956 https://bugzilla.suse.com/1242006 SUSE Bug 1242006 In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-39991 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39991.html CVE-2025-39991 https://bugzilla.suse.com/1252075 SUSE Bug 1252075 In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue. CVE-2025-39992 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39992.html CVE-2025-39992 https://bugzilla.suse.com/1252076 SUSE Bug 1252076 In the Linux kernel, the following vulnerability has been resolved: media: rc: fix races with imon_disconnect() Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465 CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer. Thread 1 vfd_write Thread 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0) else usb_put_dev(ictx->usbdev_intf1) ... while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAF else pipe = usb_sndctrlpipe( ictx->usbdev_intf0, 0) UAF Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present. Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations. Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-39993 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39993.html CVE-2025-39993 https://bugzilla.suse.com/1252070 SUSE Bug 1252070 In the Linux kernel, the following vulnerability has been resolved: media: tuner: xc5000: Fix use-after-free in xc5000_release The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was initially identified through static analysis. [hverkuil: fix typo in Subject: tunner -> tuner] CVE-2025-39994 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39994.html CVE-2025-39994 https://bugzilla.suse.com/1252072 SUSE Bug 1252072 In the Linux kernel, the following vulnerability has been resolved: media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe The state->timer is a cyclic timer that schedules work_i2c_poll and delayed_work_enable_hotplug, while rearming itself. Using timer_delete() fails to guarantee the timer isn't still running when destroyed, similarly cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has terminated if already executing. During probe failure after timer initialization, these may continue running as orphans and reference the already-freed tc358743_state object through tc358743_irq_poll_timer. The following is the trace captured by KASAN. BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ> ... Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace timer_delete() with timer_delete_sync() and cancel_delayed_work() with cancel_delayed_work_sync() to ensure proper termination of timer and work items before resource cleanup. This bug was initially identified through static analysis. For reproduction and testing, I created a functional emulation of the tc358743 device via a kernel module and introduced faults through the debugfs interface. CVE-2025-39995 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39995.html CVE-2025-39995 https://bugzilla.suse.com/1252064 SUSE Bug 1252064 In the Linux kernel, the following vulnerability has been resolved: media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAF This is confirmed by a KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ> ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug. CVE-2025-39996 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39996.html CVE-2025-39996 https://bugzilla.suse.com/1252065 SUSE Bug 1252065 In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at removal") patched a UAF issue caused by the error timer. However, because the error timer kill added in this patch occurs after the endpoint delete, a race condition to UAF still occurs, albeit rarely. Additionally, since kill-cleanup for urb is also missing, freed memory can be accessed in interrupt context related to urb, which can cause UAF. Therefore, to prevent this, error timer and urb must be killed before freeing the heap memory. CVE-2025-39997 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39997.html CVE-2025-39997 https://bugzilla.suse.com/1252056 SUSE Bug 1252056 In the Linux kernel, the following vulnerability has been resolved: scsi: target: target_core_configfs: Add length check to avoid buffer overflow A buffer overflow arises from the usage of snprintf to write into the buffer "buf" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow. CVE-2025-39998 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39998.html CVE-2025-39998 https://bugzilla.suse.com/1252073 SUSE Bug 1252073 In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix blk_mq_tags double free while nr_requests grown In the case user trigger tags grow by queue sysfs attribute nr_requests, hctx->sched_tags will be freed directly and replaced with a new allocated tags, see blk_mq_tag_update_depth(). The problem is that hctx->sched_tags is from elevator->et->tags, while et->tags is still the freed tags, hence later elevator exit will try to free the tags again, causing kernel panic. Fix this problem by replacing et->tags with new allocated tags as well. Noted there are still some long term problems that will require some refactor to be fixed thoroughly[1]. [1] https://lore.kernel.org/all/20250815080216.410665-1-yukuai1@huaweicloud.com/ CVE-2025-39999 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-39999.html CVE-2025-39999 https://bugzilla.suse.com/1252059 SUSE Bug 1252059 In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait() There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to access already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 It is a consequence of a race between the waiting and the signaling side of the completion: Waiting thread Completing thread rtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and ---truncated--- CVE-2025-40000 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40000.html CVE-2025-40000 https://bugzilla.suse.com/1252062 SUSE Bug 1252062 In the Linux kernel, the following vulnerability has been resolved: scsi: mvsas: Fix use-after-free bugs in mvs_work_queue During the detaching of Marvell's SAS/SATA controller, the original code calls cancel_delayed_work() in mvs_free() to cancel the delayed work item mwq->work_q. However, if mwq->work_q is already running, the cancel_delayed_work() may fail to cancel it. This can lead to use-after-free scenarios where mvs_free() frees the mvs_info while mvs_work_queue() is still executing and attempts to access the already-freed mvs_info. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work item completes before the mvs_info is deallocated. This bug was found by static analysis. CVE-2025-40001 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40001.html CVE-2025-40001 https://bugzilla.suse.com/1252303 SUSE Bug 1252303 In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix use-after-free in tb_dp_dprx_work The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(), which does not ensure that the delayed work item tunnel->dprx_work has fully completed if it was already running. This leads to use-after-free scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while tunnel->dprx_work remains active and attempts to dereference tb_tunnel in tb_dp_dprx_work(). A typical race condition is illustrated below: CPU 0 | CPU 1 tb_dp_tunnel_active() | tb_deactivate_and_free_tunnel()| tb_dp_dprx_start() tb_tunnel_deactivate() | queue_delayed_work() tb_dp_activate() | tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker cancel_delayed_work() | tb_tunnel_put(tunnel); | | tunnel = container_of(...); //UAF | tunnel-> //UAF Replacing cancel_delayed_work() with cancel_delayed_work_sync() is not feasible as it would introduce a deadlock: both tb_dp_dprx_work() and the cleanup path acquire tb->lock, and cancel_delayed_work_sync() would wait indefinitely for the work item that cannot proceed. Instead, implement proper reference counting: - If cancel_delayed_work() returns true (work is pending), we release the reference in the stop function. - If it returns false (work is executing or already completed), the reference is released in delayed work function itself. This ensures the tb_tunnel remains valid during work item execution while preventing memory leaks. This bug was found by static analysis. CVE-2025-40002 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40002.html CVE-2025-40002 https://bugzilla.suse.com/1252302 SUSE Bug 1252302 In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: Fix use-after-free caused by cyclic delayed work The origin code calls cancel_delayed_work() in ocelot_stats_deinit() to cancel the cyclic delayed work item ocelot->stats_work. However, cancel_delayed_work() may fail to cancel the work item if it is already executing. While destroy_workqueue() does wait for all pending work items in the work queue to complete before destroying the work queue, it cannot prevent the delayed work item from being rescheduled within the ocelot_check_stats_work() function. This limitation exists because the delayed work item is only enqueued into the work queue after its timer expires. Before the timer expiration, destroy_workqueue() has no visibility of this pending work item. Once the work queue appears empty, destroy_workqueue() proceeds with destruction. When the timer eventually expires, the delayed work item gets queued again, leading to the following warning: workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-stats WARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0 ... RIP: 0010:__queue_work+0x875/0xaf0 ... RSP: 0018:ffff88806d108b10 EFLAGS: 00010086 RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027 RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88 RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2 R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000 R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0 FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0 Call Trace: <IRQ> ? kasan_report+0xc6/0xf0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? __pfx_delayed_work_timer_fn+0x10/0x10 call_timer_fn+0x25/0x1c0 __run_timer_base.part.0+0x3be/0x8c0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x1c0/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ> ... The following diagram reveals the cause of the above warning: CPU 0 (remove) | CPU 1 (delayed work callback) mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (wait a time) | __queue_work() //UAF The above scenario actually constitutes a UAF vulnerability. The ocelot_stats_deinit() is only invoked when initialization failure or resource destruction, so we must ensure that any delayed work items cannot be rescheduled. Replace cancel_delayed_work() with disable_delayed_work_sync() to guarantee proper cancellation of the delayed work item and ensure completion of any currently executing work before the workqueue is deallocated. A deadlock concern was considered: ocelot_stats_deinit() is called in a process context and is not holding any locks that the delayed work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated ocelot-swit ---truncated--- CVE-2025-40003 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40003.html CVE-2025-40003 https://bugzilla.suse.com/1252301 SUSE Bug 1252301 In the Linux kernel, the following vulnerability has been resolved: net/9p: Fix buffer overflow in USB transport layer A buffer overflow vulnerability exists in the USB 9pfs transport layer where inconsistent size validation between packet header parsing and actual data copying allows a malicious USB host to overflow heap buffers. The issue occurs because: - usb9pfs_rx_header() validates only the declared size in packet header - usb9pfs_rx_complete() uses req->actual (actual received bytes) for memcpy This allows an attacker to craft packets with small declared size (bypassing validation) but large actual payload (triggering overflow in memcpy). Add validation in usb9pfs_rx_complete() to ensure req->actual does not exceed the buffer capacity before copying data. CVE-2025-40004 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40004.html CVE-2025-40004 https://bugzilla.suse.com/1252310 SUSE Bug 1252310 In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: audioreach: fix potential null pointer dereference It is possible that the topology parsing function audioreach_widget_load_module_common() could return NULL or an error pointer. Add missing NULL check so that we do not dereference it. CVE-2025-40013 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40013.html CVE-2025-40013 https://bugzilla.suse.com/1252348 SUSE Bug 1252348 In the Linux kernel, the following vulnerability has been resolved: media: stm32-csi: Fix dereference before NULL check In 'stm32_csi_start', 'csidev->s_subdev' is dereferenced directly while assigning a value to the 'src_pad'. However the same value is being checked against NULL at a later point of time indicating that there are chances that the value can be NULL. Move the dereference after the NULL check. CVE-2025-40015 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40015.html CVE-2025-40015 https://bugzilla.suse.com/1252345 SUSE Bug 1252345 In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require entities to have a non-zero unique ID"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated--- CVE-2025-40016 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40016.html CVE-2025-40016 https://bugzilla.suse.com/1252346 SUSE Bug 1252346 In the Linux kernel, the following vulnerability has been resolved: media: iris: Fix memory leak by freeing untracked persist buffer One internal buffer which is allocated only once per session was not being freed during session close because it was not being tracked as part of internal buffer list which resulted in a memory leak. Add the necessary logic to explicitly free the untracked internal buffer during session close to ensure all allocated memory is released properly. CVE-2025-40017 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40017.html CVE-2025-40017 https://bugzilla.suse.com/1252335 SUSE Bug 1252335 In the Linux kernel, the following vulnerability has been resolved: ipvs: Defer ip_vs_ftp unregister during netns cleanup On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free. Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately. CVE-2025-40018 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40018.html CVE-2025-40018 https://bugzilla.suse.com/1247374 SUSE Bug 1247374 https://bugzilla.suse.com/1252688 SUSE Bug 1252688 https://bugzilla.suse.com/1252689 SUSE Bug 1252689 https://bugzilla.suse.com/1253291 SUSE Bug 1253291 In the Linux kernel, the following vulnerability has been resolved: crypto: essiv - Check ssize for decryption and in-place encryption Move the ssize check to the start in essiv_aead_crypt so that it's also checked for decryption and in-place encryption. CVE-2025-40019 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40019.html CVE-2025-40019 https://bugzilla.suse.com/1252678 SUSE Bug 1252678 https://bugzilla.suse.com/1252719 SUSE Bug 1252719 In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on node footer for non inode dnode As syzbot reported below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/file.c:1243! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5354 Comm: syz.0.0 Not tainted 6.17.0-rc1-syzkaller-00211-g90d970cade8e #0 PREEMPT(full) RIP: 0010:f2fs_truncate_hole+0x69e/0x6c0 fs/f2fs/file.c:1243 Call Trace: <TASK> f2fs_punch_hole+0x2db/0x330 fs/f2fs/file.c:1306 f2fs_fallocate+0x546/0x990 fs/f2fs/file.c:2018 vfs_fallocate+0x666/0x7e0 fs/open.c:342 ksys_fallocate fs/open.c:366 [inline] __do_sys_fallocate fs/open.c:371 [inline] __se_sys_fallocate fs/open.c:369 [inline] __x64_sys_fallocate+0xc0/0x110 fs/open.c:369 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1e65f8ebe9 w/ a fuzzed image, f2fs may encounter panic due to it detects inconsistent truncation range in direct node in f2fs_truncate_hole(). The root cause is: a non-inode dnode may has the same footer.ino and footer.nid, so the dnode will be parsed as an inode, then ADDRS_PER_PAGE() may return wrong blkaddr count which may be 923 typically, by chance, dn.ofs_in_node is equal to 923, then count can be calculated to 0 in below statement, later it will trigger panic w/ f2fs_bug_on(, count == 0 || ...). count = min(end_offset - dn.ofs_in_node, pg_end - pg_start); This patch introduces a new node_type NODE_TYPE_NON_INODE, then allowing passing the new_type to sanity_check_node_footer in f2fs_get_node_folio() to detect corruption that a non-inode dnode has the same footer.ino and footer.nid. Scripts to reproduce: mkfs.f2fs -f /dev/vdb mount /dev/vdb /mnt/f2fs touch /mnt/f2fs/foo touch /mnt/f2fs/bar dd if=/dev/zero of=/mnt/f2fs/foo bs=1M count=8 umount /mnt/f2fs inject.f2fs --node --mb i_nid --nid 4 --idx 0 --val 5 /dev/vdb mount /dev/vdb /mnt/f2fs xfs_io /mnt/f2fs/foo -c "fpunch 6984k 4k" CVE-2025-40025 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40025.html CVE-2025-40025 https://bugzilla.suse.com/1252766 SUSE Bug 1252766 In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended "recipient") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: <TASK> kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> CVE-2025-40026 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40026.html CVE-2025-40026 https://bugzilla.suse.com/1252764 SUSE Bug 1252764 In the Linux kernel, the following vulnerability has been resolved: net/9p: fix double req put in p9_fd_cancelled Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__list_del_entry include/linux/list.h:137 [inline] RIP: 0010:list_del include/linux/list.h:148 [inline] RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734 Call Trace: <TASK> p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ... Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem client where the req_list could be deleted simultaneously by both p9_read_work and p9_fd_cancelled functions, but for the case where req->status equals REQ_STATUS_RCVD. Update the check for req->status in p9_fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [updated the check from status == RECV || status == ERROR to status != SENT] CVE-2025-40027 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40027.html CVE-2025-40027 https://bugzilla.suse.com/1252763 SUSE Bug 1252763 In the Linux kernel, the following vulnerability has been resolved: binder: fix double-free in dbitmap A process might fail to allocate a new bitmap when trying to expand its proc->dmap. In that case, dbitmap_grow() fails and frees the old bitmap via dbitmap_free(). However, the driver calls dbitmap_free() again when the same process terminates, leading to a double-free error: ================================================================== BUG: KASAN: double-free in binder_proc_dec_tmpref+0x2e0/0x55c Free of addr ffff00000b7c1420 by task kworker/9:1/209 CPU: 9 UID: 0 PID: 209 Comm: kworker/9:1 Not tainted 6.17.0-rc6-dirty #5 PREEMPT Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: kfree+0x164/0x31c binder_proc_dec_tmpref+0x2e0/0x55c binder_deferred_func+0xc24/0x1120 process_one_work+0x520/0xba4 [...] Allocated by task 448: __kmalloc_noprof+0x178/0x3c0 bitmap_zalloc+0x24/0x30 binder_open+0x14c/0xc10 [...] Freed by task 449: kfree+0x184/0x31c binder_inc_ref_for_node+0xb44/0xe44 binder_transaction+0x29b4/0x7fbc binder_thread_write+0x1708/0x442c binder_ioctl+0x1b50/0x2900 [...] ================================================================== Fix this issue by marking proc->map NULL in dbitmap_free(). CVE-2025-40028 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40028.html CVE-2025-40028 https://bugzilla.suse.com/1252762 SUSE Bug 1252762 In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: Check return value of platform_get_resource() platform_get_resource() returns NULL in case of failure, so check its return value and propagate the error in order to prevent NULL pointer dereference. CVE-2025-40029 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40029.html CVE-2025-40029 https://bugzilla.suse.com/1252772 SUSE Bug 1252772 In the Linux kernel, the following vulnerability has been resolved: pinctrl: check the return value of pinmux_ops::get_function_name() While the API contract in docs doesn't specify it explicitly, the generic implementation of the get_function_name() callback from struct pinmux_ops - pinmux_generic_get_function_name() - can fail and return NULL. This is already checked in pinmux_check_ops() so add a similar check in pinmux_func_name_to_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions. CVE-2025-40030 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40030.html CVE-2025-40030 https://bugzilla.suse.com/1252773 SUSE Bug 1252773 In the Linux kernel, the following vulnerability has been resolved: tee: fix register_shm_helper() In register_shm_helper(), fix incorrect error handling for a call to iov_iter_extract_pages(). A case is missing for when iov_iter_extract_pages() only got some pages and return a number larger than 0, but not the requested amount. This fixes a possible NULL pointer dereference following a bad input from ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped. CVE-2025-40031 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40031.html CVE-2025-40031 https://bugzilla.suse.com/1252779 SUSE Bug 1252779 In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 [mani: trimmed the stack trace] CVE-2025-40032 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40032.html CVE-2025-40032 https://bugzilla.suse.com/1252841 SUSE Bug 1252841 In the Linux kernel, the following vulnerability has been resolved: remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable() pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULL check, which could lead to a null pointer dereference. Move the pru assignment, ensuring we never dereference a NULL rproc pointer. CVE-2025-40033 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40033.html CVE-2025-40033 https://bugzilla.suse.com/1252824 SUSE Bug 1252824 In the Linux kernel, the following vulnerability has been resolved: PCI/AER: Avoid NULL pointer dereference in aer_ratelimit() When platform firmware supplies error information to the OS, e.g., via the ACPI APEI GHES mechanism, it may identify an error source device that doesn't advertise an AER Capability and therefore dev->aer_info, which contains AER stats and ratelimiting data, is NULL. pci_dev_aer_stats_incr() already checks dev->aer_info for NULL, but aer_ratelimit() did not, leading to NULL pointer dereferences like this one from the URL below: {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0 {1}[Hardware Error]: event severity: corrected {1}[Hardware Error]: device_id: 0000:00:00.0 {1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x2020 {1}[Hardware Error]: aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000 BUG: kernel NULL pointer dereference, address: 0000000000000264 RIP: 0010:___ratelimit+0xc/0x1b0 pci_print_aer+0x141/0x360 aer_recover_work_func+0xb5/0x130 [8086:2020] is an Intel "Sky Lake-E DMI3 Registers" device that claims to be a Root Port but does not advertise an AER Capability. Add a NULL check in aer_ratelimit() to avoid the NULL pointer dereference. Note that this also prevents ratelimiting these events from GHES. [bhelgaas: add crash details to commit log] CVE-2025-40034 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40034.html CVE-2025-40034 https://bugzilla.suse.com/1252868 SUSE Bug 1252868 In the Linux kernel, the following vulnerability has been resolved: Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace. Initialize ff_up_compat to zero before filling valid fields. CVE-2025-40035 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40035.html CVE-2025-40035 https://bugzilla.suse.com/1252866 SUSE Bug 1252866 In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix possible map leak in fastrpc_put_args copy_to_user() failure would cause an early return without cleaning up the fdlist, which has been updated by the DSP. This could lead to map leak. Fix this by redirecting to a cleanup path on failure, ensuring that all mapped buffers are properly released before returning. CVE-2025-40036 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40036.html CVE-2025-40036 https://bugzilla.suse.com/1252865 SUSE Bug 1252865 In the Linux kernel, the following vulnerability has been resolved: fbdev: simplefb: Fix use after free in simplefb_detach_genpds() The pm_domain cleanup can not be devres managed as it uses struct simplefb_par which is allocated within struct fb_info by framebuffer_alloc(). This allocation is explicitly freed by unregister_framebuffer() in simplefb_remove(). Devres managed cleanup runs after the device remove call and thus can no longer access struct simplefb_par. Call simplefb_detach_genpds() explicitly from simplefb_destroy() like the cleanup functions for clocks and regulators. Fixes an use after free on M2 Mac mini during aperture_remove_conflicting_devices() using the downstream asahi kernel with Debian's kernel config. For unknown reasons this started to consistently dereference an invalid pointer in v6.16.3 based kernels. [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220 [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227 [ 6.750697] [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT) [ 6.752189] Call trace: [ 6.752190] show_stack+0x34/0x98 (C) [ 6.752194] dump_stack_lvl+0x60/0x80 [ 6.752197] print_report+0x17c/0x4d8 [ 6.752201] kasan_report+0xb4/0x100 [ 6.752206] __asan_report_load4_noabort+0x20/0x30 [ 6.752209] simplefb_detach_genpds+0x58/0x220 [ 6.752213] devm_action_release+0x50/0x98 [ 6.752216] release_nodes+0xd0/0x2c8 [ 6.752219] devres_release_all+0xfc/0x178 [ 6.752221] device_unbind_cleanup+0x28/0x168 [ 6.752224] device_release_driver_internal+0x34c/0x470 [ 6.752228] device_release_driver+0x20/0x38 [ 6.752231] bus_remove_device+0x1b0/0x380 [ 6.752234] device_del+0x314/0x820 [ 6.752238] platform_device_del+0x3c/0x1e8 [ 6.752242] platform_device_unregister+0x20/0x50 [ 6.752246] aperture_detach_platform_device+0x1c/0x30 [ 6.752250] aperture_detach_devices+0x16c/0x290 [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50 ... [ 6.752343] [ 6.967409] Allocated by task 62: [ 6.970724] kasan_save_stack+0x3c/0x70 [ 6.974560] kasan_save_track+0x20/0x40 [ 6.978397] kasan_save_alloc_info+0x40/0x58 [ 6.982670] __kasan_kmalloc+0xd4/0xd8 [ 6.986420] __kmalloc_noprof+0x194/0x540 [ 6.990432] framebuffer_alloc+0xc8/0x130 [ 6.994444] simplefb_probe+0x258/0x2378 ... [ 7.054356] [ 7.055838] Freed by task 227: [ 7.058891] kasan_save_stack+0x3c/0x70 [ 7.062727] kasan_save_track+0x20/0x40 [ 7.066565] kasan_save_free_info+0x4c/0x80 [ 7.070751] __kasan_slab_free+0x6c/0xa0 [ 7.074675] kfree+0x10c/0x380 [ 7.077727] framebuffer_release+0x5c/0x90 [ 7.081826] simplefb_destroy+0x1b4/0x2c0 [ 7.085837] put_fb_info+0x98/0x100 [ 7.089326] unregister_framebuffer+0x178/0x320 [ 7.093861] simplefb_remove+0x3c/0x60 [ 7.097611] platform_remove+0x60/0x98 [ 7.101361] device_remove+0xb8/0x160 [ 7.105024] device_release_driver_internal+0x2fc/0x470 [ 7.110256] device_release_driver+0x20/0x38 [ 7.114529] bus_remove_device+0x1b0/0x380 [ 7.118628] device_del+0x314/0x820 [ 7.122116] platform_device_del+0x3c/0x1e8 [ 7.126302] platform_device_unregister+0x20/0x50 [ 7.131012] aperture_detach_platform_device+0x1c/0x30 [ 7.136157] aperture_detach_devices+0x16c/0x290 [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50 ... CVE-2025-40037 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40037.html CVE-2025-40037 https://bugzilla.suse.com/1252819 SUSE Bug 1252819 In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [<ffffffffc08b2527>] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [<ffffffffb4f62e32>] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: <TASK> dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b </TASK> Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons). CVE-2025-40038 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40038.html CVE-2025-40038 https://bugzilla.suse.com/1252817 SUSE Bug 1252817 In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix race condition in RPC handle list access The 'sess->rpc_handle_list' XArray manages RPC handles within a ksmbd session. Access to this list is intended to be protected by 'sess->rpc_lock' (an rw_semaphore). However, the locking implementation was flawed, leading to potential race conditions. In ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock before calling xa_store() and xa_erase(). Since these operations modify the XArray structure, a write lock is required to ensure exclusive access and prevent data corruption from concurrent modifications. Furthermore, ksmbd_session_rpc_method() accessed the list using xa_load() without holding any lock at all. This could lead to reading inconsistent data or a potential use-after-free if an entry is concurrently removed and the pointer is dereferenced. Fix these issues by: 1. Using down_write() and up_write() in ksmbd_session_rpc_open() to ensure exclusive access during XArray modification, and ensuring the lock is correctly released on error paths. 2. Adding down_read() and up_read() in ksmbd_session_rpc_method() to safely protect the lookup. CVE-2025-40039 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40039.html CVE-2025-40039 https://bugzilla.suse.com/1252783 SUSE Bug 1252783 In the Linux kernel, the following vulnerability has been resolved: mm/ksm: fix flag-dropping behavior in ksm_madvise syzkaller discovered the following crash: (kernel BUG) [ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460 <snip other registers, drop unreliable trace> [ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227 Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags. The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags. Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment. VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value. Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the BIT() macro. Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s. Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place: [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067 but the root-cause (flag-drop) remains the same. [akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel] CVE-2025-40040 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40040.html CVE-2025-40040 https://bugzilla.suse.com/1252780 SUSE Bug 1252780 In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Sign-extend struct ops return values properly The ns_bpf_qdisc selftest triggers a kernel panic: Oops[#1]: CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4 CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G OE 6.16.0+ #3 PREEMPT(full) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600 a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008 a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000 t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001 t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800 s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880 s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000 ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8 ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000741d58 PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)] Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956) Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8 90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000 900000010597c400 900000008694a000 0000000000000000 9000000105b59000 90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c 9000000086936000 0000000100094d4c fffffff400676208 0000000000000000 9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000 9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000 9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840 0000000000000000 9000000086be6c40 0000000000000000 0000000000000000 0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4 ... Call Trace: [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8 [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0 [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950 [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448 [<9000000085370b24>] ip6_xmit+0x304/0x858 [<90000000853c4438>] inet6_csk_xmit+0x100/0x170 [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0 [<90000000852b47fc>] tcp_connect+0xbcc/0x1168 [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0 [<90000000852e7738>] __inet_stream_connect+0x170/0x480 [<90000000852e7a98>] inet_stream_connect+0x50/0x88 [<90000000850f2814>] __sys_connect+0xe4/0x110 [<90000000850f2858>] sys_connect+0x18/0x28 [<9000000085520c94>] do_syscall+0x94/0x1a0 [<9000000083df1fb8>] handle_syscall+0xb8/0x158 Code: 4001ad80 2400873f 2400832d <240073cc> 001137ff 001133ff 6407b41f 001503cc 0280041d ---[ end trace 0000000000000000 ]--- The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires LoongArch ABI. So let's sign extend struct ops return values according to the LoongArch ABI ([1]) and return value spec in function model. [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html CVE-2025-40041 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40041.html CVE-2025-40041 https://bugzilla.suse.com/1252860 SUSE Bug 1252860 In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race condition in kprobe initialization causing NULL pointer dereference There is a critical race condition in kprobe initialization that can lead to NULL pointer dereference and kernel crash. [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000 ... [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO) [1135630.269239] pc : kprobe_perf_func+0x30/0x260 [1135630.277643] lr : kprobe_dispatcher+0x44/0x60 [1135630.286041] sp : ffffaeff4977fa40 [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400 [1135630.302837] x27: 0000000000000000 x26: 0000000000000000 [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528 [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50 [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50 [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000 [1135630.349985] x17: 0000000000000000 x16: 0000000000000000 [1135630.359285] x15: 0000000000000000 x14: 0000000000000000 [1135630.368445] x13: 0000000000000000 x12: 0000000000000000 [1135630.377473] x11: 0000000000000000 x10: 0000000000000000 [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000 [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000 [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000 [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006 [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000 [1135630.429410] Call trace: [1135630.434828] kprobe_perf_func+0x30/0x260 [1135630.441661] kprobe_dispatcher+0x44/0x60 [1135630.448396] aggr_pre_handler+0x70/0xc8 [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0 [1135630.462435] brk_handler+0xbc/0xd8 [1135630.468437] do_debug_exception+0x84/0x138 [1135630.475074] el1_dbg+0x18/0x8c [1135630.480582] security_file_permission+0x0/0xd0 [1135630.487426] vfs_write+0x70/0x1c0 [1135630.493059] ksys_write+0x5c/0xc8 [1135630.498638] __arm64_sys_write+0x24/0x30 [1135630.504821] el0_svc_common+0x78/0x130 [1135630.510838] el0_svc_handler+0x38/0x78 [1135630.516834] el0_svc+0x8/0x1b0 kernel/trace/trace_kprobe.c: 1308 0xffff3df8995039ec <kprobe_perf_func+0x2c>: ldr x21, [x24,#120] include/linux/compiler.h: 294 0xffff3df8995039f0 <kprobe_perf_func+0x30>: ldr x1, [x21,x0] kernel/trace/trace_kprobe.c 1308: head = this_cpu_ptr(call->perf_events); 1309: if (hlist_empty(head)) 1310: return 0; crash> struct trace_event_call -o struct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ... } crash> struct trace_event_call ffffaf015340e528 struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ... } Race Condition Analysis: The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)<- KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL) Problem: 1. CPU0 executes (1) assigning tp_event->perf_events = list 2. CPU0 executes (2) enabling kprobe functionality via class->reg() 3. CPU1 triggers and reaches kprobe_dispatcher 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed) 5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULL CPU1 sees that kprobe functionality is enabled but does not see that perf_events has been assigned. Add pairing read an ---truncated--- CVE-2025-40042 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40042.html CVE-2025-40042 https://bugzilla.suse.com/1252861 SUSE Bug 1252861 In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Add parameter validation for packet data Syzbot reported an uninitialized value bug in nci_init_req, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools"). This bug arises due to very limited and poor input validation that was done at nic_valid_size(). This validation only validates the skb->len (directly reflects size provided at the userspace interface) with the length provided in the buffer itself (interpreted as NCI_HEADER). This leads to the processing of memory content at the address assuming the correct layout per what opcode requires there. This leads to the accesses to buffer of `skb_buff->data` which is not assigned anything yet. Following the same silent drop of packets of invalid sizes at `nic_valid_size()`, add validation of the data in the respective handlers and return error values in case of failure. Release the skb if error values are returned from handlers in `nci_nft_packet` and effectively do a silent drop Possible TODO: because we silently drop the packets, the call to `nci_request` will be waiting for completion of request and will face timeouts. These timeouts can get excessively logged in the dmesg. A proper handling of them may require to export `nci_request_cancel` (or propagate error handling from the nft packets handlers). CVE-2025-40043 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40043.html CVE-2025-40043 https://bugzilla.suse.com/1252787 SUSE Bug 1252787 In the Linux kernel, the following vulnerability has been resolved: fs: udf: fix OOB read in lengthAllocDescs handling When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read. BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309 CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #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: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Validate the computed total length against epos->bh->b_size. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-40044 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40044.html CVE-2025-40044 https://bugzilla.suse.com/1252785 SUSE Bug 1252785 In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd937x: set the comp soundwire port correctly For some reason we endup with setting soundwire port for HPHL_COMP and HPHR_COMP as zero, this can potentially result in a memory corruption due to accessing and setting -1 th element of port_map array. CVE-2025-40045 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40045.html CVE-2025-40045 https://bugzilla.suse.com/1252784 SUSE Bug 1252784 In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix overshooting recv limit It's reported that sometimes a zcrx request can receive more than was requested. It's caused by io_zcrx_recv_skb() adjusting desc->count for all received buffers including frag lists, but then doing recursive calls to process frag list skbs, which leads to desc->count double accounting and underflow. CVE-2025-40046 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40046.html CVE-2025-40046 https://bugzilla.suse.com/1252791 SUSE Bug 1252791 In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: always prune wait queue entry in io_waitid_wait() For a successful return, always remove our entry from the wait queue entry list. Previously this was skipped if a cancelation was in progress, but this can race with another invocation of the wait queue entry callback. CVE-2025-40047 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40047.html CVE-2025-40047 https://bugzilla.suse.com/1252790 SUSE Bug 1252790 In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Let userspace take care of interrupt mask Remove the logic to set interrupt mask by default in uio_hv_generic driver as the interrupt mask value is supposed to be controlled completely by the user space. If the mask bit gets changed by the driver, concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, and the user-mode driver will miss an interrupt which will cause a hang. For eg- when the driver sets inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. So let's assume that happens, the host puts a message into the ring buffer but does not interrupt. Subsequently, the user space code in the guest sets the inbound ring buffer interrupt mask to 0, saying “Hey, I'm ready for interrupts”. User space code then calls pread() to wait for an interrupt. Then one of two things happens: * The host never sends another message. So the pread() waits forever. * The host does send another message. But because there's already a message in the ring buffer, it doesn't generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever. This could be easily reproduced in hv_fcopy_uio_daemon if we delay setting interrupt mask to 0. Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1, there's a race condition. Once user space empties the inbound ring buffer, but before user space sets interrupt_mask to 0, the host could put another message in the ring buffer but it wouldn't interrupt. Then the next pread() would hang. Fix these by removing all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable userspace control the interrupt mask by writing 0/1 to /dev/uioX. CVE-2025-40048 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40048.html CVE-2025-40048 https://bugzilla.suse.com/1252862 SUSE Bug 1252862 In the Linux kernel, the following vulnerability has been resolved: Squashfs: fix uninit-value in squashfs_get_parent Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug. This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory. Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent; Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access. The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned. Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0. CVE-2025-40049 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40049.html CVE-2025-40049 https://bugzilla.suse.com/1252822 SUSE Bug 1252822 In the Linux kernel, the following vulnerability has been resolved: bpf: Skip scalar adjustment for BPF_NEG if dst is a pointer In check_alu_op(), the verifier currently calls check_reg_arg() and adjust_scalar_min_max_vals() unconditionally for BPF_NEG operations. However, if the destination register holds a pointer, these scalar adjustments are unnecessary and potentially incorrect. This patch adds a check to skip the adjustment logic when the destination register contains a pointer. CVE-2025-40050 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40050.html CVE-2025-40050 https://bugzilla.suse.com/1252856 SUSE Bug 1252856 In the Linux kernel, the following vulnerability has been resolved: vhost: vringh: Modify the return value check The return value of copy_from_iter and copy_to_iter can't be negative, check whether the copied lengths are equal. CVE-2025-40051 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40051.html CVE-2025-40051 https://bugzilla.suse.com/1252858 SUSE Bug 1252858 In the Linux kernel, the following vulnerability has been resolved: smb: client: fix crypto buffers in non-linear memory The crypto API, through the scatterlist API, expects input buffers to be in linear memory. We handle this with the cifs_sg_set_buf() helper that converts vmalloc'd memory to their corresponding pages. However, when we allocate our aead_request buffer (@creq in smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly puts aead_request->__ctx in vmalloc area. AEAD algorithm then uses ->__ctx for its private/internal data and operations, and uses sg_set_buf() for such data on a few places. This works fine as long as @creq falls into kmalloc zone (small requests) or vmalloc'd memory is still within linear range. Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too many tasks will increment the base stacks' addresses to a point where virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that happens. In practice: too many parallel reads and writes on an encrypted mount will trigger this bug. To fix this, always alloc @creq with kmalloc() instead. Also drop the @sensitive_size variable/arguments since kfree_sensitive() doesn't need it. Backtrace: [ 945.272081] ------------[ cut here ]------------ [ 945.272774] kernel BUG at include/linux/scatterlist.h:209! [ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary) [ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 [ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2) [ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220 [ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b [ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246 [ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030 [ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070 [ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000 [ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070 [ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010 [ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000 [ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0 [ 945.286683] Call Trace: [ 945.286952] <TASK> [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs] [ 945.287719] crypto_gcm_encrypt+0x36/0xe0 [ 945.288152] crypt_message+0x54a/0xad0 [cifs] [ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs] [ 945.289300] smb_send_rqst+0xa3/0x160 [cifs] [ 945.289944] cifs_call_async+0x178/0x340 [cifs] [ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs] [ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs] [ 945.291759] ? find_held_lock+0x32/0x90 [ 945.292212] ? netfs_advance_write+0xf2/0x310 [ 945.292723] netfs_advance_write+0xf2/0x310 [ 945.293210] netfs_write_folio+0x346/0xcc0 [ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10 [ 945.294250] netfs_writepages+0x117/0x460 [ 945.294724] do_writepages+0xbe/0x170 [ 945.295152] ? find_held_lock+0x32/0x90 [ 945.295600] ? kvm_sched_clock_read+0x11/0x20 [ 945.296103] __writeback_single_inode+0x56/0x4b0 [ 945.296643] writeback_sb_inodes+0x229/0x550 [ 945.297140] __writeback_inodes_wb+0x4c/0xe0 [ 945.297642] wb_writeback+0x2f1/0x3f0 [ 945.298069] wb_workfn+0x300/0x490 [ 945.298472] process_one_work+0x1fe/0x590 [ 945.298949] worker_thread+0x1ce/0x3c0 [ 945.299397] ? __pfx_worker_thread+0x10/0x10 [ 945.299900] kthr ---truncated--- CVE-2025-40052 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40052.html CVE-2025-40052 https://bugzilla.suse.com/1252851 SUSE Bug 1252851 In the Linux kernel, the following vulnerability has been resolved: net: dlink: handle copy_thresh allocation failure The driver did not handle failure of `netdev_alloc_skb_ip_align()`. If the allocation failed, dereferencing `skb->protocol` could lead to a NULL pointer dereference. This patch tries to allocate `skb`. If the allocation fails, it falls back to the normal path. Tested-on: D-Link DGE-550T Rev-A3 CVE-2025-40053 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40053.html CVE-2025-40053 https://bugzilla.suse.com/1252808 SUSE Bug 1252808 In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF issue in f2fs_merge_page_bio() As JY reported in bugzilla [1], Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98 lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4 CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P B W OE 6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5 Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Workqueue: writeback wb_workfn (flush-254:49) Call trace: f2fs_is_cp_guaranteed+0x70/0x98 f2fs_inplace_write_data+0x174/0x2f4 f2fs_do_write_data_page+0x214/0x81c f2fs_write_single_data_page+0x28c/0x764 f2fs_write_data_pages+0x78c/0xce4 do_writepages+0xe8/0x2fc __writeback_single_inode+0x4c/0x4b4 writeback_sb_inodes+0x314/0x540 __writeback_inodes_wb+0xa4/0xf4 wb_writeback+0x160/0x448 wb_workfn+0x2f0/0x5dc process_scheduled_works+0x1c8/0x458 worker_thread+0x334/0x3f0 kthread+0x118/0x1ac ret_from_fork+0x10/0x20 [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575 The panic was caused by UAF issue w/ below race condition: kworker - writepages - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #1 into bio & cache bio in io->bio_list - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #2 into bio which is linked in io->bio_list write - f2fs_write_begin : write page #1 - f2fs_folio_wait_writeback - f2fs_submit_merged_ipu_write - f2fs_submit_write_bio : submit bio which inclues page #1 and #2 software IRQ - f2fs_write_end_io - fscrypt_free_bounce_page : freed bounced page which belongs to page #2 - inc_page_count( , WB_DATA_TYPE(data_folio), false) : data_folio points to fio->encrypted_page the bounced page can be freed before accessing it in f2fs_is_cp_guarantee() It can reproduce w/ below testcase: Run below script in shell #1: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync" Run below script in shell #2: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync" So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after commit page into internal ipu cache. CVE-2025-40054 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40054.html CVE-2025-40054 https://bugzilla.suse.com/1252853 SUSE Bug 1252853 In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix double free in user_cluster_connect() user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free. CVE-2025-40055 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40055.html CVE-2025-40055 https://bugzilla.suse.com/1252821 SUSE Bug 1252821 In the Linux kernel, the following vulnerability has been resolved: vhost: vringh: Fix copy_to_iter return value check The return value of copy_to_iter can't be negative, check whether the copied length is equal to the requested length instead of checking for negative values. CVE-2025-40056 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40056.html CVE-2025-40056 https://bugzilla.suse.com/1252826 SUSE Bug 1252826 In the Linux kernel, the following vulnerability has been resolved: ptp: Add a upper bound on max_vclocks syzbot reported WARNING in max_vclocks_store. This occurs when the argument max is too large for kcalloc to handle. Extend the guard to guard against values that are too large for kcalloc CVE-2025-40057 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40057.html CVE-2025-40057 https://bugzilla.suse.com/1252825 SUSE Bug 1252825 In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Disallow dirty tracking if incoherent page walk Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work. The Intel VT-d specification, Section 3.10 "Snoop Behavior" states: "Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault." To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported. CVE-2025-40058 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40058.html CVE-2025-40058 https://bugzilla.suse.com/1252854 SUSE Bug 1252854 In the Linux kernel, the following vulnerability has been resolved: coresight: Fix incorrect handling for return value of devm_kzalloc The return value of devm_kzalloc could be an null pointer, use "!desc.pdata" to fix incorrect handling return value of devm_kzalloc. CVE-2025-40059 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40059.html CVE-2025-40059 https://bugzilla.suse.com/1252809 SUSE Bug 1252809 In the Linux kernel, the following vulnerability has been resolved: coresight: trbe: Return NULL pointer for allocation failures When the TRBE driver fails to allocate a buffer, it currently returns the error code "-ENOMEM". However, the caller etm_setup_aux() only checks for a NULL pointer, so it misses the error. As a result, the driver continues and eventually causes a kernel panic. Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on allocation failures. This allows that the callers can properly handle the failure. CVE-2025-40060 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40060.html CVE-2025-40060 https://bugzilla.suse.com/1252848 SUSE Bug 1252848 In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix race in do_task() when draining When do_task() exhausts its iteration budget (!ret), it sets the state to TASK_STATE_IDLE to reschedule, without a secondary check on the current task->state. This can overwrite the TASK_STATE_DRAINING state set by a concurrent call to rxe_cleanup_task() or rxe_disable_task(). While state changes are protected by a spinlock, both rxe_cleanup_task() and rxe_disable_task() release the lock while waiting for the task to finish draining in the while(!is_done(task)) loop. The race occurs if do_task() hits its iteration limit and acquires the lock in this window. The cleanup logic may then proceed while the task incorrectly reschedules itself, leading to a potential use-after-free. This bug was introduced during the migration from tasklets to workqueues, where the special handling for the draining case was lost. Fix this by restoring the original pre-migration behavior. If the state is TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the task to finish its work, so that a subsequent iteration can reach the switch statement and correctly transition the state to TASK_STATE_DRAINED, stopping the task as intended. CVE-2025-40061 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40061.html CVE-2025-40061 https://bugzilla.suse.com/1252849 SUSE Bug 1252849 In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs When the initialization of qm->debug.acc_diff_reg fails, the probe process does not exit. However, after qm->debug.qm_diff_regs is freed, it is not set to NULL. This can lead to a double free when the remove process attempts to free it again. Therefore, qm->debug.qm_diff_regs should be set to NULL after it is freed. CVE-2025-40062 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40062.html CVE-2025-40062 https://bugzilla.suse.com/1252850 SUSE Bug 1252850 In the Linux kernel, the following vulnerability has been resolved: crypto: comp - Use same definition of context alloc and free ops In commit 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation code into acomp"), the crypto_acomp_streams struct was made to rely on having the alloc_ctx and free_ctx operations defined in the same order as the scomp_alg struct. But in that same commit, the alloc_ctx and free_ctx members of scomp_alg may be randomized by structure layout randomization, since they are contained in a pure ops structure (containing only function pointers). If the pointers within scomp_alg are randomized, but those in crypto_acomp_streams are not, then the order may no longer match. This fixes the problem by removing the union from scomp_alg so that both crypto_acomp_streams and scomp_alg will share the same definition of alloc_ctx and free_ctx, ensuring they will always have the same layout. CVE-2025-40063 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40063.html CVE-2025-40063 https://bugzilla.suse.com/1252844 SUSE Bug 1252844 In the Linux kernel, the following vulnerability has been resolved: smc: Fix use-after-free in __pnet_find_base_ndev(). syzbot reported use-after-free of net_device in __pnet_find_base_ndev(), which was called during connect(). [0] smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passes down to pnet_find_base_ndev(), where RTNL is held. Then, UAF happened at __pnet_find_base_ndev() when the dev is first used. This means dev had already been freed before acquiring RTNL in pnet_find_base_ndev(). While dev is going away, dst->dev could be swapped with blackhole_netdev, and the dev's refcnt by dst will be released. We must hold dev's refcnt before calling smc_pnet_find_ism_resource(). Also, smc_pnet_find_roce_resource() has the same problem. Let's use __sk_dst_get() and dst_dev_rcu() in the two functions. [0]: BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609 CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f47cbf8eba9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9 RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 </TASK> The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000 raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node ---truncated--- CVE-2025-40064 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40064.html CVE-2025-40064 https://bugzilla.suse.com/1252845 SUSE Bug 1252845 In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Write hgatp register with valid mode bits According to the RISC-V Privileged Architecture Spec, when MODE=Bare is selected,software must write zero to the remaining fields of hgatp. We have detected the valid mode supported by the HW before, So using a valid mode to detect how many vmid bits are supported. CVE-2025-40065 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40065.html CVE-2025-40065 https://bugzilla.suse.com/1252846 SUSE Bug 1252846 In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: Check phy before init msta_link in mt7996_mac_sta_add_links() In order to avoid a possible NULL pointer dereference in mt7996_mac_sta_init_link routine, move the phy pointer check before running mt7996_mac_sta_init_link() in mt7996_mac_sta_add_links routine. CVE-2025-40066 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40066.html CVE-2025-40066 https://bugzilla.suse.com/1252842 SUSE Bug 1252842 In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist Index allocation requires at least one bit in the $BITMAP attribute to track usage of index entries. If the bitmap is empty while index blocks are already present, this reflects on-disk corruption. syzbot triggered this condition using a malformed NTFS image. During a rename() operation involving a long filename (which spans multiple index entries), the empty bitmap allowed the name to be added without valid tracking. Subsequent deletion of the original entry failed with -ENOENT, due to unexpected index state. Reject such cases by verifying that the bitmap is not empty when index blocks exist. CVE-2025-40067 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40067.html CVE-2025-40067 https://bugzilla.suse.com/1252840 SUSE Bug 1252840 In the Linux kernel, the following vulnerability has been resolved: fs: ntfs3: Fix integer overflow in run_unpack() The MFT record relative to the file being opened contains its runlist, an array containing information about the file's location on the physical disk. Analysis of all Call Stack paths showed that the values of the runlist array, from which LCNs are calculated, are not validated before run_unpack function. The run_unpack function decodes the compressed runlist data format from MFT attributes (for example, $DATA), converting them into a runs_tree structure, which describes the mapping of virtual clusters (VCN) to logical clusters (LCN). The NTFS3 subsystem also has a shortcut for deleting files from MFT records - in this case, the RUN_DEALLOCATE command is sent to the run_unpack input, and the function logic provides that all data transferred to the runlist about file or directory is deleted without creating a runs_tree structure. Substituting the runlist in the $DATA attribute of the MFT record for an arbitrary file can lead either to access to arbitrary data on the disk bypassing access checks to them (since the inode access check occurs above) or to destruction of arbitrary data on the disk. Add overflow check for addition operation. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-40068 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40068.html CVE-2025-40068 https://bugzilla.suse.com/1252843 SUSE Bug 1252843 In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix obj leak in VM_BIND error path If we fail a handle-lookup part way thru, we need to drop the already obtained obj references. Patchwork: https://patchwork.freedesktop.org/patch/669784/ CVE-2025-40069 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40069.html CVE-2025-40069 https://bugzilla.suse.com/1252831 SUSE Bug 1252831 In the Linux kernel, the following vulnerability has been resolved: pps: fix warning in pps_register_cdev when register device fail Similar to previous commit 2a934fdb01db ("media: v4l2-dev: fix error handling in __video_register_device()"), the release hook should be set before device_register(). Otherwise, when device_register() return error and put_device() try to callback the release function, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: <TASK> kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Before commit c79a39dc8d06 ("pps: Fix a use-after-free"), pps_register_cdev() call device_create() to create pps->dev, which will init dev->release to device_create_release(). Now the comment is outdated, just remove it. Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removed in pps_register_source() to avoid a double free in the failure case. CVE-2025-40070 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40070.html CVE-2025-40070 https://bugzilla.suse.com/1252836 SUSE Bug 1252836 In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Don't block input queue by waiting MSC Currently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue. Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used. CVE-2025-40071 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40071.html CVE-2025-40071 https://bugzilla.suse.com/1252797 SUSE Bug 1252797 In the Linux kernel, the following vulnerability has been resolved: fanotify: Validate the return value of mnt_ns_from_dentry() before dereferencing The function do_fanotify_mark() does not validate if mnt_ns_from_dentry() returns NULL before dereferencing mntns->user_ns. This causes a NULL pointer dereference in do_fanotify_mark() if the path is not a mount namespace object. Fix this by checking mnt_ns_from_dentry()'s return value before dereferencing it. Before the patch $ gcc fanotify_nullptr.c -o fanotify_nullptr $ mkdir A $ ./fanotify_nullptr Fanotify fd: 3 fanotify_mark: Operation not permitted $ unshare -Urm Fanotify fd: 3 Killed int main(void){ int ffd; ffd = fanotify_init(FAN_CLASS_NOTIF | FAN_REPORT_MNT, 0); if(ffd < 0){ perror("fanotify_init"); exit(EXIT_FAILURE); } printf("Fanotify fd: %d\n",ffd); if(fanotify_mark(ffd, FAN_MARK_ADD | FAN_MARK_MNTNS, FAN_MNT_ATTACH, AT_FDCWD, "A") < 0){ perror("fanotify_mark"); exit(EXIT_FAILURE); } return 0; } After the patch $ gcc fanotify_nullptr.c -o fanotify_nullptr $ mkdir A $ ./fanotify_nullptr Fanotify fd: 3 fanotify_mark: Operation not permitted $ unshare -Urm Fanotify fd: 3 fanotify_mark: Invalid argument [ 25.694973] BUG: kernel NULL pointer dereference, address: 0000000000000038 [ 25.695006] #PF: supervisor read access in kernel mode [ 25.695012] #PF: error_code(0x0000) - not-present page [ 25.695017] PGD 109a30067 P4D 109a30067 PUD 142b46067 PMD 0 [ 25.695025] Oops: Oops: 0000 [#1] SMP NOPTI [ 25.695032] CPU: 4 UID: 1000 PID: 1478 Comm: fanotify_nullpt Not tainted 6.17.0-rc4 #1 PREEMPT(lazy) [ 25.695040] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [ 25.695049] RIP: 0010:do_fanotify_mark+0x817/0x950 [ 25.695066] Code: 04 00 00 e9 45 fd ff ff 48 8b 7c 24 48 4c 89 54 24 18 4c 89 5c 24 10 4c 89 0c 24 e8 b3 11 fc ff 4c 8b 54 24 18 4c 8b 5c 24 10 <48> 8b 78 38 4c 8b 0c 24 49 89 c4 e9 13 fd ff ff 8b 4c 24 28 85 c9 [ 25.695081] RSP: 0018:ffffd31c469e3c08 EFLAGS: 00010203 [ 25.695104] RAX: 0000000000000000 RBX: 0000000001000000 RCX: ffff8eb48aebd220 [ 25.695110] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8eb4835e8180 [ 25.695115] RBP: 0000000000000111 R08: 0000000000000000 R09: 0000000000000000 [ 25.695142] R10: ffff8eb48a7d56c0 R11: ffff8eb482bede00 R12: 00000000004012a7 [ 25.695148] R13: 0000000000000110 R14: 0000000000000001 R15: ffff8eb48a7d56c0 [ 25.695154] FS: 00007f8733bda740(0000) GS:ffff8eb61ce5f000(0000) knlGS:0000000000000000 [ 25.695162] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 25.695170] CR2: 0000000000000038 CR3: 0000000136994006 CR4: 00000000003706f0 [ 25.695201] Call Trace: [ 25.695209] <TASK> [ 25.695215] __x64_sys_fanotify_mark+0x1f/0x30 [ 25.695222] do_syscall_64+0x82/0x2c0 ... CVE-2025-40072 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40072.html CVE-2025-40072 https://bugzilla.suse.com/1252796 SUSE Bug 1252796 In the Linux kernel, the following vulnerability has been resolved: drm/msm: Do not validate SSPP when it is not ready Current code will validate current plane and previous plane to confirm they can share a SSPP with multi-rect mode. The SSPP is already allocated for previous plane, while current plane is not associated with any SSPP yet. Null pointer is referenced when validating the SSPP of current plane. Skip SSPP validation for current plane. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000888ac3000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 4 UID: 0 PID: 1891 Comm: modetest Tainted: G S 6.15.0-rc2-g3ee3f6e1202e #335 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: SM8650 EV1 rev1 4slam 2et (DT) pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : dpu_plane_is_multirect_capable+0x68/0x90 lr : dpu_assign_plane_resources+0x288/0x410 sp : ffff800093dcb770 x29: ffff800093dcb770 x28: 0000000000002000 x27: ffff000817c6c000 x26: ffff000806b46368 x25: ffff0008013f6080 x24: ffff00080cbf4800 x23: ffff000810842680 x22: ffff0008013f1080 x21: ffff00080cc86080 x20: ffff000806b463b0 x19: ffff00080cbf5a00 x18: 00000000ffffffff x17: 707a5f657a696c61 x16: 0000000000000003 x15: 0000000000002200 x14: 00000000ffffffff x13: 00aaaaaa00aaaaaa x12: 0000000000000000 x11: ffff000817c6e2b8 x10: 0000000000000000 x9 : ffff80008106a950 x8 : ffff00080cbf48f4 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000438 x3 : 0000000000000438 x2 : ffff800082e245e0 x1 : 0000000000000008 x0 : 0000000000000000 Call trace: dpu_plane_is_multirect_capable+0x68/0x90 (P) dpu_crtc_atomic_check+0x5bc/0x650 drm_atomic_helper_check_planes+0x13c/0x220 drm_atomic_helper_check+0x58/0xb8 msm_atomic_check+0xd8/0xf0 drm_atomic_check_only+0x4a8/0x968 drm_atomic_commit+0x50/0xd8 drm_atomic_helper_update_plane+0x140/0x188 __setplane_atomic+0xfc/0x148 drm_mode_setplane+0x164/0x378 drm_ioctl_kernel+0xc0/0x140 drm_ioctl+0x20c/0x500 __arm64_sys_ioctl+0xbc/0xf8 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x48/0xf8 do_el0_svc+0x28/0x40 el0_svc+0x30/0xd0 el0t_64_sync_handler+0x144/0x168 el0t_64_sync+0x198/0x1a0 Code: b9402021 370fffc1 f9401441 3707ff81 (f94010a1) ---[ end trace 0000000000000000 ]--- Patchwork: https://patchwork.freedesktop.org/patch/669224/ CVE-2025-40073 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40073.html CVE-2025-40073 https://bugzilla.suse.com/1252798 SUSE Bug 1252798 In the Linux kernel, the following vulnerability has been resolved: ipv4: start using dst_dev_rcu() Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF. Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(), ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu(). CVE-2025-40074 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40074.html CVE-2025-40074 https://bugzilla.suse.com/1252794 SUSE Bug 1252794 In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: use dst_dev_net_rcu() Replace three dst_dev() with a lockdep enabled helper. CVE-2025-40075 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40075.html CVE-2025-40075 https://bugzilla.suse.com/1252795 SUSE Bug 1252795 In the Linux kernel, the following vulnerability has been resolved: PCI: rcar-host: Pass proper IRQ domain to generic_handle_domain_irq() Starting with commit dd26c1a23fd5 ("PCI: rcar-host: Switch to msi_create_parent_irq_domain()"), the MSI parent IRQ domain is NULL because the object of type struct irq_domain_info passed to: msi_create_parent_irq_domain() -> irq_domain_instantiate()() -> __irq_domain_instantiate() has no reference to the parent IRQ domain. Using msi->domain->parent as an argument for generic_handle_domain_irq() leads to below error: "Unable to handle kernel NULL pointer dereference at virtual address" This error was identified while switching the upcoming RZ/G3S PCIe host controller driver to msi_create_parent_irq_domain() (which was using a similar pattern to handle MSIs (see link section)), but it was not tested on hardware using the pcie-rcar-host controller driver due to lack of hardware. [mani: reworded subject and description] CVE-2025-40076 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40076.html CVE-2025-40076 https://bugzilla.suse.com/1252792 SUSE Bug 1252792 In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid overflow while left shift operation Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation. CVE-2025-40077 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40077.html CVE-2025-40077 https://bugzilla.suse.com/1252782 SUSE Bug 1252782 In the Linux kernel, the following vulnerability has been resolved: bpf: Explicitly check accesses to bpf_sock_addr Syzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exit which triggers: verifier bug: error during ctx access conversion (0) This is happening because offset 60 in bpf_sock_addr corresponds to an implicit padding of 4 bytes, right after msg_src_ip4. Access to this padding isn't rejected in sock_addr_is_valid_access and it thus later fails to convert the access. This patch fixes it by explicitly checking the various fields of bpf_sock_addr in sock_addr_is_valid_access. I checked the other ctx structures and is_valid_access functions and didn't find any other similar cases. Other cases of (properly handled) padding are covered in new tests in a subsequent patch. CVE-2025-40078 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40078.html CVE-2025-40078 https://bugzilla.suse.com/1252789 SUSE Bug 1252789 In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Sign extend struct ops return values properly The ns_bpf_qdisc selftest triggers a kernel panic: Unable to handle kernel paging request at virtual address ffffffffa38dbf58 Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000 [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000 Oops [#1] Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)] CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G W OE 6.17.0-rc1-g2465bb83e0b4 #1 NONE Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024 epc : __qdisc_run+0x82/0x6f0 ra : __qdisc_run+0x6e/0x6f0 epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550 gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180 t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0 s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001 a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000 a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049 s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000 s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0 s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000 s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000 t5 : 0000000000000000 t6 : ff60000093a6a8b6 status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d [<ffffffff80bd5c7a>] __qdisc_run+0x82/0x6f0 [<ffffffff80b6fe58>] __dev_queue_xmit+0x4c0/0x1128 [<ffffffff80b80ae0>] neigh_resolve_output+0xd0/0x170 [<ffffffff80d2daf6>] ip6_finish_output2+0x226/0x6c8 [<ffffffff80d31254>] ip6_finish_output+0x10c/0x2a0 [<ffffffff80d31446>] ip6_output+0x5e/0x178 [<ffffffff80d2e232>] ip6_xmit+0x29a/0x608 [<ffffffff80d6f4c6>] inet6_csk_xmit+0xe6/0x140 [<ffffffff80c985e4>] __tcp_transmit_skb+0x45c/0xaa8 [<ffffffff80c995fe>] tcp_connect+0x9ce/0xd10 [<ffffffff80d66524>] tcp_v6_connect+0x4ac/0x5e8 [<ffffffff80cc19b8>] __inet_stream_connect+0xd8/0x318 [<ffffffff80cc1c36>] inet_stream_connect+0x3e/0x68 [<ffffffff80b42b20>] __sys_connect_file+0x50/0x88 [<ffffffff80b42bee>] __sys_connect+0x96/0xc8 [<ffffffff80b42c40>] __riscv_sys_connect+0x20/0x30 [<ffffffff80e5bcae>] do_trap_ecall_u+0x256/0x378 [<ffffffff80e69af2>] handle_exception+0x14a/0x156 Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709 ---[ end trace 0000000000000000 ]--- The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires RISC-V ABI. So let's sign extend struct ops return values according to the function model and RISC-V ABI([0]). [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf CVE-2025-40079 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40079.html CVE-2025-40079 https://bugzilla.suse.com/1252786 SUSE Bug 1252786 In the Linux kernel, the following vulnerability has been resolved: nbd: restrict sockets to TCP and UDP Recently, syzbot started to abuse NBD with all kinds of sockets. Commit cf1b2326b734 ("nbd: verify socket is supported during setup") made sure the socket supported a shutdown() method. Explicitely accept TCP and UNIX stream sockets. CVE-2025-40080 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40080.html CVE-2025-40080 https://bugzilla.suse.com/1252774 SUSE Bug 1252774 In the Linux kernel, the following vulnerability has been resolved: perf: arm_spe: Prevent overflow in PERF_IDX2OFF() Cast nr_pages to unsigned long to avoid overflow when handling large AUX buffer sizes (>= 2 GiB). CVE-2025-40081 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40081.html CVE-2025-40081 https://bugzilla.suse.com/1252776 SUSE Bug 1252776 In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290 CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe0e9fae16d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3 RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000 RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 </TASK> Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f When hfsplus_uni2asc is called from hfsplus_listxattr, it actually passes in a struct hfsplus_attr_unistr*. The size of the corresponding structure is different from that of hfsplus_unistr, so the previous fix (94458781aee6) is insufficient. The pointer on the unicode buffer is still going beyond the allocated memory. This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and hfsplus_uni2asc_str to process two unicode buffers, struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively. When ustrlen value is bigger than the allocated memory size, the ustrlen value is limited to an safe size. CVE-2025-40082 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40082.html CVE-2025-40082 https://bugzilla.suse.com/1252775 SUSE Bug 1252775 In the Linux kernel, the following vulnerability has been resolved: ksmbd: transport_ipc: validate payload size before reading handle handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing. This is a minimal fix to guard the initial handle read. CVE-2025-40084 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40084.html CVE-2025-40084 https://bugzilla.suse.com/1252874 SUSE Bug 1252874 In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card In try_to_register_card(), the return value of usb_ifnum_to_if() is passed directly to usb_interface_claimed() without a NULL check, which will lead to a NULL pointer dereference when creating an invalid USB audio device. Fix this by adding a check to ensure the interface pointer is valid before passing it to usb_interface_claimed(). CVE-2025-40085 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40085.html CVE-2025-40085 https://bugzilla.suse.com/1252873 SUSE Bug 1252873 In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't allow evicting of BOs in same VM in array of VM binds An array of VM binds can potentially evict other buffer objects (BOs) within the same VM under certain conditions, which may lead to NULL pointer dereferences later in the bind pipeline. To prevent this, clear the allow_res_evict flag in the xe_bo_validate call. v2: - Invert polarity of no_res_evict (Thomas) - Add comment in code explaining issue (Thomas) (cherry picked from commit 8b9ba8d6d95fe75fed6b0480bb03da4b321bea08) CVE-2025-40086 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40086.html CVE-2025-40086 https://bugzilla.suse.com/1252923 SUSE Bug 1252923 In the Linux kernel, the following vulnerability has been resolved: NFSD: Define a proc_layoutcommit for the FlexFiles layout type Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout. CVE-2025-40087 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40087.html CVE-2025-40087 https://bugzilla.suse.com/1252909 SUSE Bug 1252909 In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp() The hfsplus_strcasecmp() logic can trigger the issue: [ 117.317703][ T9855] ================================================================== [ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490 [ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855 [ 117.319577][ T9855] [ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full) [ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 117.319783][ T9855] Call Trace: [ 117.319785][ T9855] <TASK> [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0 [ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10 [ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0 [ 117.319816][ T9855] ? lock_release+0x4b/0x3e0 [ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40 [ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319842][ T9855] print_report+0x17e/0x7e0 [ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319862][ T9855] ? __phys_addr+0xd3/0x180 [ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319876][ T9855] kasan_report+0x147/0x180 [ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490 [ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10 [ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0 [ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470 [ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10 [ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10 [ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510 [ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10 [ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510 [ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0 [ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120 [ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890 [ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10 [ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0 [ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80 [ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10 [ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100 [ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150 [ 117.320034][ T9855] __lookup_slow+0x297/0x3d0 [ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10 [ 117.320045][ T9855] ? down_read+0x1ad/0x2e0 [ 117.320055][ T9855] lookup_slow+0x53/0x70 [ 117.320065][ T9855] walk_component+0x2f0/0x430 [ 117.320073][ T9855] path_lookupat+0x169/0x440 [ 117.320081][ T9855] filename_lookup+0x212/0x590 [ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10 [ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290 [ 117.320105][ T9855] ? getname_flags+0x1e5/0x540 [ 117.320112][ T9855] user_path_at+0x3a/0x60 [ 117.320117][ T9855] __x64_sys_umount+0xee/0x160 [ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10 [ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0 [ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0 [ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0 [ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07 [ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08 [ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated--- CVE-2025-40088 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40088.html CVE-2025-40088 https://bugzilla.suse.com/1252904 SUSE Bug 1252904 In the Linux kernel, the following vulnerability has been resolved: cxl/features: Add check for no entries in cxl_feature_info cxl EDAC calls cxl_feature_info() to get the feature information and if the hardware has no Features support, cxlfs may be passed in as NULL. [ 51.957498] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 51.965571] #PF: supervisor read access in kernel mode [ 51.971559] #PF: error_code(0x0000) - not-present page [ 51.977542] PGD 17e4f6067 P4D 0 [ 51.981384] Oops: Oops: 0000 [#1] SMP NOPTI [ 51.986300] CPU: 49 UID: 0 PID: 3782 Comm: systemd-udevd Not tainted 6.17.0dj test+ #64 PREEMPT(voluntary) [ 51.997355] Hardware name: <removed> [ 52.009790] RIP: 0010:cxl_feature_info+0xa/0x80 [cxl_core] Add a check for cxlfs before dereferencing it and return -EOPNOTSUPP if there is no cxlfs created due to no hardware support. CVE-2025-40089 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40089.html CVE-2025-40089 https://bugzilla.suse.com/1252903 SUSE Bug 1252903 In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix recursive locking in RPC handle list access Since commit 305853cce3794 ("ksmbd: Fix race condition in RPC handle list access"), ksmbd_session_rpc_method() attempts to lock sess->rpc_lock. This causes hung connections / tasks when a client attempts to open a named pipe. Using Samba's rpcclient tool: $ rpcclient //192.168.1.254 -U user%password $ rpcclient $> srvinfo <connection hung here> Kernel side: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/0:0 state:D stack:0 pid:5021 tgid:5021 ppid:2 flags:0x00200000 Workqueue: ksmbd-io handle_ksmbd_work Call trace: __schedule from schedule+0x3c/0x58 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from rwsem_down_read_slowpath+0x1b0/0x1d8 rwsem_down_read_slowpath from down_read+0x28/0x30 down_read from ksmbd_session_rpc_method+0x18/0x3c ksmbd_session_rpc_method from ksmbd_rpc_open+0x34/0x68 ksmbd_rpc_open from ksmbd_session_rpc_open+0x194/0x228 ksmbd_session_rpc_open from create_smb2_pipe+0x8c/0x2c8 create_smb2_pipe from smb2_open+0x10c/0x27ac smb2_open from handle_ksmbd_work+0x238/0x3dc handle_ksmbd_work from process_scheduled_works+0x160/0x25c process_scheduled_works from worker_thread+0x16c/0x1e8 worker_thread from kthread+0xa8/0xb8 kthread from ret_from_fork+0x14/0x38 Exception stack(0x8529ffb0 to 0x8529fff8) The task deadlocks because the lock is already held: ksmbd_session_rpc_open down_write(&sess->rpc_lock) ksmbd_rpc_open ksmbd_session_rpc_method down_read(&sess->rpc_lock) <-- deadlock Adjust ksmbd_session_rpc_method() callers to take the lock when necessary. CVE-2025-40090 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40090.html CVE-2025-40090 https://bugzilla.suse.com/1252910 SUSE Bug 1252910 In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix too early devlink_free() in ixgbe_remove() Since ixgbe_adapter is embedded in devlink, calling devlink_free() prematurely in the ixgbe_remove() path can lead to UAF. Move devlink_free() to the end. KASAN report: BUG: KASAN: use-after-free in ixgbe_reset_interrupt_capability+0x140/0x180 [ixgbe] Read of size 8 at addr ffff0000adf813e0 by task bash/2095 CPU: 1 UID: 0 PID: 2095 Comm: bash Tainted: G S 6.17.0-rc2-tnguy.net-queue+ #1 PREEMPT(full) [...] Call trace: show_stack+0x30/0x90 (C) dump_stack_lvl+0x9c/0xd0 print_address_description.constprop.0+0x90/0x310 print_report+0x104/0x1f0 kasan_report+0x88/0x180 __asan_report_load8_noabort+0x20/0x30 ixgbe_reset_interrupt_capability+0x140/0x180 [ixgbe] ixgbe_clear_interrupt_scheme+0xf8/0x130 [ixgbe] ixgbe_remove+0x2d0/0x8c0 [ixgbe] pci_device_remove+0xa0/0x220 device_remove+0xb8/0x170 device_release_driver_internal+0x318/0x490 device_driver_detach+0x40/0x68 unbind_store+0xec/0x118 drv_attr_store+0x64/0xb8 sysfs_kf_write+0xcc/0x138 kernfs_fop_write_iter+0x294/0x440 new_sync_write+0x1fc/0x588 vfs_write+0x480/0x6a0 ksys_write+0xf0/0x1e0 __arm64_sys_write+0x70/0xc0 invoke_syscall.constprop.0+0xcc/0x280 el0_svc_common.constprop.0+0xa8/0x248 do_el0_svc+0x44/0x68 el0_svc+0x54/0x160 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 CVE-2025-40091 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40091.html CVE-2025-40091 https://bugzilla.suse.com/1252915 SUSE Bug 1252915 In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Refactor bind path to use __free() After an bind/unbind cycle, the ncm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20 CVE-2025-40092 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40092.html CVE-2025-40092 https://bugzilla.suse.com/1252916 SUSE Bug 1252916 In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ecm: Refactor bind path to use __free() After an bind/unbind cycle, the ecm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. CVE-2025-40093 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40093.html CVE-2025-40093 https://bugzilla.suse.com/1252906 SUSE Bug 1252906 In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_acm: Refactor bind path to use __free() After an bind/unbind cycle, the acm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec gs_free_req+0x30/0x44 acm_bind+0x1b8/0x1f4 usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20 CVE-2025-40094 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40094.html CVE-2025-40094 https://bugzilla.suse.com/1252899 SUSE Bug 1252899 In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Refactor bind path to use __free() After an bind/unbind cycle, the rndis->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. CVE-2025-40095 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40095.html CVE-2025-40095 https://bugzilla.suse.com/1252898 SUSE Bug 1252898 In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free. Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this: drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]); Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it. The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies"). At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder") noticed and attempted to fix. But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case. As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain. While fixing we also improve the comment and explain the reason for taking the reference and not dropping it. CVE-2025-40096 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40096.html CVE-2025-40096 https://bugzilla.suse.com/1252902 SUSE Bug 1252902 In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix missing pointer check in hda_component_manager_init function The __component_match_add function may assign the 'matchptr' pointer the value ERR_PTR(-ENOMEM), which will subsequently be dereferenced. The call stack leading to the error looks like this: hda_component_manager_init |-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign |-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereference Add IS_ERR() check to prevent the crash. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-40097 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40097.html CVE-2025-40097 https://bugzilla.suse.com/1252900 SUSE Bug 1252900 In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-40098 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40098.html CVE-2025-40098 https://bugzilla.suse.com/1252917 SUSE Bug 1252917 In the Linux kernel, the following vulnerability has been resolved: cifs: parse_dfs_referrals: prevent oob on malformed input Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS - reply smaller than sizeof(struct get_dfs_referral_rsp) - reply with number of referrals smaller than NumberOfReferrals in the header Processing of such replies will cause oob. Return -EINVAL error on such replies to prevent oob-s. CVE-2025-40099 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40099.html CVE-2025-40099 https://bugzilla.suse.com/1252911 SUSE Bug 1252911 In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: <TASK> btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- CVE-2025-40100 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40100.html CVE-2025-40100 https://bugzilla.suse.com/1252918 SUSE Bug 1252918 In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST At the end of btrfs_load_block_group_zone_info() the first thing we do is to ensure that if the mapping type is not a SINGLE one and there is no RAID stripe tree, then we return early with an error. Doing that, though, prevents the code from running the last calls from this function which are about freeing memory allocated during its run. Hence, in this case, instead of returning early, we set the ret value and fall through the rest of the cleanup code. CVE-2025-40101 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40101.html CVE-2025-40101 https://bugzilla.suse.com/1252901 SUSE Bug 1252901 In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state. CVE-2025-40102 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40102.html CVE-2025-40102 https://bugzilla.suse.com/1252919 SUSE Bug 1252919 In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks. CVE-2025-40103 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40103.html CVE-2025-40103 https://bugzilla.suse.com/1252924 SUSE Bug 1252924 In the Linux kernel, the following vulnerability has been resolved: ixgbevf: fix mailbox API compatibility by negotiating supported features There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API. This convention has been broken since introducing API 1.4. Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself. Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes. The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX. To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox. New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op. Features negotiation mechanism gives possibility to be extended with new features when needed in the future. CVE-2025-40104 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40104.html CVE-2025-40104 https://bugzilla.suse.com/1252921 SUSE Bug 1252921 In the Linux kernel, the following vulnerability has been resolved: vfs: Don't leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well. CVE-2025-40105 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40105.html CVE-2025-40105 https://bugzilla.suse.com/1252928 SUSE Bug 1252928 In the Linux kernel, the following vulnerability has been resolved: comedi: fix divide-by-zero in comedi_buf_munge() The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands. CVE-2025-40106 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40106.html CVE-2025-40106 https://bugzilla.suse.com/1252891 SUSE Bug 1252891 In the Linux kernel, the following vulnerability has been resolved: x86/vmscape: Add conditional IBPB mitigation VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit. Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB. This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace. The intent is to integrate and optimize these cases post-embargo. [ dhansen: elaborate on suboptimal IBPB solution ] CVE-2025-40300 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-40300.html CVE-2025-40300 https://bugzilla.suse.com/1249561 SUSE Bug 1249561 In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing The Extended Supported Rates (ESR) IE handling in OnBeacon accessed *(p + 1 + ielen) and *(p + 2 + ielen) without verifying that these offsets lie within the received frame buffer. A malformed beacon with an ESR IE positioned at the end of the buffer could cause an out-of-bounds read, potentially triggering a kernel panic. Add a boundary check to ensure that the ESR IE body and the subsequent bytes are within the limits of the frame before attempting to access them. This prevents OOB reads caused by malformed beacon frames. CVE-2025-68254 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68254.html CVE-2025-68254 https://bugzilla.suse.com/1255140 SUSE Bug 1255140 In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing The Supported Rates IE length from an incoming Association Request frame was used directly as the memcpy() length when copying into a fixed-size 16-byte stack buffer (supportRate). A malicious station can advertise an IE length larger than 16 bytes, causing a stack buffer overflow. Clamp ie_len to the buffer size before copying the Supported Rates IE, and correct the bounds check when merging Extended Supported Rates to prevent a second potential overflow. This prevents kernel stack corruption triggered by malformed association requests. CVE-2025-68255 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68255.html CVE-2025-68255 https://bugzilla.suse.com/1255395 SUSE Bug 1255395 In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser The Information Element (IE) parser rtw_get_ie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop. Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element. This prevents OOB reads and ensures the parser terminates safely on malformed frames. CVE-2025-68256 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68256.html CVE-2025-68256 https://bugzilla.suse.com/1255138 SUSE Bug 1255138 In the Linux kernel, the following vulnerability has been resolved: comedi: check device's attached status in compat ioctls Syzbot identified an issue [1] that crashes kernel, seemingly due to unexistent callback dev->get_valid_routes(). By all means, this should not occur as said callback must always be set to get_zero_valid_routes() in __comedi_device_postconfig(). As the crash seems to appear exclusively in i386 kernels, at least, judging from [1] reports, the blame lies with compat versions of standard IOCTL handlers. Several of them are modified and do not use comedi_unlocked_ioctl(). While functionality of these ioctls essentially copy their original versions, they do not have required sanity check for device's attached status. This, in turn, leads to a possibility of calling select IOCTLs on a device that has not been properly setup, even via COMEDI_DEVCONFIG. Doing so on unconfigured devices means that several crucial steps are missed, for instance, specifying dev->get_valid_routes() callback. Fix this somewhat crudely by ensuring device's attached status before performing any ioctls, improving logic consistency between modern and compat functions. [1] Syzbot report: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0 Call Trace: <TASK> get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline] parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401 do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594 compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline] comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273 __do_compat_sys_ioctl fs/ioctl.c:695 [inline] __se_compat_sys_ioctl fs/ioctl.c:638 [inline] __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] ... CVE-2025-68257 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68257.html CVE-2025-68257 https://bugzilla.suse.com/1255167 SUSE Bug 1255167 In the Linux kernel, the following vulnerability has been resolved: comedi: multiq3: sanitize config options in multiq3_attach() Syzbot identified an issue [1] in multiq3_attach() that induces a task timeout due to open() or COMEDI_DEVCONFIG ioctl operations, specifically, in the case of multiq3 driver. This problem arose when syzkaller managed to craft weird configuration options used to specify the number of channels in encoder subdevice. If a particularly great number is passed to s->n_chan in multiq3_attach() via it->options[2], then multiple calls to multiq3_encoder_reset() at the end of driver-specific attach() method will be running for minutes, thus blocking tasks and affected devices as well. While this issue is most likely not too dangerous for real-life devices, it still makes sense to sanitize configuration inputs. Enable a sensible limit on the number of encoder chips (4 chips max, each with 2 channels) to stop this behaviour from manifesting. [1] Syzbot crash: INFO: task syz.2.19:6067 blocked for more than 143 seconds. ... Call Trace: <TASK> context_switch kernel/sched/core.c:5254 [inline] __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 __schedule_loop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016 __mutex_lock_common kernel/locking/mutex.c:676 [inline] __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414 do_dentry_open+0x953/0x13f0 fs/open.c:965 vfs_open+0x3b/0x340 fs/open.c:1097 ... CVE-2025-68258 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68258.html CVE-2025-68258 https://bugzilla.suse.com/1255182 SUSE Bug 1255182 In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn instruction, discard the exception and retry the instruction if the code stream is changed (e.g. by a different vCPU) between when the CPU executes the instruction and when KVM decodes the instruction to get the next RIP. As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction"), failure to verify that the correct INTn instruction was decoded can effectively clobber guest state due to decoding the wrong instruction and thus specifying the wrong next RIP. The bug most often manifests as "Oops: int3" panics on static branch checks in Linux guests. Enabling or disabling a static branch in Linux uses the kernel's "text poke" code patching mechanism. To modify code while other CPUs may be executing that code, Linux (temporarily) replaces the first byte of the original instruction with an int3 (opcode 0xcc), then patches in the new code stream except for the first byte, and finally replaces the int3 with the first byte of the new code stream. If a CPU hits the int3, i.e. executes the code while it's being modified, then the guest kernel must look up the RIP to determine how to handle the #BP, e.g. by emulating the new instruction. If the RIP is incorrect, then this lookup fails and the guest kernel panics. The bug reproduces almost instantly by hacking the guest kernel to repeatedly check a static branch[1] while running a drgn script[2] on the host to constantly swap out the memory containing the guest's TSS. [1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a [2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b CVE-2025-68259 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68259.html CVE-2025-68259 https://bugzilla.suse.com/1255199 SUSE Bug 1255199 In the Linux kernel, the following vulnerability has been resolved: rust_binder: fix race condition on death_list Rust Binder contains the following unsafe operation: // SAFETY: A `NodeDeath` is never inserted into the death list // of any node other than its owner, so it is either in this // death list or in no death list. unsafe { node_inner.death_list.remove(self) }; This operation is unsafe because when touching the prev/next pointers of a list element, we have to ensure that no other thread is also touching them in parallel. If the node is present in the list that `remove` is called on, then that is fine because we have exclusive access to that list. If the node is not in any list, then it's also ok. But if it's present in a different list that may be accessed in parallel, then that may be a data race on the prev/next pointers. And unfortunately that is exactly what is happening here. In Node::release, we: 1. Take the lock. 2. Move all items to a local list on the stack. 3. Drop the lock. 4. Iterate the local list on the stack. Combined with threads using the unsafe remove method on the original list, this leads to memory corruption of the prev/next pointers. This leads to crashes like this one: Unable to handle kernel paging request at virtual address 000bb9841bcac70e Mem abort info: ESR = 0x0000000096000044 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [000bb9841bcac70e] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP google-cdd 538c004.gcdd: context saved(CPU:1) item - log_kevents is disabled Modules linked in: ... rust_binder CPU: 1 UID: 0 PID: 2092 Comm: kworker/1:178 Tainted: G S W OE 6.12.52-android16-5-g98debd5df505-4k #1 f94a6367396c5488d635708e43ee0c888d230b0b Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: MUSTANG PVT 1.0 based on LGA (DT) Workqueue: events _RNvXs6_NtCsdfZWD8DztAw_6kernel9workqueueINtNtNtB7_4sync3arc3ArcNtNtCs8QPsHWIn21X_16rust_binder_main7process7ProcessEINtB5_15WorkItemPointerKy0_E3runB13_ [rust_binder] pstate: 23400005 (nzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x450/0x11f8 [rust_binder] lr : _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x464/0x11f8 [rust_binder] sp : ffffffc09b433ac0 x29: ffffffc09b433d30 x28: ffffff8821690000 x27: ffffffd40cbaa448 x26: ffffff8821690000 x25: 00000000ffffffff x24: ffffff88d0376578 x23: 0000000000000001 x22: ffffffc09b433c78 x21: ffffff88e8f9bf40 x20: ffffff88e8f9bf40 x19: ffffff882692b000 x18: ffffffd40f10bf00 x17: 00000000c006287d x16: 00000000c006287d x15: 00000000000003b0 x14: 0000000000000100 x13: 000000201cb79ae0 x12: fffffffffffffff0 x11: 0000000000000000 x10: 0000000000000001 x9 : 0000000000000000 x8 : b80bb9841bcac706 x7 : 0000000000000001 x6 : fffffffebee63f30 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000004c31 x1 : ffffff88216900c0 x0 : ffffff88e8f9bf00 Call trace: _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x450/0x11f8 [rust_binder bbc172b53665bbc815363b22e97e3f7e3fe971fc] process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1c8 ret_from_fork+0x10/0x20 Code: 94218d85 b4000155 a94026a8 d10102a0 (f9000509) ---[ end trace 0000000000000000 ]--- Thus, modify Node::release to pop items directly off the original list. CVE-2025-68260 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68260.html CVE-2025-68260 https://bugzilla.suse.com/1255177 SUSE Bug 1255177 In the Linux kernel, the following vulnerability has been resolved: ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock() Fix a race between inline data destruction and block mapping. The function ext4_destroy_inline_data_nolock() changes the inode data layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS. At the same time, another thread may execute ext4_map_blocks(), which tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks() or ext4_ind_map_blocks(). Without i_data_sem protection, ext4_ind_map_blocks() may receive inode with EXT4_INODE_EXTENTS flag and triggering assert. kernel BUG at fs/ext4/indirect.c:546! EXT4-fs (loop2): unmounting filesystem. invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546 Call Trace: <TASK> ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 CVE-2025-68261 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68261.html CVE-2025-68261 https://bugzilla.suse.com/1255164 SUSE Bug 1255164 In the Linux kernel, the following vulnerability has been resolved: crypto: zstd - fix double-free in per-CPU stream cleanup The crypto/zstd module has a double-free bug that occurs when multiple tfms are allocated and freed. The issue happens because zstd_streams (per-CPU contexts) are freed in zstd_exit() during every tfm destruction, rather than being managed at the module level. When multiple tfms exist, each tfm exit attempts to free the same shared per-CPU streams, resulting in a double-free. This leads to a stack trace similar to: BUG: Bad page state in process kworker/u16:1 pfn:106fd93 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x106fd93 flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: nonzero entire_mapcount Modules linked in: ... CPU: 3 UID: 0 PID: 2506 Comm: kworker/u16:1 Kdump: loaded Tainted: G B Hardware name: ... Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 bad_page+0x71/0xd0 free_unref_page_prepare+0x24e/0x490 free_unref_page+0x60/0x170 crypto_acomp_free_streams+0x5d/0xc0 crypto_acomp_exit_tfm+0x23/0x50 crypto_destroy_tfm+0x60/0xc0 ... Change the lifecycle management of zstd_streams to free the streams only once during module cleanup. CVE-2025-68262 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68262.html CVE-2025-68262 https://bugzilla.suse.com/1255158 SUSE Bug 1255158 In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. The generic netlink handler (handle_generic_event()/handle_response()) fills entry->response under ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free entry->response without holding the same lock. Under high concurrency this allows a race where handle_response() is copying data into entry->response while ipc_msg_send_request() has just freed it, leading to a slab-use-after-free reported by KASAN in handle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd] Fix by: - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table. - Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock. - Returning NULL in the error path, preserving the original API semantics. This makes all accesses to entry->response consistent with handle_response(), which already updates and fills the response buffer under ipc_msg_table_lock, and closes the race that allowed the UAF. CVE-2025-68263 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68263.html CVE-2025-68263 https://bugzilla.suse.com/1255384 SUSE Bug 1255384 In the Linux kernel, the following vulnerability has been resolved: ext4: refresh inline data size before write operations The cached ei->i_inline_size can become stale between the initial size check and when ext4_update_inline_data()/ext4_create_inline_data() use it. Although ext4_get_max_inline_size() reads the correct value at the time of the check, concurrent xattr operations can modify i_inline_size before ext4_write_lock_xattr() is acquired. This causes ext4_update_inline_data() and ext4_create_inline_data() to work with stale capacity values, leading to a BUG_ON() crash in ext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); The race window: 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, i_inline_size changes to 40] 4. ext4_write_lock_xattr() acquires lock 5. ext4_update_inline_data() uses stale i_inline_size = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock() immediately after acquiring xattr_sem. This ensures ext4_update_inline_data() and ext4_create_inline_data() work with current values that are protected from concurrent modifications. This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inline_data file while its xattrs are changing") which fixed i_inline_off staleness. This patch addresses the related i_inline_size staleness issue. CVE-2025-68264 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68264.html CVE-2025-68264 https://bugzilla.suse.com/1255380 SUSE Bug 1255380 In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated--- CVE-2025-68323 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68323.html CVE-2025-68323 https://bugzilla.suse.com/1255405 SUSE Bug 1255405 In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated. CVE-2025-68324 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68324.html CVE-2025-68324 https://bugzilla.suse.com/1255416 SUSE Bug 1255416 https://bugzilla.suse.com/1257117 SUSE Bug 1257117 In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged. CVE-2025-68325 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68325.html CVE-2025-68325 https://bugzilla.suse.com/1255417 SUSE Bug 1255417 In the Linux kernel, the following vulnerability has been resolved: comedi: c6xdigio: Fix invalid PNP driver unregistration The Comedi low-level driver "c6xdigio" seems to be for a parallel port connected device. When the Comedi core calls the driver's Comedi "attach" handler `c6xdigio_attach()` to configure a Comedi to use this driver, it tries to enable the parallel port PNP resources by registering a PNP driver with `pnp_register_driver()`, but ignores the return value. (The `struct pnp_driver` it uses has only the `name` and `id_table` members filled in.) The driver's Comedi "detach" handler `c6xdigio_detach()` unconditionally unregisters the PNP driver with `pnp_unregister_driver()`. It is possible for `c6xdigio_attach()` to return an error before it calls `pnp_register_driver()` and it is possible for the call to `pnp_register_driver()` to return an error (that is ignored). In both cases, the driver should not be calling `pnp_unregister_driver()` as it does in `c6xdigio_detach()`. (Note that `c6xdigio_detach()` will be called by the Comedi core if `c6xdigio_attach()` returns an error, or if the Comedi core decides to detach the Comedi device from the driver for some other reason.) The unconditional call to `pnp_unregister_driver()` without a previous successful call to `pnp_register_driver()` will cause `driver_unregister()` to issue a warning "Unexpected driver unregister!". This was detected by Syzbot [1]. Also, the PNP driver registration and unregistration should be done at module init and exit time, respectively, not when attaching or detaching Comedi devices to the driver. (There might be more than one Comedi device being attached to the driver, although that is unlikely.) Change the driver to do the PNP driver registration at module init time, and the unregistration at module exit time. Since `c6xdigio_detach()` now only calls `comedi_legacy_detach()`, remove the function and change the Comedi driver "detach" handler to `comedi_legacy_detach`. ------------------------------------------- [1] Syzbot sample crash report: Unexpected driver unregister! WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister drivers/base/driver.c:273 [inline] WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister+0x90/0xb0 drivers/base/driver.c:270 Modules linked in: CPU: 0 UID: 0 PID: 5970 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 RIP: 0010:driver_unregister drivers/base/driver.c:273 [inline] RIP: 0010:driver_unregister+0x90/0xb0 drivers/base/driver.c:270 Code: 48 89 ef e8 c2 e6 82 fc 48 89 df e8 3a 93 ff ff 5b 5d e9 c3 6d d9 fb e8 be 6d d9 fb 90 48 c7 c7 e0 f8 1f 8c e8 51 a2 97 fb 90 <0f> 0b 90 90 5b 5d e9 a5 6d d9 fb e8 e0 f4 41 fc eb 94 e8 d9 f4 41 RSP: 0018:ffffc9000373f9a0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff8ff24720 RCX: ffffffff817b6ee8 RDX: ffff88807c932480 RSI: ffffffff817b6ef5 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8ff24660 R13: dffffc0000000000 R14: 0000000000000000 R15: ffff88814cca0000 FS: 000055556dab1500(0000) GS:ffff8881249d9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f77f285cd0 CR3: 000000007d871000 CR4: 00000000003526f0 Call Trace: <TASK> comedi_device_detach_locked+0x12f/0xa50 drivers/comedi/drivers.c:207 comedi_device_detach+0x67/0xb0 drivers/comedi/drivers.c:215 comedi_device_attach+0x43d/0x900 drivers/comedi/drivers.c:1011 do_devconfig_ioctl+0x1b1/0x710 drivers/comedi/comedi_fops.c:872 comedi_unlocked_ioctl+0x165d/0x2f00 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_sys ---truncated--- CVE-2025-68332 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68332.html CVE-2025-68332 https://bugzilla.suse.com/1255483 SUSE Bug 1255483 In the Linux kernel, the following vulnerability has been resolved: comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel() Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems from the fact that in case of early device detach via pcl818_detach(), subdevice dev->read_subdev may not have initialized its pointer to &struct comedi_async as intended. Thus, any such dereferencing of &s->async->cmd will lead to general protection fault and kernel crash. Mitigate this problem by removing a call to pcl818_ai_cancel() from pcl818_detach() altogether. This way, if the subdevice setups its support for async commands, everything async-related will be handled via subdevice's own ->cancel() function in comedi_device_detach_locked() even before pcl818_detach(). If no support for asynchronous commands is provided, there is no need to cancel anything either. [1] Syzbot crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762 ... Call Trace: <TASK> pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115 comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207 do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline] comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] ... CVE-2025-68335 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68335.html CVE-2025-68335 https://bugzilla.suse.com/1255480 SUSE Bug 1255480 In the Linux kernel, the following vulnerability has been resolved: locking/spinlock/debug: Fix data-race in do_raw_write_lock KCSAN reports: BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lock write (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_fork read to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_fork value changed: 0xffffffff -> 0x00000001 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111 Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") has adressed most of these races, but seems to be not consistent/not complete. >From do_raw_write_lock() only debug_write_lock_after() part has been converted to WRITE_ONCE(), but not debug_write_lock_before() part. Do it now. CVE-2025-68336 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68336.html CVE-2025-68336 https://bugzilla.suse.com/1255481 SUSE Bug 1255481 In the Linux kernel, the following vulnerability has been resolved: jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted There's issue when file system corrupted: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1289! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0 RSP: 0018:ffff888117aafa30 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534 RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010 RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028 R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0 Call Trace: <TASK> __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The above issue occurs with us in errors=continue mode when accompanied by storage failures. There have been many inconsistencies in the file system data. In the case of file system data inconsistency, for example, if the block bitmap of a referenced block is not set, it can lead to the situation where a block being committed is allocated and used again. As a result, the following condition will not be satisfied then trigger BUG_ON. Of course, it is entirely possible to construct a problematic image that can trigger this BUG_ON through specific operations. In fact, I have constructed such an image and easily reproduced this issue. Therefore, J_ASSERT() holds true only under ideal conditions, but it may not necessarily be satisfied in exceptional scenarios. Using J_ASSERT() directly in abnormal situations would cause the system to crash, which is clearly not what we want. So here we directly trigger a JBD abort instead of immediately invoking BUG_ON. CVE-2025-68337 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68337.html CVE-2025-68337 https://bugzilla.suse.com/1255482 SUSE Bug 1255482 In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow. CVE-2025-68344 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68344.html CVE-2025-68344 https://bugzilla.suse.com/1255816 SUSE Bug 1255816 In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-68345 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68345.html CVE-2025-68345 https://bugzilla.suse.com/1255601 SUSE Bug 1255601 In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats(). CVE-2025-68346 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68346.html CVE-2025-68346 https://bugzilla.suse.com/1255603 SUSE Bug 1255603 In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested. CVE-2025-68347 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68347.html CVE-2025-68347 https://bugzilla.suse.com/1255706 SUSE Bug 1255706 In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation. CVE-2025-68348 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68348.html CVE-2025-68348 https://bugzilla.suse.com/1255694 SUSE Bug 1255694 In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout. CVE-2025-68349 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68349.html CVE-2025-68349 https://bugzilla.suse.com/1255544 SUSE Bug 1255544 In the Linux kernel, the following vulnerability has been resolved: exfat: fix divide-by-zero in exfat_allocate_bitmap The variable max_ra_count can be 0 in exfat_allocate_bitmap(), which causes a divide-by-zero error in the subsequent modulo operation (i % max_ra_count), leading to a system crash. When max_ra_count is 0, it means that readahead is not used. This patch load the bitmap without readahead. CVE-2025-68350 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68350.html CVE-2025-68350 https://bugzilla.suse.com/1255625 SUSE Bug 1255625 In the Linux kernel, the following vulnerability has been resolved: exfat: fix refcount leak in exfat_find Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`. Function `exfat_get_dentry_set` would increase the reference counter of `es->bh` on success. Therefore, `exfat_put_dentry_set` must be called after `exfat_get_dentry_set` to ensure refcount consistency. This patch relocate two checks to avoid possible leaks. CVE-2025-68351 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68351.html CVE-2025-68351 https://bugzilla.suse.com/1255567 SUSE Bug 1255567 In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes. CVE-2025-68352 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68352.html CVE-2025-68352 https://bugzilla.suse.com/1255541 SUSE Bug 1255541 In the Linux kernel, the following vulnerability has been resolved: net: vxlan: prevent NULL deref in vxlan_xmit_one Neither sock4 nor sock6 pointers are guaranteed to be non-NULL in vxlan_xmit_one, e.g. if the iface is brought down. This can lead to the following NULL dereference: BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:vxlan_xmit_one+0xbb3/0x1580 Call Trace: vxlan_xmit+0x429/0x610 dev_hard_start_xmit+0x55/0xa0 __dev_queue_xmit+0x6d0/0x7f0 ip_finish_output2+0x24b/0x590 ip_output+0x63/0x110 Mentioned commits changed the code path in vxlan_xmit_one and as a side effect the sock4/6 pointer validity checks in vxlan(6)_get_route were lost. Fix this by adding back checks. Since both commits being fixed were released in the same version (v6.7) and are strongly related, bundle the fixes in a single commit. CVE-2025-68353 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68353.html CVE-2025-68353 https://bugzilla.suse.com/1255533 SUSE Bug 1255533 In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex. CVE-2025-68354 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68354.html CVE-2025-68354 https://bugzilla.suse.com/1255553 SUSE Bug 1255553 In the Linux kernel, the following vulnerability has been resolved: bpf: Fix exclusive map memory leak When excl_prog_hash is 0 and excl_prog_hash_size is non-zero, the map also needs to be freed. Otherwise, the map memory will not be reclaimed, just like the memory leak problem reported by syzbot [1]. syzbot reported: BUG: memory leak backtrace (crc 7b9fb9b4): map_create+0x322/0x11e0 kernel/bpf/syscall.c:1512 __sys_bpf+0x3556/0x3610 kernel/bpf/syscall.c:6131 CVE-2025-68355 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68355.html CVE-2025-68355 https://bugzilla.suse.com/1255599 SUSE Bug 1255599 In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The "meta" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation"). Fixes xfstest generic/273. CVE-2025-68356 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68356.html CVE-2025-68356 https://bugzilla.suse.com/1255593 SUSE Bug 1255593 In the Linux kernel, the following vulnerability has been resolved: iomap: allocate s_dio_done_wq for async reads as well Since commit 222f2c7c6d14 ("iomap: always run error completions in user context"), read error completions are deferred to s_dio_done_wq. This means the workqueue also needs to be allocated for async reads. CVE-2025-68357 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68357.html CVE-2025-68357 https://bugzilla.suse.com/1255525 SUSE Bug 1255525 In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated--- CVE-2025-68358 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68358.html CVE-2025-68358 https://bugzilla.suse.com/1255531 SUSE Bug 1255531 In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object. CVE-2025-68359 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68359.html CVE-2025-68359 https://bugzilla.suse.com/1255542 SUSE Bug 1255542 In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks. CVE-2025-68360 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68360.html CVE-2025-68360 https://bugzilla.suse.com/1255536 SUSE Bug 1255536 In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself). CVE-2025-68361 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68361.html CVE-2025-68361 https://bugzilla.suse.com/1255526 SUSE Bug 1255526 In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails. CVE-2025-68362 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68362.html CVE-2025-68362 https://bugzilla.suse.com/1255611 SUSE Bug 1255611 In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next. CVE-2025-68363 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68363.html CVE-2025-68363 https://bugzilla.suse.com/1255552 SUSE Bug 1255552 In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption. CVE-2025-68364 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68364.html CVE-2025-68364 https://bugzilla.suse.com/1255556 SUSE Bug 1255556 In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use. CVE-2025-68365 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68365.html CVE-2025-68365 https://bugzilla.suse.com/1255548 SUSE Bug 1255548 In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk("before sleep\n"); + mdelay(5 * 1000); + printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); } CVE-2025-68366 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68366.html CVE-2025-68366 https://bugzilla.suse.com/1255622 SUSE Bug 1255622 In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region. CVE-2025-68367 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68367.html CVE-2025-68367 https://bugzilla.suse.com/1255547 SUSE Bug 1255547 In the Linux kernel, the following vulnerability has been resolved: md: init bioset in mddev_init IO operations may be needed before md_run(), such as updating metadata after writing sysfs. Without bioset, this triggers a NULL pointer dereference as below: BUG: kernel NULL pointer dereference, address: 0000000000000020 Call Trace: md_update_sb+0x658/0xe00 new_level_store+0xc5/0x120 md_attr_store+0xc9/0x1e0 sysfs_kf_write+0x6f/0xa0 kernfs_fop_write_iter+0x141/0x2a0 vfs_write+0x1fc/0x5a0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x2818/0x2880 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Reproducer ``` mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd] echo inactive > /sys/block/md0/md/array_state echo 10 > /sys/block/md0/md/new_level ``` mddev_init() can only be called once per mddev, no need to test if bioset has been initialized anymore. CVE-2025-68368 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68368.html CVE-2025-68368 https://bugzilla.suse.com/1255527 SUSE Bug 1255527 In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808 CVE-2025-68369 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68369.html CVE-2025-68369 https://bugzilla.suse.com/1255535 SUSE Bug 1255535 In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight] CVE-2025-68370 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68370.html CVE-2025-68370 https://bugzilla.suse.com/1255534 SUSE Bug 1255534 In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets. CVE-2025-68371 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68371.html CVE-2025-68371 https://bugzilla.suse.com/1255572 SUSE Bug 1255572 In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the waiter") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put") CVE-2025-68372 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68372.html CVE-2025-68372 https://bugzilla.suse.com/1255537 SUSE Bug 1255537 In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: <TASK> __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition. CVE-2025-68373 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68373.html CVE-2025-68373 https://bugzilla.suse.com/1255610 SUSE Bug 1255610 In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free. CVE-2025-68374 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68374.html CVE-2025-68374 https://bugzilla.suse.com/1255530 SUSE Bug 1255530 In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[]. CVE-2025-68375 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68375.html CVE-2025-68375 https://bugzilla.suse.com/1255575 SUSE Bug 1255575 In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it. CVE-2025-68376 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68376.html CVE-2025-68376 https://bugzilla.suse.com/1255529 SUSE Bug 1255529 In the Linux kernel, the following vulnerability has been resolved: ns: initialize ns_list_node for initial namespaces Make sure that the list is always initialized for initial namespaces. CVE-2025-68377 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68377.html CVE-2025-68377 https://bugzilla.suse.com/1255592 SUSE Bug 1255592 In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array. CVE-2025-68378 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68378.html CVE-2025-68378 https://bugzilla.suse.com/1255614 SUSE Bug 1255614 In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: <TASK> rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e CVE-2025-68379 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68379.html CVE-2025-68379 https://bugzilla.suse.com/1255695 SUSE Bug 1255695 In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. Ext Tag: HE Capabilities [...] Supported HE-MCS and NSS Set [...] Rx and Tx MCS Maps 160 MHz [...] Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 CVE-2025-68380 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68380.html CVE-2025-68380 https://bugzilla.suse.com/1255580 SUSE Bug 1255580 In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc. CVE-2025-68724 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68724.html CVE-2025-68724 https://bugzilla.suse.com/1255550 SUSE Bug 1255550 In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there. CVE-2025-68725 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68725.html CVE-2025-68725 https://bugzilla.suse.com/1255569 SUSE Bug 1255569 In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b CVE-2025-68726 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68726.html CVE-2025-68726 https://bugzilla.suse.com/1255598 SUSE Bug 1255598 In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN. CVE-2025-68727 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68727.html CVE-2025-68727 https://bugzilla.suse.com/1255568 SUSE Bug 1255568 In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it's not already, by overwriting it. CVE-2025-68728 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68728.html CVE-2025-68728 https://bugzilla.suse.com/1255539 SUSE Bug 1255539 In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 CVE-2025-68729 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68729.html CVE-2025-68729 https://bugzilla.suse.com/1255692 SUSE Bug 1255692 In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list. CVE-2025-68730 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68730.html CVE-2025-68730 https://bugzilla.suse.com/1255602 SUSE Bug 1255602 In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix an integer overflow in aie2_query_ctx_status_array() The unpublished smatch static checker reported a warning. drivers/accel/amdxdna/aie2_pci.c:904 aie2_query_ctx_status_array() warn: potential user controlled sizeof overflow 'args->num_element * args->element_size' '1-u32max(user) * 1-u32max(user)' Even this will not cause a real issue, it is better to put a reasonable limitation for element_size and num_element. Add condition to make sure the input element_size <= 4K and num_element <= 1K. CVE-2025-68731 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68731.html CVE-2025-68731 https://bugzilla.suse.com/1255696 SUSE Bug 1255696 In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically. CVE-2025-68732 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68732.html CVE-2025-68732 https://bugzilla.suse.com/1255688 SUSE Bug 1255688 https://bugzilla.suse.com/1255689 SUSE Bug 1255689 In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking "relabel-self" list. This change ensures that the "relabel-self" list is checked before importing the label. CVE-2025-68733 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68733.html CVE-2025-68733 https://bugzilla.suse.com/1255615 SUSE Bug 1255615 In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags CVE-2025-68735 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68735.html CVE-2025-68735 https://bugzilla.suse.com/1255811 SUSE Bug 1255811 https://bugzilla.suse.com/1256251 SUSE Bug 1256251 In the Linux kernel, the following vulnerability has been resolved: landlock: Fix handling of disconnected directories Disconnected files or directories can appear when they are visible and opened from a bind mount, but have been renamed or moved from the source of the bind mount in a way that makes them inaccessible from the mount point (i.e. out of scope). Previously, access rights tied to files or directories opened through a disconnected directory were collected by walking the related hierarchy down to the root of the filesystem, without taking into account the mount point because it couldn't be found. This could lead to inconsistent access results, potential access right widening, and hard-to-debug renames, especially since such paths cannot be printed. For a sandboxed task to create a disconnected directory, it needs to have write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) to the underlying source of the bind mount, and read access to the related mount point. Because a sandboxed task cannot acquire more access rights than those defined by its Landlock domain, this could lead to inconsistent access rights due to missing permissions that should be inherited from the mount point hierarchy, while inheriting permissions from the filesystem hierarchy hidden by this mount point instead. Landlock now handles files and directories opened from disconnected directories by taking into account the filesystem hierarchy when the mount point is not found in the hierarchy walk, and also always taking into account the mount point from which these disconnected directories were opened. This ensures that a rename is not allowed if it would widen access rights [1]. The rationale is that, even if disconnected hierarchies might not be visible or accessible to a sandboxed task, relying on the collected access rights from them improves the guarantee that access rights will not be widened during a rename because of the access right comparison between the source and the destination (see LANDLOCK_ACCESS_FS_REFER). It may look like this would grant more access on disconnected files and directories, but the security policies are always enforced for all the evaluated hierarchies. This new behavior should be less surprising to users and safer from an access control perspective. Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() and fix the related comment. Because opened files have their access rights stored in the related file security properties, there is no impact for disconnected or unlinked files. CVE-2025-68736 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68736.html CVE-2025-68736 https://bugzilla.suse.com/1255698 SUSE Bug 1255698 In the Linux kernel, the following vulnerability has been resolved: arm64/pageattr: Propagate return value from __change_memory_common The rodata=on security measure requires that any code path which does vmalloc -> set_memory_ro/set_memory_rox must protect the linear map alias too. Therefore, if such a call fails, we must abort set_memory_* and caller must take appropriate action; currently we are suppressing the error, and there is a real chance of such an error arising post commit a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full"). Therefore, propagate any error to the caller. CVE-2025-68737 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68737.html CVE-2025-68737 https://bugzilla.suse.com/1255699 SUSE Bug 1255699 In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link. CVE-2025-68738 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68738.html CVE-2025-68738 https://bugzilla.suse.com/1255700 SUSE Bug 1255700 In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order. CVE-2025-68739 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68739.html CVE-2025-68739 https://bugzilla.suse.com/1255701 SUSE Bug 1255701 In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match. CVE-2025-68740 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68740.html CVE-2025-68740 https://bugzilla.suse.com/1255812 SUSE Bug 1255812 In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items. CVE-2025-68741 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68741.html CVE-2025-68741 https://bugzilla.suse.com/1255703 SUSE Bug 1255703 In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL. CVE-2025-68742 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68742.html CVE-2025-68742 https://bugzilla.suse.com/1255707 SUSE Bug 1255707 In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used. CVE-2025-68743 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68743.html CVE-2025-68743 https://bugzilla.suse.com/1255708 SUSE Bug 1255708 In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'. CVE-2025-68744 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68744.html CVE-2025-68744 https://bugzilla.suse.com/1255709 SUSE Bug 1255709 In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clear cmds after chip reset Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems: 1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore. 2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs(). So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at __qla2x00_abort_all_cmds. CVE-2025-68745 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68745.html CVE-2025-68745 https://bugzilla.suse.com/1255721 SUSE Bug 1255721 In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer. CVE-2025-68746 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68746.html CVE-2025-68746 https://bugzilla.suse.com/1255722 SUSE Bug 1255722 In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree. CVE-2025-68747 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68747.html CVE-2025-68747 https://bugzilla.suse.com/1255723 SUSE Bug 1255723 https://bugzilla.suse.com/1257628 SUSE Bug 1257628 In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work(). CVE-2025-68748 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68748.html CVE-2025-68748 https://bugzilla.suse.com/1255813 SUSE Bug 1255813 In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind(). CVE-2025-68749 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68749.html CVE-2025-68749 https://bugzilla.suse.com/1255724 SUSE Bug 1255724 In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated--- CVE-2025-68751 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68751.html CVE-2025-68751 https://bugzilla.suse.com/1255945 SUSE Bug 1255945 In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 ("gve: Implement settime64 with -EOPNOTSUPP"). CVE-2025-68752 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68752.html CVE-2025-68752 https://bugzilla.suse.com/1256237 SUSE Bug 1256237 In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user(). CVE-2025-68753 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68753.html CVE-2025-68753 https://bugzilla.suse.com/1256238 SUSE Bug 1256238 In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle. CVE-2025-68754 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68754.html CVE-2025-68754 https://bugzilla.suse.com/1256240 SUSE Bug 1256240 In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e ("staging: most: remove device from interface structure") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it. CVE-2025-68755 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68755.html CVE-2025-68755 https://bugzilla.suse.com/1255940 SUSE Bug 1255940 In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period. CVE-2025-68756 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68756.html CVE-2025-68756 https://bugzilla.suse.com/1255942 SUSE Bug 1255942 In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [<ffffffff8289db71>] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [<ffffffff82882021>] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [<ffffffff8289fd00>] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [<ffffffff813d4ddf>] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] <Interrupt> [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] <IRQ> [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated--- CVE-2025-68757 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68757.html CVE-2025-68757 https://bugzilla.suse.com/1255943 SUSE Bug 1255943 In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = "nxp,pca9632"; reg = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well. CVE-2025-68758 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68758.html CVE-2025-68758 https://bugzilla.suse.com/1255944 SUSE Bug 1255944 In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free. CVE-2025-68759 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68759.html CVE-2025-68759 https://bugzilla.suse.com/1255934 SUSE Bug 1255934 In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation. CVE-2025-68760 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68760.html CVE-2025-68760 https://bugzilla.suse.com/1255935 SUSE Bug 1255935 In the Linux kernel, the following vulnerability has been resolved: hfs: fix potential use after free in hfs_correct_next_unused_CNID() This code calls hfs_bnode_put(node) which drops the refcount and then dreferences "node" on the next line. It's only safe to use "node" when we're holding a reference so flip these two lines around. CVE-2025-68761 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68761.html CVE-2025-68761 https://bugzilla.suse.com/1255936 SUSE Bug 1255936 In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails. CVE-2025-68762 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68762.html CVE-2025-68762 https://bugzilla.suse.com/1255937 SUSE Bug 1255937 In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows. CVE-2025-68763 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68763.html CVE-2025-68763 https://bugzilla.suse.com/1255929 SUSE Bug 1255929 In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag. CVE-2025-68764 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68764.html CVE-2025-68764 https://bugzilla.suse.com/1255930 SUSE Bug 1255930 In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released. CVE-2025-68765 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68765.html CVE-2025-68765 https://bugzilla.suse.com/1255931 SUSE Bug 1255931 In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets "hwirq" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success. CVE-2025-68766 openSUSE Tumbleweed:kernel-devel-longterm-6.18.16-1.1 openSUSE Tumbleweed:kernel-source-longterm-6.18.16-1.1 moderate To install this SUSE Security Update use the SUSE recommended installation methods like YaST online_update or "zypper patch". https://www.suse.com/security/cve/CVE-2025-68766.html CVE-2025-68766 https://bugzilla.suse.com/1255932 SUSE Bug 1255932