{"cves":[{"cve_id":"CVE-2026-5286","summary":"Use after free in Dawn in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22593,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/493900619"],"published_time":"2026-04-01T05:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5287","summary":"Use after free in PDF in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted PDF file. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22593,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/494644471"],"published_time":"2026-04-01T05:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5288","summary":"Use after free in WebView in Google Chrome on Android prior to 146.0.7680.178 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":9.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.6,"epss":0.00058,"ranking_epss":0.18378,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/495507390"],"published_time":"2026-04-01T05:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5289","summary":"Use after free in Navigation in Google Chrome prior to 146.0.7680.178 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":9.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.6,"epss":0.00063,"ranking_epss":0.19778,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/495931147"],"published_time":"2026-04-01T05:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5290","summary":"Use after free in Compositing in Google Chrome prior to 146.0.7680.178 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":9.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.6,"epss":0.00063,"ranking_epss":0.19778,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/496205576"],"published_time":"2026-04-01T05:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5291","summary":"Inappropriate implementation in WebGL in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00024,"ranking_epss":0.06343,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/490118036"],"published_time":"2026-04-01T05:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5292","summary":"Out of bounds read in WebCodecs in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00058,"ranking_epss":0.18378,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/492213293"],"published_time":"2026-04-01T05:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5278","summary":"Use after free in Web MIDI in Google Chrome on Android prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00066,"ranking_epss":0.20555,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/490254128"],"published_time":"2026-04-01T05:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5279","summary":"Object corruption in V8 in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22593,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/490642836"],"published_time":"2026-04-01T05:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5280","summary":"Use after free in WebCodecs in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00066,"ranking_epss":0.20555,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/491515787"],"published_time":"2026-04-01T05:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5281","summary":"Use after free in Dawn in Google Chrome prior to 146.0.7680.178 allowed a remote attacker who had compromised the renderer process to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.03034,"ranking_epss":0.86631,"kev":true,"propose_action":"Google Dawn contains an use-after-free vulnerability that could allow a remote attacker who had compromised the renderer process to execute arbitrary code via a crafted HTML page. This vulnerability could affect multiple Chromium-based products including, but not limited to, Google Chrome, Microsoft Edge, and Opera.","ransomware_campaign":"Unknown","references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/491518608","https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-5281"],"published_time":"2026-04-01T05:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5282","summary":"Out of bounds read in WebCodecs in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.00058,"ranking_epss":0.18378,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/491655161"],"published_time":"2026-04-01T05:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5283","summary":"Inappropriate implementation in ANGLE in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00013,"ranking_epss":0.02079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/492131521"],"published_time":"2026-04-01T05:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5284","summary":"Use after free in Dawn in Google Chrome prior to 146.0.7680.178 allowed a remote attacker who had compromised the renderer process to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00074,"ranking_epss":0.22593,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/492139412"],"published_time":"2026-04-01T05:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5285","summary":"Use after free in WebGL in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00066,"ranking_epss":0.20555,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/492228019"],"published_time":"2026-04-01T05:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5272","summary":"Heap buffer overflow in GPU in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00023,"ranking_epss":0.06124,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/491732188"],"published_time":"2026-04-01T05:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5273","summary":"Use after free in CSS in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":6.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.3,"epss":0.0006,"ranking_epss":0.18975,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/493952652"],"published_time":"2026-04-01T05:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5274","summary":"Integer overflow in Codecs in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00063,"ranking_epss":0.19778,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/488596746"],"published_time":"2026-04-01T05:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5275","summary":"Heap buffer overflow in ANGLE in Google Chrome on Mac prior to 146.0.7680.178 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00066,"ranking_epss":0.20714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/489494022"],"published_time":"2026-04-01T05:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5276","summary":"Insufficient policy enforcement in WebUSB in Google Chrome prior to 146.0.7680.178 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: High)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00042,"ranking_epss":0.12779,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/489711638"],"published_time":"2026-04-01T05:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-5277","summary":"Integer overflow in ANGLE in Google Chrome on Windows prior to 146.0.7680.178 allowed a remote attacker who had compromised the renderer process to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: High)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00063,"ranking_epss":0.19778,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_31.html","https://issues.chromium.org/issues/489791424"],"published_time":"2026-04-01T05:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13855","summary":"IBM Storage Protect Server 8.2.0 IBM Storage Protect Plus Server is vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.","cvss":7.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.6,"epss":0.00095,"ranking_epss":0.2661,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7267783"],"published_time":"2026-04-01T01:16:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2485","summary":"IBM Infosphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to stored cross-site scripting. This vulnerability allows a privileged user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.","cvss":4.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.8,"epss":0.00027,"ranking_epss":0.07496,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266765"],"published_time":"2026-03-25T21:16:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2483","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00027,"ranking_epss":0.07689,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266764"],"published_time":"2026-03-25T21:16:40","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-1014","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to exposure of sensitive information via JSON server response manipulation.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00014,"ranking_epss":0.02452,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266736"],"published_time":"2026-03-25T21:16:28","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-1015","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00027,"ranking_epss":0.07447,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266740"],"published_time":"2026-03-25T21:16:28","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-1262","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is affected by an information disclosure vulnerability.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00029,"ranking_epss":0.08251,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266748"],"published_time":"2026-03-25T21:16:28","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-1561","summary":"IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.3 IBM WebSphere Application Server Liberty is vulnerable to server-side request forgery (SSRF). This may allow remote attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00032,"ranking_epss":0.09138,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7267347"],"published_time":"2026-03-25T21:16:28","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36422","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 IBM InfoSphere DataStage Flow Designer is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00015,"ranking_epss":0.02986,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266685"],"published_time":"2026-03-25T21:16:25","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14912","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00027,"ranking_epss":0.07447,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266698"],"published_time":"2026-03-25T21:16:24","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14915","summary":"IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.3 IBM WebSphere Application Server Liberty is affected by privilege escalation. A privileged user could gain additional access to the application server.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00036,"ranking_epss":0.10801,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7267345"],"published_time":"2026-03-25T21:16:24","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14917","summary":"IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.3 IBM WebSphere Application Server Liberty could provide weaker than expected security when administering security settings.","cvss":6.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.7,"epss":0.00037,"ranking_epss":0.11121,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7267362"],"published_time":"2026-03-25T21:16:24","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14974","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable due to Insecure Direct Object Reference (IDOR).","cvss":5.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.7,"epss":0.00042,"ranking_epss":0.12956,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266723"],"published_time":"2026-03-25T21:16:24","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36258","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 product stores user credentials and other sensitive information in plain text which can be read by a local user.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00013,"ranking_epss":0.02025,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266489"],"published_time":"2026-03-25T21:16:24","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14807","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to HTTP header injection, caused by improper validation of input by the HOST headers. This could allow an attacker to conduct various attacks against the vulnerable system, including cross-site scripting, cache poisoning or session hijacking.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00046,"ranking_epss":0.14261,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7267526"],"published_time":"2026-03-25T21:16:23","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14808","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 could allow an attacker to obtain sensitive information from the query string of an HTTP GET method to process a request which could be obtained using man in the middle techniques.","cvss":3.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.1,"epss":0.00029,"ranking_epss":0.08251,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266695"],"published_time":"2026-03-25T21:16:23","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14810","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 does not invalidate a session after privileges have been modified which could allow an authenticated user to retain access to sensitive information. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L CWE: CWE-613: Insufficient Session Expiration CVSS Source: IBM CVSS Base score: 6.3 CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L)","cvss":6.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.3,"epss":0.00029,"ranking_epss":0.0812,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266696"],"published_time":"2026-03-25T21:16:23","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14790","summary":"IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 could allow an attacker to obtain sensitive information due to insufficiently protected credentials.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.0003,"ranking_epss":0.08569,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266688"],"published_time":"2026-03-25T20:16:22","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4675","summary":"Heap buffer overflow in WebGL in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00073,"ranking_epss":0.22275,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/488270257"],"published_time":"2026-03-24T01:17:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4676","summary":"Use after free in Dawn in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00118,"ranking_epss":0.30791,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/488613135"],"published_time":"2026-03-24T01:17:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4677","summary":"Inappropriate implementation in WebAudio in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23725,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/490533968"],"published_time":"2026-03-24T01:17:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4678","summary":"Use after free in WebGPU in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00123,"ranking_epss":0.31581,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/491164019"],"published_time":"2026-03-24T01:17:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4679","summary":"Integer overflow in Fonts in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00109,"ranking_epss":0.29326,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/491516670"],"published_time":"2026-03-24T01:17:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4680","summary":"Use after free in FedCM in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00139,"ranking_epss":0.34124,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/491869946"],"published_time":"2026-03-24T01:17:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4673","summary":"Heap buffer overflow in WebAudio in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00092,"ranking_epss":0.25959,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/485397284"],"published_time":"2026-03-24T01:17:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4674","summary":"Out of bounds read in CSS in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00086,"ranking_epss":0.25055,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/488188166"],"published_time":"2026-03-24T01:17:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4458","summary":"Use after free in Extensions in Google Chrome prior to 146.0.7680.153 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted Chrome Extension. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00029,"ranking_epss":0.08347,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/489619753"],"published_time":"2026-03-20T02:16:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4459","summary":"Out of bounds read and write in WebAudio in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22568,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/490246422"],"published_time":"2026-03-20T02:16:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4460","summary":"Out of bounds read in Skia in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23898,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/490254124"],"published_time":"2026-03-20T02:16:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4461","summary":"Inappropriate implementation in V8 in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23898,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/490558172"],"published_time":"2026-03-20T02:16:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4462","summary":"Out of bounds read in Blink in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23898,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/491080830"],"published_time":"2026-03-20T02:16:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4463","summary":"Heap buffer overflow in WebRTC in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00068,"ranking_epss":0.21108,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/491358681"],"published_time":"2026-03-20T02:16:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4464","summary":"Integer overflow in ANGLE in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23898,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/487208468"],"published_time":"2026-03-20T02:16:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4451","summary":"Insufficient validation of untrusted input in Navigation in Google Chrome prior to 146.0.7680.153 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00116,"ranking_epss":0.30504,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/487768779"],"published_time":"2026-03-20T02:16:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4454","summary":"Use after free in Network in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00109,"ranking_epss":0.29404,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/488585488"],"published_time":"2026-03-20T02:16:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4455","summary":"Heap buffer overflow in PDFium in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted PDF file. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22433,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/488585504"],"published_time":"2026-03-20T02:16:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4456","summary":"Use after free in Digital Credentials API in Google Chrome prior to 146.0.7680.153 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00109,"ranking_epss":0.29404,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/488617440"],"published_time":"2026-03-20T02:16:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4457","summary":"Type Confusion in V8 in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00082,"ranking_epss":0.2417,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/488803413"],"published_time":"2026-03-20T02:16:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4444","summary":"Stack buffer overflow in WebRTC in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit stack corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00068,"ranking_epss":0.21108,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/486349161"],"published_time":"2026-03-20T02:16:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4445","summary":"Use after free in WebRTC in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00101,"ranking_epss":0.27968,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/486421953"],"published_time":"2026-03-20T02:16:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4446","summary":"Use after free in WebRTC in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00101,"ranking_epss":0.27968,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/486421954"],"published_time":"2026-03-20T02:16:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4447","summary":"Inappropriate implementation in V8 in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00095,"ranking_epss":0.26563,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/486657483"],"published_time":"2026-03-20T02:16:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4448","summary":"Heap buffer overflow in ANGLE in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22433,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/486972661"],"published_time":"2026-03-20T02:16:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4449","summary":"Use after free in Blink in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00109,"ranking_epss":0.29404,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/487117772"],"published_time":"2026-03-20T02:16:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4450","summary":"Out of bounds write in V8 in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00101,"ranking_epss":0.28077,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/487746373"],"published_time":"2026-03-20T02:16:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4439","summary":"Out of bounds memory access in WebGL in Google Chrome on Android prior to 146.0.7680.153 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22568,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/475877320"],"published_time":"2026-03-20T02:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4440","summary":"Out of bounds read and write in WebGL in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page. (Chromium security severity: Critical)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22568,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/485935305"],"published_time":"2026-03-20T02:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4441","summary":"Use after free in Base in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Critical)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00109,"ranking_epss":0.29404,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/489381399"],"published_time":"2026-03-20T02:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4442","summary":"Heap buffer overflow in CSS in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22433,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/484751092"],"published_time":"2026-03-20T02:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-4443","summary":"Heap buffer overflow in WebAudio in Google Chrome prior to 146.0.7680.153 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00075,"ranking_epss":0.2277,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_18.html","https://issues.chromium.org/issues/485292589"],"published_time":"2026-03-20T02:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13995","summary":"IBM QRadar SIEM 7.5.0 through 7.5.0 Update Package 14 could allow an attacker with access to one tenant to access hostname data from another tenant's account.","cvss":5.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.0,"epss":0.00044,"ranking_epss":0.13621,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266709"],"published_time":"2026-03-19T03:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-15051","summary":"IBM QRadar SIEM 7.5.0 through 7.5.0 Update Package 14 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00027,"ranking_epss":0.07689,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266709"],"published_time":"2026-03-19T03:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36051","summary":"IBM QRadar SIEM 7.5.0 through 7.5.0 Update Package 14 stores potentially sensitive information in configuration files that could be read by a local user.","cvss":6.2,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.2,"epss":0.00012,"ranking_epss":0.01899,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266709"],"published_time":"2026-03-19T03:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-1276","summary":"IBM QRadar SIEM 7.5.0 through 7.5.0 Update Package 14 is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00027,"ranking_epss":0.07689,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7266709"],"published_time":"2026-03-19T03:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13212","summary":"IBM Aspera Console 3.3.0 through 3.4.8 could allow an authenticated user to cause a denial of service in the email service due to improper control of interaction frequency.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00045,"ranking_epss":0.14066,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263486"],"published_time":"2026-03-16T14:17:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13459","summary":"IBM Aspera Console 3.3.0 through 3.4.8 could allow a privileged user to cause a denial of service due to improper enforcement of behavioral workflow.","cvss":2.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":2.7,"epss":0.00051,"ranking_epss":0.15806,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263486"],"published_time":"2026-03-16T14:17:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13460","summary":"IBM Aspera Console 3.3.0 through 3.4.8 could allow an attacker to enumerate usernames due to an observable response discrepancy.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00034,"ranking_epss":0.10114,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263486"],"published_time":"2026-03-16T14:17:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3909","summary":"Out of bounds write in Skia in Google Chrome prior to 146.0.7680.75 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00264,"ranking_epss":0.49922,"kev":true,"propose_action":"Google Skia contains an out-of-bounds write vulnerability that could allow a remote attacker to perform out of bounds memory access via a crafted HTML page. This vulnerability affects Google Chrome and ChromeOS, Android, Flutter, and possibly other products.","ransomware_campaign":"Unknown","references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/491421267","https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-3909"],"published_time":"2026-03-13T19:55:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3910","summary":"Inappropriate implementation in V8 in Google Chrome prior to 146.0.7680.75 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00769,"ranking_epss":0.73477,"kev":true,"propose_action":"Google Chromium V8 contains an improper restriction of operations within the bounds of a memory buffer vulnerability that could allow a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera.","ransomware_campaign":"Unknown","references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_12.html","https://issues.chromium.org/issues/491410818","https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-3910"],"published_time":"2026-03-13T19:55:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13702","summary":"IBM Sterling Partner Engagement Manager 6.2.3.0 through 6.2.3.5 and 6.2.4.0 through 6.2.4.2 is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00027,"ranking_epss":0.07689,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263391"],"published_time":"2026-03-13T19:53:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13718","summary":"IBM Sterling Partner Engagement Manager 6.2.3.0 through 6.2.3.5 and 6.2.4.0 through 6.2.4.2 could allow a remote attacker to obtain sensitive information in cleartext in a communication channel that can be sniffed by unauthorized actors.","cvss":3.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.7,"epss":0.0002,"ranking_epss":0.05328,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263391"],"published_time":"2026-03-13T19:53:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13723","summary":"IBM Sterling Partner Engagement Manager 6.2.3.0 through 6.2.3.5 and 6.2.4.0 through 6.2.4.2 could allow an attacker to obtain sensitive user information using an expired access token","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00016,"ranking_epss":0.03371,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263391"],"published_time":"2026-03-13T19:53:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13726","summary":"IBM Sterling Partner Engagement Manager 6.2.3.0 through 6.2.3.5 and 6.2.4.0 through 6.2.4.2 could allow a remote attacker to obtain sensitive information when detailed technical error messages are returned. This information could be used in further attacks against the system.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00047,"ranking_epss":0.14788,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263391"],"published_time":"2026-03-13T19:53:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3934","summary":"Insufficient policy enforcement in ChromeDriver in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00025,"ranking_epss":0.06933,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/478783560"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3935","summary":"Incorrect security UI in WebAppInstalls in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00026,"ranking_epss":0.07228,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/479326680"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3936","summary":"Use after free in WebView in Google Chrome on Android prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00108,"ranking_epss":0.29237,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/481920229"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3937","summary":"Incorrect security UI in Downloads in Google Chrome on Android prior to 146.0.7680.71 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00028,"ranking_epss":0.08052,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/473118648"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3938","summary":"Insufficient policy enforcement in Clipboard in Google Chrome prior to 146.0.7680.71 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00032,"ranking_epss":0.09292,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/474763968"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3939","summary":"Insufficient policy enforcement in PDF in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to bypass navigation restrictions via a crafted PDF file. (Chromium security severity: Low)","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00025,"ranking_epss":0.06933,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/40058077"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3940","summary":"Insufficient policy enforcement in DevTools in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00025,"ranking_epss":0.06933,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/470574526"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3941","summary":"Insufficient policy enforcement in DevTools in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00034,"ranking_epss":0.09822,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/474670215"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3942","summary":"Incorrect security UI in PictureInPicture in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00028,"ranking_epss":0.08052,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/475238879"],"published_time":"2026-03-11T22:16:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3925","summary":"Incorrect security UI in LookalikeChecks in Google Chrome on Android prior to 146.0.7680.71 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00024,"ranking_epss":0.06455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/418214610"],"published_time":"2026-03-11T22:16:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3926","summary":"Out of bounds read in V8 in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00086,"ranking_epss":0.25055,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/478659010"],"published_time":"2026-03-11T22:16:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3927","summary":"Incorrect security UI in PictureInPicture in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00028,"ranking_epss":0.08052,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/474948986"],"published_time":"2026-03-11T22:16:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3928","summary":"Insufficient policy enforcement in Extensions in Google Chrome prior to 146.0.7680.71 allowed an attacker who convinced a user to install a malicious extension to perform UI spoofing via a crafted Chrome Extension. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00015,"ranking_epss":0.02914,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/435980394"],"published_time":"2026-03-11T22:16:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3929","summary":"Side-channel information leakage in ResourceTiming in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium)","cvss":3.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.1,"epss":0.00031,"ranking_epss":0.09035,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/477180001"],"published_time":"2026-03-11T22:16:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3930","summary":"Unsafe navigation in Navigation in Google Chrome on iOS prior to 146.0.7680.71 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Medium)","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00025,"ranking_epss":0.06933,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/476898368"],"published_time":"2026-03-11T22:16:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3931","summary":"Heap buffer overflow in Skia in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00079,"ranking_epss":0.23592,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/417599694"],"published_time":"2026-03-11T22:16:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3932","summary":"Insufficient policy enforcement in PDF in Google Chrome on Android prior to 146.0.7680.71 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Medium)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00025,"ranking_epss":0.06933,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/478296121"],"published_time":"2026-03-11T22:16:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3917","summary":"Use after free in Agents in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00118,"ranking_epss":0.30791,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/483569512"],"published_time":"2026-03-11T22:16:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3918","summary":"Use after free in WebMCP in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00108,"ranking_epss":0.29237,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/483853103"],"published_time":"2026-03-11T22:16:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3919","summary":"Use after free in Extensions in Google Chrome prior to 146.0.7680.71 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00031,"ranking_epss":0.0904,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/444176961"],"published_time":"2026-03-11T22:16:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3920","summary":"Out of bounds memory access in WebML in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23725,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/482875307"],"published_time":"2026-03-11T22:16:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3921","summary":"Use after free in TextEncoding in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00118,"ranking_epss":0.30791,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/484946544"],"published_time":"2026-03-11T22:16:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3922","summary":"Use after free in MediaStream in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00118,"ranking_epss":0.30791,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/485397139"],"published_time":"2026-03-11T22:16:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3923","summary":"Use after free in WebMIDI in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00108,"ranking_epss":0.29237,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/485935314"],"published_time":"2026-03-11T22:16:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3924","summary":"use after free in WindowDialog in Google Chrome prior to 146.0.7680.71 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00118,"ranking_epss":0.30791,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/487338366"],"published_time":"2026-03-11T22:16:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3913","summary":"Heap buffer overflow in WebML in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Critical)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00073,"ranking_epss":0.22275,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/483445078"],"published_time":"2026-03-11T22:16:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3914","summary":"Integer overflow in WebML in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23725,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/481776048"],"published_time":"2026-03-11T22:16:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3915","summary":"Heap buffer overflow in WebML in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00073,"ranking_epss":0.22275,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/483971526"],"published_time":"2026-03-11T22:16:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3916","summary":"Out of bounds read in Web Speech in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":9.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.6,"epss":0.0008,"ranking_epss":0.23725,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/482828615"],"published_time":"2026-03-11T22:16:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13213","summary":"IBM Aspera Orchestrator 3.0.0 through 4.1.2 is vulnerable to HTTP header injection, caused by improper validation of input by the HOST headers. This could allow an attacker to conduct various attacks against the vulnerable system, including cross-site scripting, cache poisoning or session hijacking","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00026,"ranking_epss":0.0722,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263083"],"published_time":"2026-03-10T21:16:40","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36227","summary":"IBM Aspera Faspex 5 5.0.0 through 5.0.14.3 is vulnerable to HTTP header injection, caused by improper validation of input by the HOST headers.  This could allow an attacker to conduct various attacks against the vulnerable system, including cross-site scripting, cache poisoning or session hijacking.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00026,"ranking_epss":0.0722,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7262816"],"published_time":"2026-03-10T20:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13219","summary":"IBM Aspera Orchestrator 3.0.0 through 4.1.2 stores sensitive information in URL parameters. This may lead to information disclosure if unauthorized parties have access to the URLs via server logs, referrer header or browser history.","cvss":5.9,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.9,"epss":0.00038,"ranking_epss":0.11686,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7263083"],"published_time":"2026-03-10T20:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36226","summary":"IBM Aspera Faspex 5 5.0.0 through 5.0.14.3 is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00027,"ranking_epss":0.07689,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7262816"],"published_time":"2026-03-10T20:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-26131","summary":"Incorrect default permissions in .NET allows an authorized attacker to elevate privileges locally.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00016,"ranking_epss":0.03538,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-26131"],"published_time":"2026-03-10T18:18:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-26127","summary":"Out-of-bounds read in .NET allows an unauthorized attacker to deny service over a network.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00104,"ranking_epss":0.28492,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-26127"],"published_time":"2026-03-10T18:18:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28723","summary":"Unauthorized report deletion due to insufficient access control. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00034,"ranking_epss":0.09849,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8486"],"published_time":"2026-03-06T00:16:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28724","summary":"Unauthorized data access due to insufficient access control validation. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00032,"ranking_epss":0.09265,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8493"],"published_time":"2026-03-06T00:16:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28725","summary":"Sensitive information disclosure due to improper configuration of a headless browser. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02472,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8695"],"published_time":"2026-03-06T00:16:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28726","summary":"Sensitive information disclosure due to improper access control. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00032,"ranking_epss":0.09265,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8401"],"published_time":"2026-03-06T00:16:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28715","summary":"Sensitive information disclosure due to improper authorization checks. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00033,"ranking_epss":0.09656,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-5910"],"published_time":"2026-03-06T00:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28716","summary":"Information disclosure and manipulation due to improper authorization checks. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":4.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.4,"epss":0.00013,"ranking_epss":0.02169,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-3687"],"published_time":"2026-03-06T00:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28718","summary":"Denial of service due to insufficient input validation in authentication logging. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00095,"ranking_epss":0.26531,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8377"],"published_time":"2026-03-06T00:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28719","summary":"Unauthorized resource manipulation due to improper authorization checks. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00034,"ranking_epss":0.09849,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8378"],"published_time":"2026-03-06T00:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28720","summary":"Unauthorized modification of settings due to insufficient authorization checks. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00034,"ranking_epss":0.09849,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8379"],"published_time":"2026-03-06T00:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28709","summary":"Unauthorized resource manipulation due to improper authorization checks. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00031,"ranking_epss":0.08938,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-5889"],"published_time":"2026-03-06T00:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28710","summary":"Sensitive information disclosure and manipulation due to improper authentication. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.00091,"ranking_epss":0.25904,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-9137"],"published_time":"2026-03-06T00:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-28714","summary":"Unnecessary transmission of sensitive cryptographic material. The following products are affected: Acronis Cyber Protect 17 (Linux, Windows) before build 41186.","cvss":4.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.8,"epss":0.00019,"ranking_epss":0.05047,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-5383"],"published_time":"2026-03-06T00:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-30413","summary":"Credentials are not deleted from Acronis Agent after plan revocation. The following products are affected: Acronis Cyber Protect Cloud Agent (Linux, macOS, Windows) before build 40497, Acronis Cyber Protect 17 (Linux, macOS, Windows) before build 41186.","cvss":4.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.4,"epss":0.00014,"ranking_epss":0.02474,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/SEC-9386","https://security-advisory.acronis.com/advisories/SEC-8658"],"published_time":"2026-03-06T00:16:10","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11790","summary":"Credentials are not deleted from Acronis Agent after plan revocation. The following products are affected: Acronis Cyber Protect Cloud Agent (Linux, macOS, Windows) before build 41124.","cvss":4.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.4,"epss":0.00015,"ranking_epss":0.03047,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/SEC-8658","https://security-advisory.acronis.com/advisories/SEC-9386"],"published_time":"2026-03-06T00:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11791","summary":"Sensitive information disclosure and manipulation due to insufficient authorization checks. The following products are affected: Acronis Cyber Protect 17 (Linux, macOS, Windows) before build 41186, Acronis Cyber Protect Cloud Agent (Linux, macOS, Windows) before build 41124.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.0202,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-9405"],"published_time":"2026-03-06T00:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30796","summary":"Cleartext Transmission of Sensitive Information vulnerability in rustdesk-server-pro RustDesk Server Pro rustdesk-server-pro on Windows, MacOS, Linux (Address book sync API modules) allows Sniffing Attacks. This vulnerability is associated with program files Closed source — API endpoint handling heartbeat sync and program routines Heartbeat API handler (accepts preset-address-book-password in plaintext).\n\nThis issue affects RustDesk Server Pro: through 1.7.5.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00016,"ranking_epss":0.03481,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://rustdesk.com/docs/en/","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30797","summary":"Missing Authorization vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android (Flutter URI scheme handler, config import modules) allows Application API Message Manipulation via Man-in-the-Middle. This vulnerability is associated with program files flutter/lib/common.Dart and program routines importConfig() via URI handler.\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.00041,"ranking_epss":0.12732,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://rustdesk.com/docs/en/client/","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30798","summary":"Insufficient Verification of Data Authenticity, Improper Handling of Exceptional Conditions vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android (Heartbeat sync loop, strategy processing modules) allows Protocol Manipulation. This vulnerability is associated with program files src/hbbs_http/sync.Rs and program routines stop-service handler in heartbeat loop.\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00021,"ranking_epss":0.05681,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://rustdesk.com/docs/en/client/","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30793","summary":"Cross-Site Request Forgery (CSRF) vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android (Flutter URI scheme handler, FFI bridge modules) allows Privilege Escalation. This vulnerability is associated with program files flutter/lib/common.Dart, src/flutter_ffi.Rs and program routines URI handler for rustdesk://password/, bind.MainSetPermanentPassword().\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00026,"ranking_epss":0.07219,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://github.com/rustdesk/hbb_common","https://github.com/rustdesk/rustdesk","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30794","summary":"Improper Certificate Validation vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android (HTTP API client, TLS transport modules) allows Adversary in the Middle (AiTM). This vulnerability is associated with program files src/hbbs_http/http_client.Rs and program routines TLS retry with danger_accept_invalid_certs(true).\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.00028,"ranking_epss":0.07869,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://github.com/rustdesk/rustdesk","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30795","summary":"Cleartext Transmission of Sensitive Information vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android (Heartbeat sync loop modules) allows Sniffing Attacks. This vulnerability is associated with program files src/hbbs_http/sync.Rs and program routines Heartbeat JSON payload construction (preset-address-book-password).\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00015,"ranking_epss":0.03017,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://github.com/rustdesk/rustdesk","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30785","summary":"Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'), Use of Password Hash With Insufficient Computational Effort vulnerability in rustdesk-client RustDesk Client rustdesk, hbb_common on Windows, MacOS, Linux (Password security module, config encryption, machine UID modules) allows Retrieve Embedded Sensitive Data. This vulnerability is associated with program files hbb_common/src/password_security.Rs, hbb_common/src/config.Rs, hbb_common/src/lib.Rs (get_uuid), machine-uid/src/lib.Rs and program routines symmetric_crypt(), encrypt_str_or_original(), decrypt_str_or_original(), get_uuid(), get_machine_id().\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":5e-05,"ranking_epss":0.00206,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://github.com/rustdesk/rustdesk/discussions/4979","https://github.com/rustdesk/rustdesk/discussions/9229","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30789","summary":"Authentication Bypass by Capture-replay, Use of Password Hash With Insufficient Computational Effort vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android (Client login, peer authentication modules) allows Reusing Session IDs (aka Session Replay). This vulnerability is associated with program files src/client.Rs and program routines hash_password(), login proof construction.\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00112,"ranking_epss":0.29869,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://rustdesk.com/docs/en/client/","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30790","summary":"Improper Restriction of Excessive Authentication Attempts, Use of Password Hash With Insufficient Computational Effort vulnerability in rustdesk-server-pro RustDesk Server Pro rustdesk-server-pro on Windows, MacOS, Linux (Peer authentication, API login modules), rustdesk-server RustDesk Server (OSS) rustdesk-server on Windows, MacOS, Linux (Peer authentication, API login modules) allows Password Brute Forcing. This vulnerability is associated with program files src/server/connection.Rs and program routines Salt/challenge generation, SHA256(SHA256(pwd+salt)+challenge) verification.\n\nThis issue affects RustDesk Server Pro: through 1.7.5; RustDesk Server (OSS): through 1.1.15.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00102,"ranking_epss":0.28193,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://github.com/rustdesk","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30792","summary":"A vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android, WebClient (Strategy sync, HTTP API client, config options engine modules) allows Application API Message Manipulation via Man-in-the-Middle. This vulnerability is associated with program files src/hbbs_http/sync.Rs, hbb_common/src/config.Rs and program routines Strategy merge loop in sync.Rs, Config::set_options().\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.00045,"ranking_epss":0.13969,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30783","summary":"A vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android, WebClient (Client signaling, API sync loop, config management modules) allows Privilege Abuse. This vulnerability is associated with program files src/rendezvous_mediator.Rs, src/hbbs_http/sync.Rs and program routines API sync loop, api-server config handling.\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.0009,"ranking_epss":0.25608,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://rustdesk.com/docs/en/client/","https://www.vulsec.org/"],"published_time":"2026-03-05T16:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3598","summary":"Use of a Broken or Risky Cryptographic Algorithm vulnerability in rustdesk-server-pro RustDesk Server Pro rustdesk-server-pro on Windows, MacOS, Linux (Config string generation, web console export modules) allows Retrieve Embedded Sensitive Data. This vulnerability is associated with program routines Config export/generation routines.\n\nThis issue affects RustDesk Server Pro: through 1.7.5.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00016,"ranking_epss":0.03379,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://rustdesk.com/docs/en/client/","https://www.vulsec.org/"],"published_time":"2026-03-05T15:16:15","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-30791","summary":"Use of a Broken or Risky Cryptographic Algorithm vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android, WebClient (Config import, URI scheme handler, CLI --config modules) allows Retrieve Embedded Sensitive Data. This vulnerability is associated with program files flutter/lib/common.Dart, hbb_common/src/config.Rs and program routines parseRustdeskUri(), importConfig().\n\nThis issue affects RustDesk Client: through 1.4.5.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00016,"ranking_epss":0.03379,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub","https://rustdesk.com/docs/en/client/","https://www.vulsec.org/"],"published_time":"2026-03-05T15:16:14","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3540","summary":"Inappropriate implementation in WebAudio in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00074,"ranking_epss":0.22568,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/484088917"],"published_time":"2026-03-04T20:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3541","summary":"Inappropriate implementation in CSS in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00078,"ranking_epss":0.23392,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/484811719"],"published_time":"2026-03-04T20:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3542","summary":"Inappropriate implementation in WebAssembly in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00072,"ranking_epss":0.22097,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/485152421"],"published_time":"2026-03-04T20:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3543","summary":"Inappropriate implementation in V8 in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00078,"ranking_epss":0.23392,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/485267831"],"published_time":"2026-03-04T20:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3544","summary":"Heap buffer overflow in WebCodecs in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00085,"ranking_epss":0.24845,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/485683110"],"published_time":"2026-03-04T20:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3545","summary":"Insufficient data validation in Navigation in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":9.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.6,"epss":0.00116,"ranking_epss":0.30504,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/487383169"],"published_time":"2026-03-04T20:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3536","summary":"Integer overflow in ANGLE in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Critical)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23898,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/485622239"],"published_time":"2026-03-04T20:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3537","summary":"Object lifecycle issue in PowerVR in Google Chrome on Android prior to 145.0.7632.159 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Critical)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00082,"ranking_epss":0.2417,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/474266014"],"published_time":"2026-03-04T20:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3538","summary":"Integer overflow in Skia in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Critical)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0008,"ranking_epss":0.23898,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/484983991"],"published_time":"2026-03-04T20:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3539","summary":"Object lifecycle issue in DevTools in Google Chrome prior to 145.0.7632.159 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted Chrome Extension. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":8e-05,"ranking_epss":0.00707,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/483853098"],"published_time":"2026-03-04T20:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23236","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: smscufx: properly copy ioctl memory to kernelspace\n\nThe UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from\nuserspace to kernelspace, and instead directly references the memory,\nwhich can cause problems if invalid data is passed from userspace.  Fix\nthis all up by correctly copying the memory before accessing it within\nthe kernel.","cvss":7.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.3,"epss":8e-05,"ranking_epss":0.00747,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/061cfeb560aa3ddc174153dbe5be9d0b55eb7248","https://git.kernel.org/stable/c/0634e8d650993602fc5b389ff7ac525f6542e141","https://git.kernel.org/stable/c/120adae7b42faa641179270c067864544a50ab69","https://git.kernel.org/stable/c/1c008ad0f0d1c1523902b9cdb08e404129677bfc","https://git.kernel.org/stable/c/52917e265aa5f848212f60fc50fc504d8ef12866","https://git.kernel.org/stable/c/6167af934f956d3ae1e06d61f45cd0d1004bbe1a","https://git.kernel.org/stable/c/a0321e6e58facb39fe191caa0e52ed9aab6a48fe","https://git.kernel.org/stable/c/f1e91bd4efeae48b0f42caed7e8ce2e3a0d05b02"],"published_time":"2026-03-04T15:16:14","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23237","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: classmate-laptop: Add missing NULL pointer checks\n\nIn a few places in the Classmate laptop driver, code using the accel\nobject may run before that object's address is stored in the driver\ndata of the input device using it.\n\nFor example, cmpc_accel_sensitivity_store_v4() is the \"show\" method\nof cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(),\nbefore calling dev_set_drvdata() for inputdev->dev.  If the sysfs\nattribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev)\ncall in in cmpc_accel_sensitivity_store_v4() returns NULL which\nleads to a NULL pointer dereference going forward.\n\nMoreover, sysfs attributes using the input device are added before\ninitializing that device by cmpc_add_acpi_notify_device() and if one\nof them is accessed before running that function, a NULL pointer\ndereference will occur.\n\nFor example, cmpc_accel_sensitivity_attr_v4 is added before calling\ncmpc_add_acpi_notify_device() and if it is read prematurely, the\ndev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4()\nreturns NULL which leads to a NULL pointer dereference going forward.\n\nFix this by adding NULL pointer checks in all of the relevant places.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00472,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/97528b1622b8f129574d29a571c32a3c85eafa3c","https://git.kernel.org/stable/c/993708fc18d0d0919db438361b4e8c1f980a8d1b","https://git.kernel.org/stable/c/9cf4b9b8ad09d6e05307abc4e951cabdff4be652","https://git.kernel.org/stable/c/af673209d43b46257540997aba042b90ef3258c0","https://git.kernel.org/stable/c/da6e06a5fdbabea3870d18c227734b5dea5b3be6","https://git.kernel.org/stable/c/eb214804f03c829decf10998e9b7dd26f4c8ab9e","https://git.kernel.org/stable/c/fe747d7112283f47169e9c16e751179a9b38611e"],"published_time":"2026-03-04T15:16:14","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23238","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nromfs: check sb_set_blocksize() return value\n\nromfs_fill_super() ignores the return value of sb_set_blocksize(), which\ncan fail if the requested block size is incompatible with the block\ndevice's configuration.\n\nThis can be triggered by setting a loop device's block size larger than\nPAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs\nfilesystem on that device.\n\nWhen sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the\ndevice has logical_block_size=32768, bdev_validate_blocksize() fails\nbecause the requested size is smaller than the device's logical block\nsize. sb_set_blocksize() returns 0 (failure), but romfs ignores this and\ncontinues mounting.\n\nThe superblock's block size remains at the device's logical block size\n(32768). Later, when sb_bread() attempts I/O with this oversized block\nsize, it triggers a kernel BUG in folio_set_bh():\n\n    kernel BUG at fs/buffer.c:1582!\n    BUG_ON(size > PAGE_SIZE);\n\nFix by checking the return value of sb_set_blocksize() and failing the\nmount with -EINVAL if it returns 0.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00472,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2c5829cd8fbbc91568c520b666898f57cdcb8cf6","https://git.kernel.org/stable/c/4b71ad7676564a94ec5f7d18298f51e8ae53db73","https://git.kernel.org/stable/c/9b203b8ddd7359270e8a694d0584743555128e2c","https://git.kernel.org/stable/c/a381f0f61b35c8894b0bd0d6acef2d8f9b08b244","https://git.kernel.org/stable/c/ab7ad7abb3660c58ffffdf07ff3bb976e7e0afa0","https://git.kernel.org/stable/c/cbd9931e6456822067725354d83446c5bb813030","https://git.kernel.org/stable/c/f2521ab1f63a8c244f06a080319e5ff9a2e1bd95"],"published_time":"2026-03-04T15:16:14","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23232","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"f2fs: block cache/dio write during f2fs_enable_checkpoint()\"\n\nThis reverts commit 196c81fdd438f7ac429d5639090a9816abb9760a.\n\nOriginal patch may cause below deadlock, revert it.\n\nwrite\t\t\t\tremount\n- write_begin\n - lock_page  --- lock A\n - prepare_write_begin\n  - f2fs_map_lock\n\t\t\t\t- f2fs_enable_checkpoint\n\t\t\t\t - down_write(cp_enable_rwsem)  --- lock B\n\t\t\t\t - sync_inode_sb\n\t\t\t\t  - writepages\n\t\t\t\t   - lock_page\t\t\t--- lock A\n   - down_read(cp_enable_rwsem)  --- lock A","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.02153,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3996b70209f145bfcf2afc7d05dd92c27b233b48","https://git.kernel.org/stable/c/b6382273801bc7c778545dd8004c9a9d750b4f62"],"published_time":"2026-03-04T15:16:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23233","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid mapping wrong physical block for swapfile\n\nXiaolong Guo reported a f2fs bug in bugzilla [1]\n\n[1] https://bugzilla.kernel.org/show_bug.cgi?id=220951\n\nQuoted:\n\n\"When using stress-ng's swap stress test on F2FS filesystem with kernel 6.6+,\nthe system experiences data corruption leading to either:\n1 dm-verity corruption errors and device reboot\n2 F2FS node corruption errors and boot hangs\n\nThe issue occurs specifically when:\n1 Using F2FS filesystem (ext4 is unaffected)\n2 Swapfile size is less than F2FS section size (2MB)\n3 Swapfile has fragmented physical layout (multiple non-contiguous extents)\n4 Kernel version is 6.6+ (6.1 is unaffected)\n\nThe root cause is in check_swap_activate() function in fs/f2fs/data.c. When the\nfirst extent of a small swapfile (< 2MB) is not aligned to section boundaries,\nthe function incorrectly treats it as the last extent, failing to map\nsubsequent extents. This results in incorrect swap_extent creation where only\nthe first extent is mapped, causing subsequent swap writes to overwrite wrong\nphysical locations (other files' data).\n\nSteps to Reproduce\n1 Setup a device with F2FS-formatted userdata partition\n2 Compile stress-ng from https://github.com/ColinIanKing/stress-ng\n3 Run swap stress test: (Android devices)\nadb shell \"cd /data/stressng; ./stress-ng-64 --metrics-brief --timeout 60\n--swap 0\"\n\nLog:\n1 Ftrace shows in kernel 6.6, only first extent is mapped during second\nf2fs_map_blocks call in check_swap_activate():\nstress-ng-swap-8990: f2fs_map_blocks: ino=11002, file offset=0, start\nblkaddr=0x43143, len=0x1\n(Only 4KB mapped, not the full swapfile)\n2 in kernel 6.1, both extents are correctly mapped:\nstress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=0, start\nblkaddr=0x13cd4, len=0x1\nstress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=1, start\nblkaddr=0x60c84b, len=0xff\n\nThe problematic code is in check_swap_activate():\nif ((pblock - SM_I(sbi)->main_blkaddr) % blks_per_sec ||\n    nr_pblocks % blks_per_sec ||\n    !f2fs_valid_pinned_area(sbi, pblock)) {\n    bool last_extent = false;\n\n    not_aligned++;\n\n    nr_pblocks = roundup(nr_pblocks, blks_per_sec);\n    if (cur_lblock + nr_pblocks > sis->max)\n        nr_pblocks -= blks_per_sec;\n\n    /* this extent is last one */\n    if (!nr_pblocks) {\n        nr_pblocks = last_lblock - cur_lblock;\n        last_extent = true;\n    }\n\n    ret = f2fs_migrate_blocks(inode, cur_lblock, nr_pblocks);\n    if (ret) {\n        if (ret == -ENOENT)\n            ret = -EINVAL;\n        goto out;\n    }\n\n    if (!last_extent)\n        goto retry;\n}\n\nWhen the first extent is unaligned and roundup(nr_pblocks, blks_per_sec)\nexceeds sis->max, we subtract blks_per_sec resulting in nr_pblocks = 0. The\ncode then incorrectly assumes this is the last extent, sets nr_pblocks =\nlast_lblock - cur_lblock (entire swapfile), and performs migration. After\nmigration, it doesn't retry mapping, so subsequent extents are never processed.\n\"\n\nIn order to fix this issue, we need to lookup block mapping info after\nwe migrate all blocks in the tail of swapfile.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00013,"ranking_epss":0.02287,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1ff415eef513bf12deb058fc50d57788c46c48e6","https://git.kernel.org/stable/c/5c145c03188bc9ba1c29e0bc4d527a5978fc47f9","https://git.kernel.org/stable/c/607cb9d83838d2cd9f0406c2403ed61aadf0edff","https://git.kernel.org/stable/c/d4534a7f6c92baaf7e12a45fc6e37332cafafc33","https://git.kernel.org/stable/c/fee27b69dde1a05908b350eea42937af2387c4fe"],"published_time":"2026-03-04T15:16:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23234","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid UAF in f2fs_write_end_io()\n\nAs syzbot reported an use-after-free issue in f2fs_write_end_io().\n\nIt is caused by below race condition:\n\nloop device\t\t\t\tumount\n- worker_thread\n - loop_process_work\n  - do_req_filebacked\n   - lo_rw_aio\n    - lo_rw_aio_complete\n     - blk_mq_end_request\n      - blk_update_request\n       - f2fs_write_end_io\n        - dec_page_count\n        - folio_end_writeback\n\t\t\t\t\t- kill_f2fs_super\n\t\t\t\t\t - kill_block_super\n\t\t\t\t\t  - f2fs_put_super\n\t\t\t\t\t : free(sbi)\n       : get_pages(, F2FS_WB_CP_DATA)\n         accessed sbi which is freed\n\nIn kill_f2fs_super(), we will drop all page caches of f2fs inodes before\ncall free(sbi), it guarantee that all folios should end its writeback, so\nit should be safe to access sbi before last folio_end_writeback().\n\nLet's relocate ckpt thread wakeup flow before folio_end_writeback() to\nresolve this issue.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02756,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0fb58aff0dafd6837cc91f4154f3ed6e020358fa","https://git.kernel.org/stable/c/2f67ff1e15a8a4d0e4ffc6564ab20d03d7398fe9","https://git.kernel.org/stable/c/505e1c0530db6152cab3feef8e3e4da3d3e358c9","https://git.kernel.org/stable/c/995030be4ce6338c6ff814583c14166446a64008","https://git.kernel.org/stable/c/a42f99be8a16b32a0bb91bb6dda212a6ad61be5d","https://git.kernel.org/stable/c/acc2c97fc0005846e5cf11b5ba3189fef130c9b3","https://git.kernel.org/stable/c/ce2739e482bce8d2c014d76c4531c877f382aa54","https://git.kernel.org/stable/c/cf4a9e1bc8129eb63fda5f8bdcd8d87f0bd76f42"],"published_time":"2026-03-04T15:16:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23235","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix out-of-bounds access in sysfs attribute read/write\n\nSome f2fs sysfs attributes suffer from out-of-bounds memory access and\nincorrect handling of integer values whose size is not 4 bytes.\n\nFor example:\nvm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out\nvm:~# cat /sys/fs/f2fs/vde/carve_out\n65537\nvm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold\nvm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold\n1\n\ncarve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit\ninteger. However, the sysfs interface allows setting it to a value\nlarger than 255, resulting in an out-of-range update.\n\natgc_age_threshold maps to {struct atgc_management}->age_threshold,\nwhich is a 64-bit integer, but its sysfs interface cannot correctly set\nvalues larger than UINT_MAX.\n\nThe root causes are:\n1. __sbi_store() treats all default values as unsigned int, which\nprevents updating integers larger than 4 bytes and causes out-of-bounds\nwrites for integers smaller than 4 bytes.\n\n2. f2fs_sbi_show() also assumes all default values are unsigned int,\nleading to out-of-bounds reads and incorrect access to integers larger\nthan 4 bytes.\n\nThis patch introduces {struct f2fs_attr}->size to record the actual size\nof the integer associated with each sysfs attribute. With this\ninformation, sysfs read and write operations can correctly access and\nupdate values according to their real data size, avoiding memory\ncorruption and truncation.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00014,"ranking_epss":0.02756,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3a905e183c047577b154f08a78ac3039e9454703","https://git.kernel.org/stable/c/438a405fbad6882df0e34b3e1a16839a71f04240","https://git.kernel.org/stable/c/4ef30b9f1641c9e877792df6b049f1cf507d002d","https://git.kernel.org/stable/c/6a6c07a9b49e43f0df42d7118fc76aa555c73d98","https://git.kernel.org/stable/c/98ea0039dbfdd00e5cc1b9a8afa40434476c0955","https://git.kernel.org/stable/c/d4a594dd952df123cbdcdee9b9640d9d55e4a954","https://git.kernel.org/stable/c/e85a99db9ab85dfc30d93b0ca0e9156f3127f55a","https://git.kernel.org/stable/c/eebd72cff518ac87e660aefb8a41224bd88c32ce"],"published_time":"2026-03-04T15:16:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71238","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix bsg_done() causing double free\n\nKernel panic observed on system,\n\n[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000\n[5353358.825194] #PF: supervisor write access in kernel mode\n[5353358.825195] #PF: error_code(0x0002) - not-present page\n[5353358.825196] PGD 100006067 P4D 0\n[5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G        W    L    -------  ---  5.14.0-503.34.1.el9_5.x86_64 #1\n[5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025\n[5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10\n[5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246\n[5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000\n[5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000\n[5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000\n[5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090\n[5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000\n[5353358.825218] FS:  00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000\n[5353358.825219] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0\n[5353358.825221] PKRU: 55555554\n[5353358.825222] Call Trace:\n[5353358.825223]  <TASK>\n[5353358.825224]  ? show_trace_log_lvl+0x1c4/0x2df\n[5353358.825229]  ? show_trace_log_lvl+0x1c4/0x2df\n[5353358.825232]  ? sg_copy_buffer+0xc8/0x110\n[5353358.825236]  ? __die_body.cold+0x8/0xd\n[5353358.825238]  ? page_fault_oops+0x134/0x170\n[5353358.825242]  ? kernelmode_fixup_or_oops+0x84/0x110\n[5353358.825244]  ? exc_page_fault+0xa8/0x150\n[5353358.825247]  ? asm_exc_page_fault+0x22/0x30\n[5353358.825252]  ? memcpy_erms+0x6/0x10\n[5353358.825253]  sg_copy_buffer+0xc8/0x110\n[5353358.825259]  qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx]\n[5353358.825317]  qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx]\n\nMost routines in qla_bsg.c call bsg_done() only for success cases.\nHowever a few invoke it for failure case as well leading to a double\nfree. Validate before calling bsg_done().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":8e-05,"ranking_epss":0.00707,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/057a5bdc481e58ab853117254867ffb22caf9f6e","https://git.kernel.org/stable/c/27ac9679c43a09e54e2d9aae9980ada045b428e0","https://git.kernel.org/stable/c/31f33b856d2324d86bcaef295f4d210477a1c018","https://git.kernel.org/stable/c/708003e1bc857dd014d4c44278d7d77c26f91b1c","https://git.kernel.org/stable/c/74e7458537cd9349cf019862e51491f670871707","https://git.kernel.org/stable/c/871f6236da96c4a9712b8a29d7f555f767a47e95","https://git.kernel.org/stable/c/c2c68225b1456f4d0d393b5a8778d51bb0d5b1d0","https://git.kernel.org/stable/c/f2bbb4db0e4a4fbd5e649c0b5d8733f61da24720"],"published_time":"2026-03-04T15:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23231","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix use-after-free in nf_tables_addchain()\n\nnf_tables_addchain() publishes the chain to table->chains via\nlist_add_tail_rcu() (in nft_chain_add()) before registering hooks.\nIf nf_tables_register_hook() then fails, the error path calls\nnft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy()\nwith no RCU grace period in between.\n\nThis creates two use-after-free conditions:\n\n 1) Control-plane: nf_tables_dump_chains() traverses table->chains\n    under rcu_read_lock(). A concurrent dump can still be walking\n    the chain when the error path frees it.\n\n 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly\n    installs the IPv4 hook before IPv6 registration fails.  Packets\n    entering nft_do_chain() via the transient IPv4 hook can still be\n    dereferencing chain->blob_gen_X when the error path frees the\n    chain.\n\nAdd synchronize_rcu() between nft_chain_del() and the chain destroy\nso that all RCU readers -- both dump threads and in-flight packet\nevaluation -- have finished before the chain is freed.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00013,"ranking_epss":0.02324,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2a6586ecfa4ce1413daaafee250d2590e05f1a33","https://git.kernel.org/stable/c/2f9a4ffeb763aec822f8ff3d1e82202d27d46d4b","https://git.kernel.org/stable/c/7017745068a9068904e1e7a1b170a5785647cc81","https://git.kernel.org/stable/c/71e99ee20fc3f662555118cf1159443250647533","https://git.kernel.org/stable/c/dbd0af8083dd201f07c49110b2ee93710abdff28","https://git.kernel.org/stable/c/f3fe58ce37926a10115ede527d59b91bcc05400a"],"published_time":"2026-03-04T13:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3351","summary":"Improper authorization in the API endpoint GET /1.0/certificates in Canonical LXD 6.6 on Linux allows an authenticated, restricted user to enumerate all certificate fingerprints trusted by the lxd server.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00023,"ranking_epss":0.06064,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/canonical/lxd/commit/d936c90d47cf0be1e9757df897f769e9887ebde1","https://github.com/canonical/lxd/pull/17738","https://github.com/canonical/lxd/security/advisories/GHSA-crmg-9m86-636r"],"published_time":"2026-03-03T13:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2749","summary":"Vulnerability in Centreon Centreon Open Tickets on Central Server on Linux (Centroen Open Ticket modules).This issue affects Centreon Open Tickets on Central Server: from all before 25.10.3, 24.10.8, 24.04.7.","cvss":9.9,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.9,"epss":0.00048,"ranking_epss":0.1511,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://thewatch.centreon.com/latest-security-bulletins-64/cve-2026-2749-centreon-open-tickets-critical-severity-5493"],"published_time":"2026-02-27T16:16:25","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0704","summary":"In affected version of Octopus Deploy it was possible to remove files and/or contents of files on the host using an API endpoint. The field lacked validation which could potentially result in ways to circumvent expected workflows.","cvss":9.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.1,"epss":0.00082,"ranking_epss":0.24251,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://advisories.octopus.com/post/2026/sa2026-01"],"published_time":"2026-02-25T13:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-0976","summary":"Information Exposure Vulnerability in Hitachi Ops Center API Configuration Manager, Hitachi Configuration Manager.This issue affects Hitachi Ops Center API Configuration Manager: from 10.0.0-00 before 11.0.4-00; Hitachi Configuration Manager: from 8.6.1-00 before 11.0.5-00.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00033,"ranking_epss":0.09739,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.hitachi.com/products/it/software/security/info/vuls/hitachi-sec-2026-110/index.html"],"published_time":"2026-02-25T05:17:13","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-5781","summary":"Information Exposure Vulnerability in Hitachi Ops Center API Configuration Manager, Hitachi Configuration Manager, Hitachi Device Manager allows Session Hijacking.This issue affects Hitachi Ops Center API Configuration Manager: from 10.0.0-00 before 11.0.5-00; Hitachi Configuration Manager: from 8.5.1-00 before 11.0.5-00; Hitachi Device Manager: from 8.4.1-00 before 8.6.5-00.","cvss":5.2,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.2,"epss":0.00015,"ranking_epss":0.03145,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.hitachi.com/products/it/software/security/info/vuls/hitachi-sec-2026-111/index.html"],"published_time":"2026-02-25T03:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3063","summary":"Inappropriate implementation in DevTools in Google Chrome prior to 145.0.7632.116 allowed an attacker who convinced a user to install a malicious extension to inject scripts or HTML into a privileged page via DevTools. (Chromium security severity: High)","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":6e-05,"ranking_epss":0.00419,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/485287859"],"published_time":"2026-02-23T23:16:16","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3061","summary":"Out of bounds read in Media in Google Chrome prior to 145.0.7632.116 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":9.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.1,"epss":0.0003,"ranking_epss":0.08655,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/482862710"],"published_time":"2026-02-23T23:16:15","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-3062","summary":"Out of bounds read and write in Tint in Google Chrome on Mac prior to 145.0.7632.116 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.0003,"ranking_epss":0.08655,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_23.html","https://issues.chromium.org/issues/483751167"],"published_time":"2026-02-23T23:16:15","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-30411","summary":"Sensitive data disclosure and manipulation due to improper authentication. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 39938, Acronis Cyber Protect 15 (Linux, Windows) before build 41800.","cvss":10.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":10.0,"epss":0.00038,"ranking_epss":0.11401,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8768"],"published_time":"2026-02-20T01:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-30412","summary":"Sensitive data disclosure and manipulation due to improper authentication. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 39938, Acronis Cyber Protect 15 (Linux, Windows) before build 41800.","cvss":10.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":10.0,"epss":0.00038,"ranking_epss":0.11401,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8598"],"published_time":"2026-02-20T01:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-30416","summary":"Sensitive data disclosure and manipulation due to missing authorization. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 39938, Acronis Cyber Protect 15 (Linux, Windows) before build 41800.","cvss":10.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":10.0,"epss":0.00014,"ranking_epss":0.025,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://security-advisory.acronis.com/advisories/SEC-8766"],"published_time":"2026-02-20T01:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23223","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix UAF in xchk_btree_check_block_owner\n\nWe cannot dereference bs->cur when trying to determine if bs->cur\naliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed.\nFix this by sampling before type before any freeing could happen.\nThe correct temporal ordering was broken when we removed xfs_btnum_t.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1c253e11225bc5167217897885b85093e17c2217","https://git.kernel.org/stable/c/1d411278dda293a507cb794db7d9ed3511c685c6","https://git.kernel.org/stable/c/ba5264610423d9653aa36920520902d83841bcfd","https://git.kernel.org/stable/c/ed82e7949f5cac3058f4100f3cd670531d41a266"],"published_time":"2026-02-18T16:22:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23224","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix UAF issue for file-backed mounts w/ directio option\n\n[    9.269940][ T3222] Call trace:\n[    9.269948][ T3222]  ext4_file_read_iter+0xac/0x108\n[    9.269979][ T3222]  vfs_iocb_iter_read+0xac/0x198\n[    9.269993][ T3222]  erofs_fileio_rq_submit+0x12c/0x180\n[    9.270008][ T3222]  erofs_fileio_submit_bio+0x14/0x24\n[    9.270030][ T3222]  z_erofs_runqueue+0x834/0x8ac\n[    9.270054][ T3222]  z_erofs_read_folio+0x120/0x220\n[    9.270083][ T3222]  filemap_read_folio+0x60/0x120\n[    9.270102][ T3222]  filemap_fault+0xcac/0x1060\n[    9.270119][ T3222]  do_pte_missing+0x2d8/0x1554\n[    9.270131][ T3222]  handle_mm_fault+0x5ec/0x70c\n[    9.270142][ T3222]  do_page_fault+0x178/0x88c\n[    9.270167][ T3222]  do_translation_fault+0x38/0x54\n[    9.270183][ T3222]  do_mem_abort+0x54/0xac\n[    9.270208][ T3222]  el0_da+0x44/0x7c\n[    9.270227][ T3222]  el0t_64_sync_handler+0x5c/0xf4\n[    9.270253][ T3222]  el0t_64_sync+0x1bc/0x1c0\n\nEROFS may encounter above panic when enabling file-backed mount w/\ndirectio mount option, the root cause is it may suffer UAF in below\nrace condition:\n\n- z_erofs_read_folio                          wq s_dio_done_wq\n - z_erofs_runqueue\n  - erofs_fileio_submit_bio\n   - erofs_fileio_rq_submit\n    - vfs_iocb_iter_read\n     - ext4_file_read_iter\n      - ext4_dio_read_iter\n       - iomap_dio_rw\n       : bio was submitted and return -EIOCBQUEUED\n                                              - dio_aio_complete_work\n                                               - dio_complete\n                                                - dio->iocb->ki_complete (erofs_fileio_ki_complete())\n                                                 - kfree(rq)\n                                                 : it frees iocb, iocb.ki_filp can be UAF in file_accessed().\n       - file_accessed\n       : access NULL file point\n\nIntroduce a reference count in struct erofs_fileio_rq, and initialize it\nas two, both erofs_fileio_ki_complete() and erofs_fileio_rq_submit() will\ndecrease reference count, the last one decreasing the reference count\nto zero will free rq.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1caf50ce4af096d0280d59a31abdd85703cd995c","https://git.kernel.org/stable/c/ae385826840a3c8e09bf38cac90adcd690716f57","https://git.kernel.org/stable/c/b2ee5e4d5446babd23ff7beb4e636be0fb3ea5aa","https://git.kernel.org/stable/c/d741534302f71c511eb0bb670b92eaa7df4a0aec"],"published_time":"2026-02-18T16:22:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23226","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: add chann_lock to protect ksmbd_chann_list xarray\n\nksmbd_chann_list xarray lacks synchronization, allowing use-after-free in\nmulti-channel sessions (between lookup_chann_list() and ksmbd_chann_del).\n\nAdds rw_semaphore chann_lock to struct ksmbd_session and protects\nall xa_load/xa_store/xa_erase accesses.","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00021,"ranking_epss":0.05716,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/36ef605c0395b94b826a8c8d6f2697071173de6e","https://git.kernel.org/stable/c/4c2ca31608521895dd742a43beca4b4d29762345","https://git.kernel.org/stable/c/4f3a06cc57976cafa8c6f716646be6c79a99e485","https://git.kernel.org/stable/c/e4a8a96a93d08570e0405cfd989a8a07e5b6ff33"],"published_time":"2026-02-18T16:22:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23227","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free\n\nExynos Virtual Display driver performs memory alloc/free operations\nwithout lock protection, which easily causes concurrency problem.\n\nFor example, use-after-free can occur in race scenario like this:\n```\n\tCPU0\t\t\t\tCPU1\t\t\t\tCPU2\n\t----\t\t\t\t----\t\t\t\t----\n  vidi_connection_ioctl()\n    if (vidi->connection) // true\n      drm_edid = drm_edid_alloc(); // alloc drm_edid\n      ...\n      ctx->raw_edid = drm_edid;\n      ...\n\t\t\t\t\t\t\t\tdrm_mode_getconnector()\n\t\t\t\t\t\t\t\t  drm_helper_probe_single_connector_modes()\n\t\t\t\t\t\t\t\t    vidi_get_modes()\n\t\t\t\t\t\t\t\t      if (ctx->raw_edid) // true\n\t\t\t\t\t\t\t\t        drm_edid_dup(ctx->raw_edid);\n\t\t\t\t\t\t\t\t          if (!drm_edid) // false\n\t\t\t\t\t\t\t\t          ...\n\t\t\t\tvidi_connection_ioctl()\n\t\t\t\t  if (vidi->connection) // false\n\t\t\t\t    drm_edid_free(ctx->raw_edid); // free drm_edid\n\t\t\t\t    ...\n\t\t\t\t\t\t\t\t          drm_edid_alloc(drm_edid->edid)\n\t\t\t\t\t\t\t\t            kmemdup(edid); // UAF!!\n\t\t\t\t\t\t\t\t            ...\n```\n\nTo prevent these vulns, at least in vidi_context, member variables related\nto memory alloc/free should be protected with ctx->lock.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":9e-05,"ranking_epss":0.00893,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0cd2c155740dbd00868ac5a8ae5d14cd6b9ed385","https://git.kernel.org/stable/c/1b24d3e8792bcc050c70e8e0dea6b49c4fc63b13","https://git.kernel.org/stable/c/52b330799e2d6f825ae2bb74662ec1b10eb954bb","https://git.kernel.org/stable/c/60b75407c172e1f341a8a5097c5cbc97dbbdd893","https://git.kernel.org/stable/c/92dd1f38d7db75374dcdaf54f1d79d67bffd54e5","https://git.kernel.org/stable/c/abfdf449fb3d7b42e85a1ad1c8694b768b1582f4"],"published_time":"2026-02-18T16:22:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23228","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\n\nOn kthread_run() failure in ksmbd_tcp_new_connection(), the transport is\nfreed via free_transport(), which does not decrement active_num_conn,\nleaking this counter.\n\nReplace free_transport() with ksmbd_tcp_disconnect().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05153,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/599271110c35f6b16e2e4e45b9fbd47ed378c982","https://git.kernel.org/stable/c/6dd2645cf080a75be31fa66063c7332b291f46f0","https://git.kernel.org/stable/c/77ffbcac4e569566d0092d5f22627dfc0896b553","https://git.kernel.org/stable/c/787769c8cc50416af7b8b1a36e6bcd6aaa7680aa","https://git.kernel.org/stable/c/7ddd69cd1338c6197e1b6b19cec60d99c8633e4f","https://git.kernel.org/stable/c/baf664fc90a6139a39a58333e4aaa390c10d45dc","https://git.kernel.org/stable/c/cd25e0d809531a67e9dd53b19012d27d2b13425f"],"published_time":"2026-02-18T16:22:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23229","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: virtio - Add spinlock protection with virtqueue notification\n\nWhen VM boots with one virtio-crypto PCI device and builtin backend,\nrun openssl benchmark command with multiple processes, such as\n  openssl speed -evp aes-128-cbc -engine afalg  -seconds 10 -multi 32\n\nopenssl processes will hangup and there is error reported like this:\n virtio_crypto virtio0: dataq.0:id 3 is not a head!\n\nIt seems that the data virtqueue need protection when it is handled\nfor virtio done notification. If the spinlock protection is added\nin virtcrypto_done_task(), openssl benchmark with multiple processes\nworks well.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00024,"ranking_epss":0.06392,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/49c57c6c108931a914ed94e3c0ddb974008260a3","https://git.kernel.org/stable/c/552475d0b6cece73a52c0fa5faa0ce45e99df74b","https://git.kernel.org/stable/c/8ee8ccfd60bf17cbdab91069d324b5302f4f3a30","https://git.kernel.org/stable/c/b505047ffc8057555900d2d3a005d033e6967382","https://git.kernel.org/stable/c/c0a0ded3bb7fd45f720faa48449a930153257d3a","https://git.kernel.org/stable/c/c9e594194795c86ca753ad6ed64c2762e9309d0d","https://git.kernel.org/stable/c/d6f0d586808689963e58fd739bed626ff5013b24","https://git.kernel.org/stable/c/e69a7b0a71b6561b3b6459f1fded8d589f2e8ac2"],"published_time":"2026-02-18T16:22:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23230","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: split cached_fid bitfields to avoid shared-byte RMW races\n\nis_open, has_lease and on_list are stored in the same bitfield byte in\nstruct cached_fid but are updated in different code paths that may run\nconcurrently. Bitfield assignments generate byte read–modify–write\noperations (e.g. `orb $mask, addr` on x86_64), so updating one flag can\nrestore stale values of the others.\n\nA possible interleaving is:\n    CPU1: load old byte (has_lease=1, on_list=1)\n    CPU2: clear both flags (store 0)\n    CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits\n\nTo avoid this class of races, convert these flags to separate bool\nfields.","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00023,"ranking_epss":0.0619,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3eaa22d688311c708b73f3c68bc6d0c8e3f0f77a","https://git.kernel.org/stable/c/4386f6af8aaedd0c5ad6f659b40cadcc8f423828","https://git.kernel.org/stable/c/4cfa4c37dcbcfd70866e856200ed8a2894cac578","https://git.kernel.org/stable/c/569fecc56bfe4df66f05734d67daef887746656b","https://git.kernel.org/stable/c/c4b9edd55987384a1f201d3d07ff71e448d79c1b","https://git.kernel.org/stable/c/ec306600d5ba7148c9dbf8f5a8f1f5c1a044a241"],"published_time":"2026-02-18T16:22:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23220","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths\n\nThe problem occurs when a signed request fails smb2 signature verification\ncheck. In __process_request(), if check_sign_req() returns an error,\nset_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called.\nset_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting\nnext_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain\nis lost. Consequently, is_chained_smb2_message() continues to point to\nthe same request header instead of advancing. If the header's NextCommand\nfield is non-zero, the function returns true, causing __handle_ksmbd_work()\nto repeatedly process the same failed request in an infinite loop.\nThis results in the kernel log being flooded with \"bad smb2 signature\"\nmessages and high CPU usage.\n\nThis patch fixes the issue by changing the return value from\nSERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that\nthe processing loop terminates immediately rather than attempting to\ncontinue from an invalidated offset.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05153,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/010eb01ce23b34b50531448b0da391c7f05a72af","https://git.kernel.org/stable/c/5accdc5b7f28a81bbc5880ac0b8886e60c86e8c8","https://git.kernel.org/stable/c/71b5e7c528315ca360a1825a4ad2f8ae48c5dc16","https://git.kernel.org/stable/c/9135e791ec2709bcf0cda0335535c74762489498","https://git.kernel.org/stable/c/f7b1c2f5642bbd60b1beef1f3298cbac81eb232c","https://git.kernel.org/stable/c/fb3b66bd72deb5543addaefa67963b34fb163a7b"],"published_time":"2026-02-18T16:22:31","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23221","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix use-after-free in driver_override_show()\n\nThe driver_override_show() function reads the driver_override string\nwithout holding the device_lock. However, driver_override_store() uses\ndriver_set_override(), which modifies and frees the string while holding\nthe device_lock.\n\nThis can result in a concurrent use-after-free if the string is freed\nby the store function while being read by the show function.\n\nFix this by holding the device_lock around the read operation.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02348,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/148891e95014b5dc5878acefa57f1940c281c431","https://git.kernel.org/stable/c/1d6bd6183e723a7b256ff34bbb5b498b5f4f2ec0","https://git.kernel.org/stable/c/a2ae33e1c6361e960a4d00f7cf75d880b54f9528","https://git.kernel.org/stable/c/b1983840287303e0dfb401b1b6cecc5ea7471e90","https://git.kernel.org/stable/c/c424e72cfa67e7e1477035058a8a659f2c0ea637","https://git.kernel.org/stable/c/c71dfb7833db7af652ee8f65011f14c97c47405d","https://git.kernel.org/stable/c/dd8ba8c0c3f3916d4ee1e3a09da9cd5caff5d227"],"published_time":"2026-02-18T16:22:31","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23222","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly\n\nThe existing allocation of scatterlists in omap_crypto_copy_sg_lists()\nwas allocating an array of scatterlist pointers, not scatterlist objects,\nresulting in a 4x too small allocation.\n\nUse sizeof(*new_sg) to get the correct object size.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03893,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1562b1fb7e17c1b3addb15e125c718b2be7f5512","https://git.kernel.org/stable/c/2ed27b5a1174351148c3adbfc0cd86d54072ba2e","https://git.kernel.org/stable/c/31aff96a41ae6f1f1687c065607875a27c364da8","https://git.kernel.org/stable/c/6edf8df4bd29f7bfd245b67b2c31d905f1cfc14b","https://git.kernel.org/stable/c/79f95b51d4278044013672c27519ae88d07013d8","https://git.kernel.org/stable/c/953c81941b0ad373674656b8767c00234ebf17ac","https://git.kernel.org/stable/c/c184341920ed78b6466360ed7b45b8922586c38f","https://git.kernel.org/stable/c/d1836c628cb72734eb5f7dfd4c996a9c18bba3ad"],"published_time":"2026-02-18T16:22:31","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71233","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: Avoid creating sub-groups asynchronously\n\nThe asynchronous creation of sub-groups by a delayed work could lead to a\nNULL pointer dereference when the driver directory is removed before the\nwork completes.\n\nThe crash can be easily reproduced with the following commands:\n\n  # cd /sys/kernel/config/pci_ep/functions/pci_epf_test\n  # for i in {1..20}; do mkdir test && rmdir test; done\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000088\n  ...\n  Call Trace:\n   configfs_register_group+0x3d/0x190\n   pci_epf_cfs_work+0x41/0x110\n   process_one_work+0x18f/0x350\n   worker_thread+0x25a/0x3a0\n\nFix this issue by using configfs_add_default_group() API which does not\nhave the deadlock problem as configfs_register_group() and does not require\nthe delayed work handler.\n\n[mani: slightly reworded the description and added stable list]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05153,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/24a253c3aa6d9a2cde46158ce9782e023bfbf32d","https://git.kernel.org/stable/c/5f609b3bffd4207cf9f2c9b41e1978457a5a1ea9","https://git.kernel.org/stable/c/73cee890adafa2c219bb865356e08e7f82423fe5","https://git.kernel.org/stable/c/7c5c7d06bd1f86d2c3ebe62be903a4ba42db4d2c","https://git.kernel.org/stable/c/8cb905eca73944089a0db01443c7628a9e87012d","https://git.kernel.org/stable/c/d9af3cf58bb4c8d6dea4166011c780756b1138b5","https://git.kernel.org/stable/c/fa9fb38f5fe9c80094c2138354d45cdc8d094d69"],"published_time":"2026-02-18T16:22:30","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71234","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_add\n\nThe driver does not set hw->sta_data_size, which causes mac80211 to\nallocate insufficient space for driver private station data in\n__sta_info_alloc(). When rtl8xxxu_sta_add() accesses members of\nstruct rtl8xxxu_sta_info through sta->drv_priv, this results in a\nslab-out-of-bounds write.\n\nKASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter:\n\n  BUG: KASAN: slab-out-of-bounds in rtl8xxxu_sta_add+0x31c/0x346\n  Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12\n\nSet hw->sta_data_size to sizeof(struct rtl8xxxu_sta_info) during\nprobe, similar to how hw->vif_data_size is configured. This ensures\nmac80211 allocates sufficient space for the driver's per-station\nprivate data.\n\nTested on StarFive VisionFive 2 v1.2A board.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/116f7bd8160c6b37d1c6939385abf90f6f6ed2f5","https://git.kernel.org/stable/c/5d810ba377eddee95d30766d360a14efbb3d1872","https://git.kernel.org/stable/c/86c946bcc00f6390ef65e9614ae60a9377e454f8","https://git.kernel.org/stable/c/9a0f3fa6ecd0c9c32dbc367a57482bbf7c7d25bf"],"published_time":"2026-02-18T16:22:30","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71235","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Delay module unload while fabric scan in progress\n\nSystem crash seen during load/unload test in a loop.\n\n[105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086\n[105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0\n[105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000\n[105954.384923] FS:  0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000\n[105954.384925] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0\n[105954.384928] PKRU: 55555554\n[105954.384929] Call Trace:\n[105954.384931]  <IRQ>\n[105954.384934]  qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx]\n[105954.384962]  ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx]\n[105954.384980]  ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx]\n[105954.384999]  ? __wake_up_common+0x80/0x190\n[105954.385004]  ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx]\n[105954.385023]  ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx]\n[105954.385040]  ? __handle_irq_event_percpu+0x3d/0x190\n[105954.385044]  ? handle_irq_event+0x58/0xb0\n[105954.385046]  ? handle_edge_irq+0x93/0x240\n[105954.385050]  ? __common_interrupt+0x41/0xa0\n[105954.385055]  ? common_interrupt+0x3e/0xa0\n[105954.385060]  ? asm_common_interrupt+0x22/0x40\n\nThe root cause of this was that there was a free (dma_free_attrs) in the\ninterrupt context.  There was a device discovery/fabric scan in\nprogress.  A module unload was issued which set the UNLOADING flag.  As\npart of the discovery, after receiving an interrupt a work queue was\nscheduled (which involved a work to be queued).  Since the UNLOADING\nflag is set, the work item was not allocated and the mapped memory had\nto be freed.  The free occurred in interrupt context leading to system\ncrash.  Delay the driver unload until the fabric scan is complete to\navoid the crash.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00024,"ranking_epss":0.06392,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/528b2f1027edfb52af0171f0f4b227fb356dde05","https://git.kernel.org/stable/c/7062eb0c488f35730334daad9495d9265c574853","https://git.kernel.org/stable/c/8890bf450e0b6b283f48ac619fca5ac2f14ddd62","https://git.kernel.org/stable/c/891f9969a29e9767a453cef4811c8d2472ccab49","https://git.kernel.org/stable/c/984dc1a51bf6fc3ca4e726abe790ec38952935d8","https://git.kernel.org/stable/c/c068ebbaf52820d6bdefb9b405a1e426663c635a","https://git.kernel.org/stable/c/d70f71d4c92bcb8b6a21ac62d4ea3e87721f4f32","https://git.kernel.org/stable/c/d8af012f92eee021c6ebb7093e65813c926c336b"],"published_time":"2026-02-18T16:22:30","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71236","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Validate sp before freeing associated memory\n\nSystem crash with the following signature\n[154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete\n[154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3.\n[154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5.\n[154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000.\n[154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000.\n[154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).\n[154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).\n[154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8\n[154565.553080] #PF: supervisor read access in kernel mode\n[154565.553082] #PF: error_code(0x0000) - not-present page\n[154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0\n[154565.553089] Oops: 0000 1 PREEMPT SMP PTI\n[154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G           OE     -------  ---  5.14.0-503.11.1.el9_5.x86_64 #1\n[154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024\n[154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]\n[154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b\n[154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286\n[154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002\n[154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47\n[154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a\n[154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0\n[154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000\n[154565.553152] FS:  0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000\n[154565.553154] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0\n[154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[154565.553159] PKRU: 55555554\n[154565.553160] Call Trace:\n[154565.553162]  <TASK>\n[154565.553165]  ? show_trace_log_lvl+0x1c4/0x2df\n[154565.553172]  ? show_trace_log_lvl+0x1c4/0x2df\n[154565.553177]  ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]\n[154565.553215]  ? __die_body.cold+0x8/0xd\n[154565.553218]  ? page_fault_oops+0x134/0x170\n[154565.553223]  ? snprintf+0x49/0x70\n[154565.553229]  ? exc_page_fault+0x62/0x150\n[154565.553238]  ? asm_exc_page_fault+0x22/0x30\n\nCheck for sp being non NULL before freeing any associated memory","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00024,"ranking_epss":0.06392,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/044131fce27749cb6ea986baf861fbe63c6d8a17","https://git.kernel.org/stable/c/1a9585e4c58d1f1662b3ca46110ed4f583082ce5","https://git.kernel.org/stable/c/40ae93668226b610edb952c6036f607a61750b57","https://git.kernel.org/stable/c/85c0890fea6baeba9c4ae6ae090182cbb1a93fb2","https://git.kernel.org/stable/c/944378ead9a48d5d50e9e3cc85e4cdb911c37ca1","https://git.kernel.org/stable/c/949010291bb941d53733ed08a33454254d9afb1b","https://git.kernel.org/stable/c/a46f81c1e627437de436e517f5fd4b725c15a1e6","https://git.kernel.org/stable/c/b6df15aec8c3441357d4da0eaf4339eb20f5999f"],"published_time":"2026-02-18T16:22:30","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71237","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: Fix potential block overflow that cause system hang\n\nWhen a user executes the FITRIM command, an underflow can occur when\ncalculating nblocks if end_block is too small. Since nblocks is of\ntype sector_t, which is u64, a negative nblocks value will become a\nvery large positive integer. This ultimately leads to the block layer\nfunction __blkdev_issue_discard() taking an excessively long time to\nprocess the bio chain, and the ns_segctor_sem lock remains held for a\nlong period. This prevents other tasks from acquiring the ns_segctor_sem\nlock, resulting in the hang reported by syzbot in [1].\n\nIf the ending block is too small, typically if it is smaller than 4KiB\nrange, depending on the usage of the segment 0, it may be possible to\nattempt a discard request beyond the device size causing the hang.\n\nExiting successfully and assign the discarded size (0 in this case)\nto range->len.\n\nAlthough the start and len values in the user input range are too small,\na conservative strategy is adopted here to safely ignore them, which is\nequivalent to a no-op; it will not perform any trimming and will not\nthrow an error.\n\n[1]\ntask:segctord state:D stack:28968 pid:6093 tgid:6093  ppid:2 task_flags:0x200040 flags:0x00080000\nCall Trace:\n rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272\n nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]\n nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684\n\n[ryusuke: corrected part of the commit message about the consequences]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00024,"ranking_epss":0.06392,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2438982f635e6cc2009be68ba2efb2998727d8d4","https://git.kernel.org/stable/c/4aa45f841413cca81882602b4042c53502f34cad","https://git.kernel.org/stable/c/6457d3ee41a4c15082ac49c5aa7fb933b4a043f3","https://git.kernel.org/stable/c/b8c5ee234bd54f1447c846101fdaef2cf70c2149","https://git.kernel.org/stable/c/ba18e5f22f26aa4ef78bc3e81f639d1d4f3845e6","https://git.kernel.org/stable/c/df1e20796c9f3d541cca47fb72e4369ea135642d","https://git.kernel.org/stable/c/ea2278657ad0d62596589fbe2caf995e189e65e7","https://git.kernel.org/stable/c/ed527ef0c264e4bed6c7b2a158ddf516b17f5f66"],"published_time":"2026-02-18T16:22:30","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71229","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: Fix alignment fault in rtw_core_enable_beacon()\n\nrtw_core_enable_beacon() reads 4 bytes from an address that is not a\nmultiple of 4. This results in a crash on some systems.\n\nDo 1 byte reads/writes instead.\n\nUnable to handle kernel paging request at virtual address ffff8000827e0522\nMem abort info:\n  ESR = 0x0000000096000021\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x21: alignment fault\nData abort info:\n  ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nswapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000005492000\n[ffff8000827e0522] pgd=0000000000000000, p4d=10000001021d9403, pud=10000001021da403, pmd=100000011061c403, pte=00780000f3200f13\nInternal error: Oops: 0000000096000021 [#1]  SMP\nModules linked in: [...] rtw88_8822ce rtw88_8822c rtw88_pci rtw88_core [...]\nCPU: 0 UID: 0 PID: 73 Comm: kworker/u32:2 Tainted: G        W           6.17.9 #1-NixOS VOLUNTARY\nTainted: [W]=WARN\nHardware name: FriendlyElec NanoPC-T6 LTS (DT)\nWorkqueue: phy0 rtw_c2h_work [rtw88_core]\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : rtw_pci_read32+0x18/0x40 [rtw88_pci]\nlr : rtw_core_enable_beacon+0xe0/0x148 [rtw88_core]\nsp : ffff800080cc3ca0\nx29: ffff800080cc3ca0 x28: ffff0001031fc240 x27: ffff000102100828\nx26: ffffd2cb7c9b4088 x25: ffff0001031fc2c0 x24: ffff000112fdef00\nx23: ffff000112fdef18 x22: ffff000111c29970 x21: 0000000000000001\nx20: 0000000000000001 x19: ffff000111c22040 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000 x9 : ffffd2cb6507c090\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000007f10 x1 : 0000000000000522 x0 : ffff8000827e0522\nCall trace:\n rtw_pci_read32+0x18/0x40 [rtw88_pci] (P)\n rtw_hw_scan_chan_switch+0x124/0x1a8 [rtw88_core]\n rtw_fw_c2h_cmd_handle+0x254/0x290 [rtw88_core]\n rtw_c2h_work+0x50/0x98 [rtw88_core]\n process_one_work+0x178/0x3f8\n worker_thread+0x208/0x418\n kthread+0x120/0x220\n ret_from_fork+0x10/0x20\nCode: d28fe202 8b020000 f9524400 8b214000 (b9400000)\n---[ end trace 0000000000000000 ]---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0177aa828d966117ea30a44f2e1890fdb356118e","https://git.kernel.org/stable/c/13394550441557115bb74f6de9778c165755a7ab","https://git.kernel.org/stable/c/653f8b6a091538b084715f259900f62c2ec1c6cf","https://git.kernel.org/stable/c/71dee092903adb496fe1f357b267d94087b679e0","https://git.kernel.org/stable/c/7d31dde1bd8678115329e46dc8d7afb63c176b74"],"published_time":"2026-02-18T16:22:29","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71230","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nhfs: ensure sb->s_fs_info is always cleaned up\n\nWhen hfs was converted to the new mount api a bug was introduced by\nchanging the allocation pattern of sb->s_fs_info. If setup_bdev_super()\nfails after a new superblock has been allocated by sget_fc(), but before\nhfs_fill_super() takes ownership of the filesystem-specific s_fs_info\ndata it was leaked.\n\nFix this by freeing sb->s_fs_info in hfs_kill_super().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/05ce49a902be15dc93854cbfc20161205a9ee446","https://git.kernel.org/stable/c/399219831514126bc9541e8eadefe02c6fbd9166","https://git.kernel.org/stable/c/46c1d56ad321fb024761abd9af61a0cb616cf2f6"],"published_time":"2026-02-18T16:22:29","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71231","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_mode\n\nThe local variable 'i' is initialized with -EINVAL, but the for loop\nimmediately overwrites it and -EINVAL is never returned.\n\nIf no empty compression mode can be found, the function would return the\nout-of-bounds index IAA_COMP_MODES_MAX, which would cause an invalid\narray access in add_iaa_compression_mode().\n\nFix both issues by returning either a valid index or -EINVAL.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/48329301969f6d21b2ef35f678e40f72b59eac94","https://git.kernel.org/stable/c/c77b33b58512708bd5603f48465f018c8b748847","https://git.kernel.org/stable/c/d75207465eed20bc9b0daa4a0927de9568996067","https://git.kernel.org/stable/c/de16f5bca05cace238d237791ed1b6e9d22dab60"],"published_time":"2026-02-18T16:22:29","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71232","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Free sp in error path to fix system crash\n\nSystem crash seen during load/unload test in a loop,\n\n[61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X.\n[61110.467494] =============================================================================\n[61110.467498] BUG qla2xxx_srbs (Tainted: G           OE    --------  --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown()\n[61110.467501] -----------------------------------------------------------------------------\n\n[61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff)\n[61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1\n[61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023\n[61110.467515] Call Trace:\n[61110.467516]  <TASK>\n[61110.467519]  dump_stack_lvl+0x34/0x48\n[61110.467526]  slab_err.cold+0x53/0x67\n[61110.467534]  __kmem_cache_shutdown+0x16e/0x320\n[61110.467540]  kmem_cache_destroy+0x51/0x160\n[61110.467544]  qla2x00_module_exit+0x93/0x99 [qla2xxx]\n[61110.467607]  ? __do_sys_delete_module.constprop.0+0x178/0x280\n[61110.467613]  ? syscall_trace_enter.constprop.0+0x145/0x1d0\n[61110.467616]  ? do_syscall_64+0x5c/0x90\n[61110.467619]  ? exc_page_fault+0x62/0x150\n[61110.467622]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[61110.467626]  </TASK>\n[61110.467627] Disabling lock debugging due to kernel taint\n[61110.467635] Object 0x0000000026f7e6e6 @offset=16000\n[61110.467639] ------------[ cut here ]------------\n[61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx]\n[61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160\n[61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G    B      OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1\n[61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023\n[61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160\n[61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89\n[61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282\n[61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027\n[61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0\n[61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7\n[61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000\n[61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[61110.467733] FS:  00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000\n[61110.467734] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0\n[61110.467736] PKRU: 55555554\n[61110.467737] Call Trace:\n[61110.467738]  <TASK>\n[61110.467739]  qla2x00_module_exit+0x93/0x99 [qla2xxx]\n[61110.467755]  ? __do_sys_delete_module.constprop.0+0x178/0x280\n\nFree sp in the error path to fix the crash.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00024,"ranking_epss":0.06392,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/05fcd590e5fbbb3e9e1b4fc6c23c98a1d38cf256","https://git.kernel.org/stable/c/19ac050ef09a2f0a9d9787540f77bb45cf9033e8","https://git.kernel.org/stable/c/7adbd2b7809066c75f0433e5e2a8e114b429f30f","https://git.kernel.org/stable/c/8e7597b4efee6143439641bc6522f247d585e060","https://git.kernel.org/stable/c/aed16d37696f494288a291b4b477484ed0be774b","https://git.kernel.org/stable/c/b410ab8b9431d6d63d04caa1d69909fcc8b25eae","https://git.kernel.org/stable/c/b74408de1f2264220979f0c6a5a9d5e50b5b534b","https://git.kernel.org/stable/c/f04840512438ac025dea6e357d80a986b28bbe4c"],"published_time":"2026-02-18T16:22:29","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23217","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: trace: fix snapshot deadlock with sbi ecall\n\nIf sbi_ecall.c's functions are traceable,\n\necho \"__sbi_ecall:snapshot\" > /sys/kernel/tracing/set_ftrace_filter\n\nmay get the kernel into a deadlock.\n\n(Functions in sbi_ecall.c are excluded from tracing if\nCONFIG_RISCV_ALTERNATIVE_EARLY is set.)\n\n__sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code\nraises an IPI interrupt, which results in another call to __sbi_ecall\nand another snapshot...\n\nAll it takes to get into this endless loop is one initial __sbi_ecall.\nOn RISC-V systems without SSTC extension, the clock events in\ntimer-riscv.c issue periodic sbi ecalls, making the problem easy to\ntrigger.\n\nAlways exclude the sbi_ecall.c functions from tracing to fix the\npotential deadlock.\n\nsbi ecalls can easiliy be logged via trace events, excluding ecall\nfunctions from function tracing is not a big limitation.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03072,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/b0d7f5f0c9f05f1b6d4ee7110f15bef9c11f9df0","https://git.kernel.org/stable/c/b1f8285bc8e3508c1fde23b5205f1270215d4984"],"published_time":"2026-02-18T15:18:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23218","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: loongson-64bit: Fix incorrect NULL check after devm_kcalloc()\n\nFix incorrect NULL check in loongson_gpio_init_irqchip().\nThe function checks chip->parent instead of chip->irq.parents.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/e34f77b09080c86c929153e2a72da26b4f8947ff","https://git.kernel.org/stable/c/e71e3fa90a15134113f61343392e887cd1f4bf7c"],"published_time":"2026-02-18T15:18:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23219","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab: Add alloc_tagging_slab_free_hook for memcg_alloc_abort_single\n\nWhen CONFIG_MEM_ALLOC_PROFILING_DEBUG is enabled, the following warning\nmay be noticed:\n\n[ 3959.023862] ------------[ cut here ]------------\n[ 3959.023891] alloc_tag was not cleared (got tag for lib/xarray.c:378)\n[ 3959.023947] WARNING: ./include/linux/alloc_tag.h:155 at alloc_tag_add+0x128/0x178, CPU#6: mkfs.ntfs/113998\n[ 3959.023978] Modules linked in: dns_resolver tun brd overlay exfat btrfs blake2b libblake2b xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel ext4 crc16 mbcache jbd2 rfkill sunrpc vfat fat sg fuse nfnetlink sr_mod virtio_gpu cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper ghash_ce drm sm4 backlight virtio_net net_failover virtio_scsi failover virtio_console virtio_blk virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod i2c_dev aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject]\n[ 3959.024170] CPU: 6 UID: 0 PID: 113998 Comm: mkfs.ntfs Kdump: loaded Tainted: G        W           6.19.0-rc7+ #7 PREEMPT(voluntary)\n[ 3959.024182] Tainted: [W]=WARN\n[ 3959.024186] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022\n[ 3959.024192] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 3959.024199] pc : alloc_tag_add+0x128/0x178\n[ 3959.024207] lr : alloc_tag_add+0x128/0x178\n[ 3959.024214] sp : ffff80008b696d60\n[ 3959.024219] x29: ffff80008b696d60 x28: 0000000000000000 x27: 0000000000000240\n[ 3959.024232] x26: 0000000000000000 x25: 0000000000000240 x24: ffff800085d17860\n[ 3959.024245] x23: 0000000000402800 x22: ffff0000c0012dc0 x21: 00000000000002d0\n[ 3959.024257] x20: ffff0000e6ef3318 x19: ffff800085ae0410 x18: 0000000000000000\n[ 3959.024269] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 3959.024281] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600064101293\n[ 3959.024292] x11: 1fffe00064101292 x10: ffff600064101292 x9 : dfff800000000000\n[ 3959.024305] x8 : 00009fff9befed6e x7 : ffff000320809493 x6 : 0000000000000001\n[ 3959.024316] x5 : ffff000320809490 x4 : ffff600064101293 x3 : ffff800080691838\n[ 3959.024328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000d5bcd640\n[ 3959.024340] Call trace:\n[ 3959.024346]  alloc_tag_add+0x128/0x178 (P)\n[ 3959.024355]  __alloc_tagging_slab_alloc_hook+0x11c/0x1a8\n[ 3959.024362]  kmem_cache_alloc_lru_noprof+0x1b8/0x5e8\n[ 3959.024369]  xas_alloc+0x304/0x4f0\n[ 3959.024381]  xas_create+0x1e0/0x4a0\n[ 3959.024388]  xas_store+0x68/0xda8\n[ 3959.024395]  __filemap_add_folio+0x5b0/0xbd8\n[ 3959.024409]  filemap_add_folio+0x16c/0x7e0\n[ 3959.024416]  __filemap_get_folio_mpol+0x2dc/0x9e8\n[ 3959.024424]  iomap_get_folio+0xfc/0x180\n[ 3959.024435]  __iomap_get_folio+0x2f8/0x4b8\n[ 3959.024441]  iomap_write_begin+0x198/0xc18\n[ 3959.024448]  iomap_write_iter+0x2ec/0x8f8\n[ 3959.024454]  iomap_file_buffered_write+0x19c/0x290\n[ 3959.024461]  blkdev_write_iter+0x38c/0x978\n[ 3959.024470]  vfs_write+0x4d4/0x928\n[ 3959.024482]  ksys_write+0xfc/0x1f8\n[ 3959.024489]  __arm64_sys_write+0x74/0xb0\n[ 3959.024496]  invoke_syscall+0xd4/0x258\n[ 3959.024507]  el0_svc_common.constprop.0+0xb4/0x240\n[ 3959.024514]  do_el0_svc+0x48/0x68\n[ 3959.024520]  el0_svc+0x40/0xf8\n[ 3959.024526]  el0t_64_sync_handler+0xa0/0xe8\n[ 3959.024533]  el0t_64_sync+0x1ac/0x1b0\n[ 3959.024540] ---[ end trace 0000000000000000 ]---\n\nWhen __memcg_slab_post_alloc_hook() fails, there are two different\nfree paths depending on whether size == 1 or size != 1. In the\nkmem_cache_free_bulk() path, we do call alloc_tagging_slab_free_hook().\nHowever, in memcg_alloc_abort_single() we don't, the above warning will be\ntriggered on the next allocation.\n\nTherefore, add alloc_tagging_slab_free_hook() to the\nmemcg_alloc_abort_single() path.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/b8bc72587c79fe52c14732e16a766b6eded00707","https://git.kernel.org/stable/c/e6c53ead2d8fa73206e0a63e9cd9aea6bc929837","https://git.kernel.org/stable/c/e8af57e090790983591f6927b3d89ee6383f8c1e"],"published_time":"2026-02-18T15:18:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23211","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm, swap: restore swap_space attr aviod kernel panic\n\ncommit 8b47299a411a (\"mm, swap: mark swap address space ro and add context\ndebug check\") made the swap address space read-only.  It may lead to\nkernel panic if arch_prepare_to_swap returns a failure under heavy memory\npressure as follows,\n\nel1_abort+0x40/0x64\nel1h_64_sync_handler+0x48/0xcc\nel1h_64_sync+0x84/0x88\nerrseq_set+0x4c/0xb8 (P)\n__filemap_set_wb_err+0x20/0xd0\nshrink_folio_list+0xc20/0x11cc\nevict_folios+0x1520/0x1be4\ntry_to_shrink_lruvec+0x27c/0x3dc\nshrink_one+0x9c/0x228\nshrink_node+0xb3c/0xeac\ndo_try_to_free_pages+0x170/0x4f0\ntry_to_free_pages+0x334/0x534\n__alloc_pages_direct_reclaim+0x90/0x158\n__alloc_pages_slowpath+0x334/0x588\n__alloc_frozen_pages_noprof+0x224/0x2fc\n__folio_alloc_noprof+0x14/0x64\nvma_alloc_zeroed_movable_folio+0x34/0x44\ndo_pte_missing+0xad4/0x1040\nhandle_mm_fault+0x4a4/0x790\ndo_page_fault+0x288/0x5f8\ndo_translation_fault+0x38/0x54\ndo_mem_abort+0x54/0xa8\n\nRestore swap address space as not ro to avoid the panic.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/a0f3c0845a4ff68d403c568266d17e9cc553e561","https://git.kernel.org/stable/c/b0020cbd26380177b9fb8b7e75a8f7bdba79db20"],"published_time":"2026-02-18T15:18:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23212","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: annotate data-races around slave->last_rx\n\nslave->last_rx and slave->target_last_arp_rx[...] can be read and written\nlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.\n\nsyzbot reported:\n\nBUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1:\n  bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n  bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n  __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n  __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n  __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n  netif_receive_skb_internal net/core/dev.c:6351 [inline]\n  netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n...\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0:\n  bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n  bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n  __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n  __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n  __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n  netif_receive_skb_internal net/core/dev.c:6351 [inline]\n  netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n  br_netif_receive_skb net/bridge/br_input.c:30 [inline]\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n...\n\nvalue changed: 0x0000000100005365 -> 0x0000000100005366","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00014,"ranking_epss":0.02431,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/8c0be3277e7aefb2f900fc37ca3fe7df362e26f5","https://git.kernel.org/stable/c/a7516cb0165926d308187e231ccd330e5e3ebff7","https://git.kernel.org/stable/c/b956289b83887e0a306067b6003c3fcd81bfdf84","https://git.kernel.org/stable/c/bd98324e327e41de04b13e372cc16f73150df254","https://git.kernel.org/stable/c/f6c3665b6dc53c3ab7d31b585446a953a74340ef"],"published_time":"2026-02-18T15:18:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23213","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Disable MMIO access during SMU Mode 1 reset\n\nDuring Mode 1 reset, the ASIC undergoes a reset cycle and becomes\ntemporarily inaccessible via PCIe. Any attempt to access MMIO registers\nduring this window (e.g., from interrupt handlers or other driver threads)\ncan result in uncompleted PCIe transactions, leading to NMI panics or\nsystem hangs.\n\nTo prevent this, set the `no_hw_access` flag to true immediately after\ntriggering the reset. This signals other driver components to skip\nregister accesses while the device is offline.\n\nA memory barrier `smp_mb()` is added to ensure the flag update is\nglobally visible to all cores before the driver enters the sleep/wait\nstate.\n\n(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0de604d0357d0d22cbf03af1077d174b641707b6","https://git.kernel.org/stable/c/c1853ebbec980d5c05d431bfd6ded73b1363fd00","https://git.kernel.org/stable/c/cd7ff7fd3e4b77f0b5a292e0926532eaa07c5162"],"published_time":"2026-02-18T15:18:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23214","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject new transactions if the fs is fully read-only\n\n[BUG]\nThere is a bug report where a heavily fuzzed fs is mounted with all\nrescue mount options, which leads to the following warnings during\nunmount:\n\n  BTRFS: Transaction aborted (error -22)\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted\n  6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline]\n  RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611\n  Call Trace:\n   <TASK>\n   btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705\n   btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157\n   btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517\n   btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708\n   btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130\n   btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499\n   btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628\n   evict+0x5f4/0xae0 fs/inode.c:837\n   __dentry_kill+0x209/0x660 fs/dcache.c:670\n   finish_dput+0xc9/0x480 fs/dcache.c:879\n   shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661\n   generic_shutdown_super+0x67/0x2c0 fs/super.c:621\n   kill_anon_super+0x3b/0x70 fs/super.c:1289\n   btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127\n   deactivate_locked_super+0xbc/0x130 fs/super.c:474\n   cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318\n   task_work_run+0x1d4/0x260 kernel/task_work.c:233\n   exit_task_work include/linux/task_work.h:40 [inline]\n   do_exit+0x694/0x22f0 kernel/exit.c:971\n   do_group_exit+0x21c/0x2d0 kernel/exit.c:1112\n   __do_sys_exit_group kernel/exit.c:1123 [inline]\n   __se_sys_exit_group kernel/exit.c:1121 [inline]\n   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121\n   x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232\n   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x44f639\n  Code: Unable to access opcode bytes at 0x44f60f.\n  RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\n  RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639\n  RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001\n  RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0\n  R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n   </TASK>\n\nSince rescue mount options will mark the full fs read-only, there should\nbe no new transaction triggered.\n\nBut during unmount we will evict all inodes, which can trigger a new\ntransaction, and triggers warnings on a heavily corrupted fs.\n\n[CAUSE]\nBtrfs allows new transaction even on a read-only fs, this is to allow\nlog replay happen even on read-only mounts, just like what ext4/xfs do.\n\nHowever with rescue mount options, the fs is fully read-only and cannot\nbe remounted read-write, thus in that case we should also reject any new\ntransactions.\n\n[FIX]\nIf we find the fs has rescue mount options, we should treat the fs as\nerror, so that no new transaction can be started.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1972f44c189c8aacde308fa9284e474c1a5cbd9f","https://git.kernel.org/stable/c/3228b2eceb6c3d7e237f8a5330113dbd164fb90d","https://git.kernel.org/stable/c/a928eecf030a9a5dc5f5ca98332699f379b91963"],"published_time":"2026-02-18T15:18:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23215","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/vmware: Fix hypercall clobbers\n\nFedora QA reported the following panic:\n\n  BUG: unable to handle page fault for address: 0000000040003e54\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0002) - not-present page\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025\n  RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90\n  ..\n  Call Trace:\n   vmmouse_report_events+0x13e/0x1b0\n   psmouse_handle_byte+0x15/0x60\n   ps2_interrupt+0x8a/0xd0\n   ...\n\nbecause the QEMU VMware mouse emulation is buggy, and clears the top 32\nbits of %rdi that the kernel kept a pointer in.\n\nThe QEMU vmmouse driver saves and restores the register state in a\n\"uint32_t data[6];\" and as a result restores the state with the high\nbits all cleared.\n\nRDI originally contained the value of a valid kernel stack address\n(0xff5eeb3240003e54).  After the vmware hypercall it now contains\n0x40003e54, and we get a page fault as a result when it is dereferenced.\n\nThe proper fix would be in QEMU, but this works around the issue in the\nkernel to keep old setups working, when old kernels had not happened to\nkeep any state in %rdi over the hypercall.\n\nIn theory this same issue exists for all the hypercalls in the vmmouse\ndriver; in practice it has only been seen with vmware_hypercall3() and\nvmware_hypercall4().  For now, just mark RDI/RSI as clobbered for those\ntwo calls.  This should have a minimal effect on code generation overall\nas it should be rare for the compiler to want to make RDI/RSI live\nacross hypercalls.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2687c848e57820651b9f69d30c4710f4219f7dbf","https://git.kernel.org/stable/c/2f467a92df61eb516a4ec36ee16234dd4e5ccf00","https://git.kernel.org/stable/c/feb603a69f830acb58f78d604f0c29e63cd38f87"],"published_time":"2026-02-18T15:18:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23216","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()\n\nIn iscsit_dec_conn_usage_count(), the function calls complete() while\nholding the conn->conn_usage_lock. As soon as complete() is invoked, the\nwaiter (such as iscsit_close_connection()) may wake up and proceed to free\nthe iscsit_conn structure.\n\nIf the waiter frees the memory before the current thread reaches\nspin_unlock_bh(), it results in a KASAN slab-use-after-free as the function\nattempts to release a lock within the already-freed connection structure.\n\nFix this by releasing the spinlock before calling complete().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02348,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/275016a551ba1a068a3bd6171b18611726b67110","https://git.kernel.org/stable/c/3835e49e146a4e6e7787b29465f1a23379b6ec44","https://git.kernel.org/stable/c/48fe983e92de2c59d143fe38362ad17ba23ec7f3","https://git.kernel.org/stable/c/73b487d44bf4f92942629d578381f89c326ff77f","https://git.kernel.org/stable/c/8518f072fc92921418cd9ed4268dd4f3e9a8fd75","https://git.kernel.org/stable/c/9411a89e9e7135cc459178fa77a3f1d6191ae903","https://git.kernel.org/stable/c/ba684191437380a07b27666eb4e72748be1ea201"],"published_time":"2026-02-18T15:18:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71225","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmd: suspend array while updating raid_disks via sysfs\n\nIn raid1_reshape(), freeze_array() is called before modifying the r1bio\nmemory pool (conf->r1bio_pool) and conf->raid_disks, and\nunfreeze_array() is called after the update is completed.\n\nHowever, freeze_array() only waits until nr_sync_pending and\n(nr_pending - nr_queued) of all buckets reaches zero. When an I/O error\noccurs, nr_queued is increased and the corresponding r1bio is queued to\neither retry_list or bio_end_io_list. As a result, freeze_array() may\nunblock before these r1bios are released.\n\nThis can lead to a situation where conf->raid_disks and the mempool have\nalready been updated while queued r1bios, allocated with the old\nraid_disks value, are later released. Consequently, free_r1bio() may\naccess memory out of bounds in put_all_bios() and release r1bios of the\nwrong size to the new mempool, potentially causing issues with the\nmempool as well.\n\nSince only normal I/O might increase nr_queued while an I/O error occurs,\nsuspending the array avoids this issue.\n\nNote: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends\nthe array. Therefore, we suspend the array when updating raid_disks\nvia sysfs to avoid this issue too.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00014,"ranking_epss":0.02383,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0107b18cd8ac17eb3e54786adc05a85cdbb6ef22","https://git.kernel.org/stable/c/165d1359f945b72c5f90088f60d48ff46115269e","https://git.kernel.org/stable/c/2cc583653bbe050bacd1cadcc9776d39bf449740"],"published_time":"2026-02-18T15:18:40","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71227","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: don't WARN for connections on invalid channels\n\nIt's not clear (to me) how exactly syzbot managed to hit this,\nbut it seems conceivable that e.g. regulatory changed and has\ndisabled a channel between scanning (channel is checked to be\nusable by cfg80211_get_ies_channel_number) and connecting on\nthe channel later.\n\nWith one scenario that isn't covered elsewhere described above,\nthe warning isn't good, replace it with a (more informative)\nerror message.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/10d3ff7e5812c8d70300f6fa8f524009a06aa7e1","https://git.kernel.org/stable/c/99067b58a408a384d2a45c105eb3dce980a862ce"],"published_time":"2026-02-18T15:18:40","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33088","summary":"IBM Concert 1.0.0 through 2.1.0 could allow a local user with specific knowledge about the system's architecture to escalate their privileges due to incorrect file permissions for critical resources.","cvss":7.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.4,"epss":0.00019,"ranking_epss":0.04831,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7260161"],"published_time":"2026-02-17T22:18:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36018","summary":"IBM Concert 1.0.0 through 2.1.0 for Z hub component is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00016,"ranking_epss":0.03678,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7260162"],"published_time":"2026-02-17T19:21:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36019","summary":"IBM Concert 1.0.0 through 2.1.0 for Z hub framework is vulnerable to cross-site scripting. This vulnerability allows an unauthenticated attacker to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00084,"ranking_epss":0.24672,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7260162"],"published_time":"2026-02-17T19:21:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2024-43178","summary":"IBM Concert 1.0.0 through 2.1.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.","cvss":5.9,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.9,"epss":0.00018,"ranking_epss":0.04381,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7260162"],"published_time":"2026-02-17T19:21:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23202","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nspi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer\n\nThe curr_xfer field is read by the IRQ handler without holding the lock\nto check if a transfer is in progress. When clearing curr_xfer in the\ncombined sequence transfer loop, protect it with the spinlock to prevent\na race with the interrupt handler.\n\nProtect the curr_xfer clearing at the exit path of\ntegra_qspi_combined_seq_xfer() with the spinlock to prevent a race\nwith the interrupt handler that reads this field.\n\nWithout this protection, the IRQ handler could read a partially updated\ncurr_xfer value, leading to NULL pointer dereference or use-after-free.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05153,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3bc293d5b56502068481478842f57b3d96e432c7","https://git.kernel.org/stable/c/6fd446178a610a48e80e5c5b487b0707cd01daac","https://git.kernel.org/stable/c/712cde8d916889e282727cdf304a43683adf899e","https://git.kernel.org/stable/c/762e2ce71c8f0238e9eaf05d14da803d9a24422f","https://git.kernel.org/stable/c/9fa4262a80f751d14a6a39d2c03f57db68da2618","https://git.kernel.org/stable/c/bf4528ab28e2bf112c3a2cdef44fd13f007781cd"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23203","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: cpsw_new: Execute ndo_set_rx_mode callback in a work queue\n\nCommit 1767bb2d47b7 (\"ipv6: mcast: Don't hold RTNL for\nIPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.\") removed the RTNL lock for\nIPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this\nchange triggered the following call trace on my BeagleBone Black board:\n  WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/496\n  RTNL: assertion failed at net/8021q/vlan_core.c (236)\n  Modules linked in:\n  CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT\n  Hardware name: Generic AM33XX (Flattened Device Tree)\n  Call trace:\n   unwind_backtrace from show_stack+0x28/0x2c\n   show_stack from dump_stack_lvl+0x30/0x38\n   dump_stack_lvl from __warn+0xb8/0x11c\n   __warn from warn_slowpath_fmt+0x130/0x194\n   warn_slowpath_fmt from vlan_for_each+0x120/0x124\n   vlan_for_each from cpsw_add_mc_addr+0x54/0xd8\n   cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec\n   __hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88\n   __dev_mc_add from igmp6_group_added+0x84/0xec\n   igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0\n   __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4\n   __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168\n   do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8\n   ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c\n   do_sock_setsockopt from __sys_setsockopt+0x84/0xac\n   __sys_setsockopt from ret_fast_syscall+0x0/0x5\n\nThis trace occurs because vlan_for_each() is called within\ncpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.\nSince modifying vlan_for_each() to operate without the RTNL lock is not\nstraightforward, and because ndo_set_rx_mode() is invoked both with and\nwithout the RTNL lock across different code paths, simply adding\nrtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.\n\nTo resolve this issue, we opt to execute the actual processing within\na work queue, following the approach used by the icssg-prueth driver.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/c0b5dc73a38f954e780f93a549b8fe225235c07a","https://git.kernel.org/stable/c/d5b3a669866977dc87fd56fcf00a70df1536d258"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23204","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_u32: use skb_header_pointer_careful()\n\nskb_header_pointer() does not fully validate negative @offset values.\n\nUse skb_header_pointer_careful() instead.\n\nGangMin Kim provided a report and a repro fooling u32_classify():\n\nBUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0\nnet/sched/cls_u32.c:221","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/13336a6239b9d7c6e61483017bb8bdfe3ceb10a5","https://git.kernel.org/stable/c/8a672f177ebe19c93d795fbe967846084fbc7943","https://git.kernel.org/stable/c/cabd1a976375780dabab888784e356f574bbaed8","https://git.kernel.org/stable/c/cfa745830e45ecb75c061aa34330ee0cac941cc7","https://git.kernel.org/stable/c/e41a23e61259f5526af875c3b86b3d42a9bae0e5"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23205","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/client: fix memory leak in smb2_open_file()\n\nReproducer:\n\n  1. server: directories are exported read-only\n  2. client: mount -t cifs //${server_ip}/export /mnt\n  3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct\n  4. client: umount /mnt\n  5. client: sleep 1\n  6. client: modprobe -r cifs\n\nThe error message is as follows:\n\n  =============================================================================\n  BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown()\n  -----------------------------------------------------------------------------\n\n  Object 0x00000000d47521be @offset=14336\n  ...\n  WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577\n  ...\n  Call Trace:\n   <TASK>\n   kmem_cache_destroy+0x94/0x190\n   cifs_destroy_request_bufs+0x3e/0x50 [cifs]\n   cleanup_module+0x4e/0x540 [cifs]\n   __se_sys_delete_module+0x278/0x400\n   __x64_sys_delete_module+0x5f/0x70\n   x64_sys_call+0x2299/0x2ff0\n   do_syscall_64+0x89/0x350\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  ...\n  kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs]\n  WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05117,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3a6d6b332f92990958602c1e35ce0173e2dd62e9","https://git.kernel.org/stable/c/743f70406264348c0830f38409eb6c40a42fb2db","https://git.kernel.org/stable/c/9ee608a64e37cea5b4b13e436c559dd0fb2ad1b5","https://git.kernel.org/stable/c/b64e3b5d8d759dd4333992e4ba4dadf9359952c8","https://git.kernel.org/stable/c/e3a43633023e3cacaca60d4b8972d084a2b06236"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23206","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zero\n\nThe driver allocates arrays for ports, FDBs, and filter blocks using\nkcalloc() with ethsw->sw_attr.num_ifs as the element count. When the\ndevice reports zero interfaces (either due to hardware configuration\nor firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)\ninstead of NULL.\n\nLater in dpaa2_switch_probe(), the NAPI initialization unconditionally\naccesses ethsw->ports[0]->netdev, which attempts to dereference\nZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.\n\nAdd a check to ensure num_ifs is greater than zero after retrieving\ndevice attributes. This prevents the zero-sized allocations and\nsubsequent invalid pointer dereference.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05153,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/155eb99aff2920153bf21217ae29565fff81e6af","https://git.kernel.org/stable/c/2fcccca88456b592bd668db13aa1d29ed257ca2b","https://git.kernel.org/stable/c/4acc40db06ffd0fd92683505342b00c8a7394c60","https://git.kernel.org/stable/c/80165ff16051448d6f840585ebe13f2400415df3","https://git.kernel.org/stable/c/b97415c4362f739e25ec6f71012277086fabdf6f","https://git.kernel.org/stable/c/ed48a84a72fefb20a82dd90a7caa7807e90c6f66"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23207","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nspi: tegra210-quad: Protect curr_xfer check in IRQ handler\n\nNow that all other accesses to curr_xfer are done under the lock,\nprotect the curr_xfer NULL check in tegra_qspi_isr_thread() with the\nspinlock. Without this protection, the following race can occur:\n\n  CPU0 (ISR thread)              CPU1 (timeout path)\n  ----------------               -------------------\n  if (!tqspi->curr_xfer)\n    // sees non-NULL\n                                 spin_lock()\n                                 tqspi->curr_xfer = NULL\n                                 spin_unlock()\n  handle_*_xfer()\n    spin_lock()\n    t = tqspi->curr_xfer  // NULL!\n    ... t->len ...        // NULL dereference!\n\nWith this patch, all curr_xfer accesses are now properly synchronized.\n\nAlthough all accesses to curr_xfer are done under the lock, in\ntegra_qspi_isr_thread() it checks for NULL, releases the lock and\nreacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer().\nThere is a potential for an update in between, which could cause a NULL\npointer dereference.\n\nTo handle this, add a NULL check inside the handlers after acquiring\nthe lock. This ensures that if the timeout path has already cleared\ncurr_xfer, the handler will safely return without dereferencing the\nNULL pointer.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00014,"ranking_epss":0.02389,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2ac3a105e51496147c0e44e49466eecfcc532d57","https://git.kernel.org/stable/c/84e926c1c272a35ddb9b86842d32fa833a60dfc7","https://git.kernel.org/stable/c/edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23208","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Prevent excessive number of frames\n\nIn this case, the user constructed the parameters with maxpacksize 40\nfor rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer\nsize for each data URB is maxpacksize * packets, which in this example\nis 40 * 6 = 240; When the user performs a write operation to send audio\ndata into the ALSA PCM playback stream, the calculated number of frames\nis packsize[0] * packets = 264, which exceeds the allocated URB buffer\nsize, triggering the out-of-bounds (OOB) issue reported by syzbot [1].\n\nAdded a check for the number of single data URB frames when calculating\nthe number of frames to prevent [1].\n\n[1]\nBUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\nWrite of size 264 at addr ffff88804337e800 by task syz.0.17/5506\nCall Trace:\n copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\n prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611\n prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03364,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/282aba56713bbc58155716b55ca7222b2d9cf3c8","https://git.kernel.org/stable/c/480a1490c595a242f27493a4544b3efb21b29f6a","https://git.kernel.org/stable/c/62932d9ed639a9fa71b4ac1a56766a4b43abb7e4","https://git.kernel.org/stable/c/ab0b5e92fc36ee82c1bd01fe896d0f775ed5de41","https://git.kernel.org/stable/c/c4dc012b027c9eb101583011089dea14d744e314","https://git.kernel.org/stable/c/d67dde02049e632ba58d3c44a164a74b6a737154","https://git.kernel.org/stable/c/e0ed5a36fb3ab9e7b9ee45cd17f09f6d5f594360","https://git.kernel.org/stable/c/ef5749ef8b307bf8717945701b1b79d036af0a15"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23209","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix error recovery in macvlan_common_newlink()\n\nvalis provided a nice repro to crash the kernel:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\n\nip link add mv0 link p2 type macvlan mode source\nip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20\n\nping -c1 -I p1 1.2.3.4\n\nHe also gave a very detailed analysis:\n\n<quote valis>\n\nThe issue is triggered when a new macvlan link is created  with\nMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or\nMACVLAN_MACADDR_SET) parameter, lower device already has a macvlan\nport and register_netdevice() called from macvlan_common_newlink()\nfails (e.g. because of the invalid link name).\n\nIn this case macvlan_hash_add_source is called from\nmacvlan_change_sources() / macvlan_common_newlink():\n\nThis adds a reference to vlan to the port's vlan_source_hash using\nmacvlan_source_entry.\n\nvlan is a pointer to the priv data of the link that is being created.\n\nWhen register_netdevice() fails, the error is returned from\nmacvlan_newlink() to rtnl_newlink_create():\n\n        if (ops->newlink)\n                err = ops->newlink(dev, &params, extack);\n        else\n                err = register_netdevice(dev);\n        if (err < 0) {\n                free_netdev(dev);\n                goto out;\n        }\n\nand free_netdev() is called, causing a kvfree() on the struct\nnet_device that is still referenced in the source entry attached to\nthe lower device's macvlan port.\n\nNow all packets sent on the macvlan port with a matching source mac\naddress will trigger a use-after-free in macvlan_forward_source().\n\n</quote valis>\n\nWith all that, my fix is to make sure we call macvlan_flush_sources()\nregardless of @create value whenever \"goto destroy_macvlan_port;\"\npath is taken.\n\nMany thanks to valis for following up on this issue.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02348,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/11ba9f0dc865136174cb98834280fb21bbc950c7","https://git.kernel.org/stable/c/5dae6b36a7cb7a4fcf4121b95e9ca7f96f816c8a","https://git.kernel.org/stable/c/986967a162142710076782d5b93daab93a892980","https://git.kernel.org/stable/c/c43d0e787cbba569ec9d11579ed370b50fab6c9c","https://git.kernel.org/stable/c/cdedcd5aa3f3cb8b7ae0f87ab3a936d0bd583d66","https://git.kernel.org/stable/c/da5c6b8ae47e414be47e5e04def15b25d5c962dc","https://git.kernel.org/stable/c/f8db6475a83649689c087a8f52486fcc53e627e9"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23210","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix PTP NULL pointer dereference during VSI rebuild\n\nFix race condition where PTP periodic work runs while VSI is being\nrebuilt, accessing NULL vsi->rx_rings.\n\nThe sequence was:\n1. ice_ptp_prepare_for_reset() cancels PTP work\n2. ice_ptp_rebuild() immediately queues PTP work\n3. VSI rebuild happens AFTER ice_ptp_rebuild()\n4. PTP work runs and accesses NULL vsi->rx_rings\n\nFix: Keep PTP work cancelled during rebuild, only queue it after\nVSI rebuild completes in ice_rebuild().\n\nAdded ice_ptp_queue_work() helper function to encapsulate the logic\nfor queuing PTP work, ensuring it's only queued when PTP is supported\nand the state is ICE_PTP_READY.\n\nError log:\n[  121.392544] ice 0000:60:00.1: PTP reset successful\n[  121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[  121.392712] #PF: supervisor read access in kernel mode\n[  121.392720] #PF: error_code(0x0000) - not-present page\n[  121.392727] PGD 0\n[  121.392734] Oops: Oops: 0000 [#1] SMP NOPTI\n[  121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S                  6.19.0-rc6+ #4 PREEMPT(voluntary)\n[  121.392761] Tainted: [S]=CPU_OUT_OF_SPEC\n[  121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice]\n[  121.393042] Call Trace:\n[  121.393047]  <TASK>\n[  121.393055]  ice_ptp_periodic_work+0x69/0x180 [ice]\n[  121.393202]  kthread_worker_fn+0xa2/0x260\n[  121.393216]  ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice]\n[  121.393359]  ? __pfx_kthread_worker_fn+0x10/0x10\n[  121.393371]  kthread+0x10d/0x230\n[  121.393382]  ? __pfx_kthread+0x10/0x10\n[  121.393393]  ret_from_fork+0x273/0x2b0\n[  121.393407]  ? __pfx_kthread+0x10/0x10\n[  121.393417]  ret_from_fork_asm+0x1a/0x30\n[  121.393432]  </TASK>","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7565d4df66b6619b50dc36618d8b8f1787d77e19","https://git.kernel.org/stable/c/ba0c7fff6616025a7d3a9e887e7ce16b06dc34b9","https://git.kernel.org/stable/c/fc6f36eaaedcf4b81af6fe1a568f018ffd530660"],"published_time":"2026-02-14T17:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23192","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlinkwatch: use __dev_put() in callers to prevent UAF\n\nAfter linkwatch_do_dev() calls __dev_put() to release the linkwatch\nreference, the device refcount may drop to 1. At this point,\nnetdev_run_todo() can proceed (since linkwatch_sync_dev() sees an\nempty list and returns without blocking), wait for the refcount to\nbecome 1 via netdev_wait_allrefs_any(), and then free the device\nvia kobject_put().\n\nThis creates a use-after-free when __linkwatch_run_queue() tries to\ncall netdev_unlock_ops() on the already-freed device.\n\nNote that adding netdev_lock_ops()/netdev_unlock_ops() pair in\nnetdev_run_todo() before kobject_put() would not work, because\nnetdev_lock_ops() is conditional - it only locks when\nnetdev_need_ops_lock() returns true. If the device doesn't require\nops_lock, linkwatch won't hold any lock, and netdev_run_todo()\nacquiring the lock won't provide synchronization.\n\nFix this by moving __dev_put() from linkwatch_do_dev() to its\ncallers. The device reference logically pairs with de-listing the\ndevice, so it's reasonable for the caller that did the de-listing\nto release it. This allows placing __dev_put() after all device\naccesses are complete, preventing UAF.\n\nThe bug can be reproduced by adding mdelay(2000) after\nlinkwatch_do_dev() in __linkwatch_run_queue(), then running:\n\n  ip tuntap add mode tun name tun_test\n  ip link set tun_test up\n  ip link set tun_test carrier off\n  ip link set tun_test carrier on\n  sleep 0.5\n  ip tuntap del mode tun name tun_test\n\nKASAN report:\n\n ==================================================================\n BUG: KASAN: use-after-free in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]\n BUG: KASAN: use-after-free in netdev_unlock_ops include/net/netdev_lock.h:47 [inline]\n BUG: KASAN: use-after-free in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245\n Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123\n\n CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: events_unbound linkwatch_event\n Call Trace:\n  <TASK>\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120\n  print_address_description mm/kasan/report.c:378 [inline]\n  print_report+0x156/0x4c9 mm/kasan/report.c:482\n  kasan_report+0xdf/0x1a0 mm/kasan/report.c:595\n  netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]\n  netdev_unlock_ops include/net/netdev_lock.h:47 [inline]\n  __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245\n  linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304\n  process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257\n  process_scheduled_works kernel/workqueue.c:3340 [inline]\n  worker_thread+0x5da/0xe40 kernel/workqueue.c:3421\n  kthread+0x3b3/0x730 kernel/kthread.c:463\n  ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n  </TASK>\n ==================================================================","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2718ae6af7445ba2ee0abf6365ca43a9a3b16aeb","https://git.kernel.org/stable/c/83b67cc9be9223183caf91826d9c194d7fb128fa"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23193","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()\n\nIn iscsit_dec_session_usage_count(), the function calls complete() while\nholding the sess->session_usage_lock. Similar to the connection usage count\nlogic, the waiter signaled by complete() (e.g., in the session release\npath) may wake up and free the iscsit_session structure immediately.\n\nThis creates a race condition where the current thread may attempt to\nexecute spin_unlock_bh() on a session structure that has already been\ndeallocated, resulting in a KASAN slab-use-after-free.\n\nTo resolve this, release the session_usage_lock before calling complete()\nto ensure all dereferences of the sess pointer are finished before the\nwaiter is allowed to proceed with deallocation.","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00028,"ranking_epss":0.07855,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/11ebafffce31efc6abeb28c509017976fc49f1ca","https://git.kernel.org/stable/c/2b64015550a13bcc72910be0565548d9a754d46d","https://git.kernel.org/stable/c/41b86a9ec037bd3435d68dd3692f0891a207e7e7","https://git.kernel.org/stable/c/4530f4e4d0e6a207110b0ffed0c911bca43531a4","https://git.kernel.org/stable/c/84dc6037390b8607c5551047d3970336cb51ba9a","https://git.kernel.org/stable/c/d8dbdc146e9e9a976931b78715be2e91299049f9","https://git.kernel.org/stable/c/fd8b0900173307039d3a84644c2fee041a7ed4fb"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23194","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrust_binder: correctly handle FDA objects of length zero\n\nFix a bug where an empty FDA (fd array) object with 0 fds would cause an\nout-of-bounds error. The previous implementation used `skip == 0` to\nmean \"this is a pointer fixup\", but 0 is also the correct skip length\nfor an empty FDA. If the FDA is at the end of the buffer, then this\nresults in an attempt to write 8-bytes out of bounds. This is caught and\nresults in an EINVAL error being returned to userspace.\n\nThe pattern of using `skip == 0` as a special value originates from the\nC-implementation of Binder. As part of fixing this bug, this pattern is\nreplaced with a Rust enum.\n\nI considered the alternate option of not pushing a fixup when the length\nis zero, but I think it's cleaner to just get rid of the zero-is-special\nstuff.\n\nThe root cause of this bug was diagnosed by Gemini CLI on first try. I\nused the following prompt:\n\n> There appears to be a bug in @drivers/android/binder/thread.rs where\n> the Fixups oob bug is triggered with 316 304 316 324. This implies\n> that we somehow ended up with a fixup where buffer A has a pointer to\n> buffer B, but the pointer is located at an index in buffer A that is\n> out of bounds. Please investigate the code to find the bug. You may\n> compare with @drivers/android/binder.c that implements this correctly.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/598fe3ff32e43918ed8a062f55432b3d23e6340c","https://git.kernel.org/stable/c/8f589c9c3be539d6c2b393c82940c3783831082f"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23195","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/dmem: avoid pool UAF\n\nAn UAF issue was observed:\n\nBUG: KASAN: slab-use-after-free in page_counter_uncharge+0x65/0x150\nWrite of size 8 at addr ffff888106715440 by task insmod/527\n\nCPU: 4 UID: 0 PID: 527 Comm: insmod    6.19.0-rc7-next-20260129+ #11\nTainted: [O]=OOT_MODULE\nCall Trace:\n<TASK>\ndump_stack_lvl+0x82/0xd0\nkasan_report+0xca/0x100\nkasan_check_range+0x39/0x1c0\npage_counter_uncharge+0x65/0x150\ndmem_cgroup_uncharge+0x1f/0x260\n\nAllocated by task 527:\n\nFreed by task 0:\n\nThe buggy address belongs to the object at ffff888106715400\nwhich belongs to the cache kmalloc-512 of size 512\nThe buggy address is located 64 bytes inside of\nfreed 512-byte region [ffff888106715400, ffff888106715600)\n\nThe buggy address belongs to the physical page:\n\nMemory state around the buggy address:\nffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\nffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n>ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n\t\t\t\t     ^\nffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\nffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n\nThe issue occurs because a pool can still be held by a caller after its\nassociated memory region is unregistered. The current implementation frees\nthe pool even if users still hold references to it (e.g., before uncharge\noperations complete).\n\nThis patch adds a reference counter to each pool, ensuring that a pool is\nonly freed when its reference count drops to zero.","cvss":7.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.0,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/99a2ef500906138ba58093b9893972a5c303c734","https://git.kernel.org/stable/c/d3081353acaa6a638dcf75726066ea556a2de8d5"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23196","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nHID: Intel-thc-hid: Intel-thc: Add safety check for reading DMA buffer\n\nAdd DMA buffer readiness check before reading DMA buffer to avoid\nunexpected NULL pointer accessing.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1e84a807c98a71f767fd1f609637bc5944f916cb","https://git.kernel.org/stable/c/a9a917998d172ec117f9e9de1919174153c0ace4"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23197","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: imx: preserve error state in block data length handler\n\nWhen a block read returns an invalid length, zero or >I2C_SMBUS_BLOCK_MAX,\nthe length handler sets the state to IMX_I2C_STATE_FAILED. However,\ni2c_imx_master_isr() unconditionally overwrites this with\nIMX_I2C_STATE_READ_CONTINUE, causing an endless read loop that overruns\nbuffers and crashes the system.\n\nGuard the state transition to preserve error states set by the length\nhandler.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3f9b508b3eecc00a243edf320bd83834d6a9b482","https://git.kernel.org/stable/c/b126097b0327437048bd045a0e4d273dea2910dd"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23198","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Don't clobber irqfd routing type when deassigning irqfd\n\nWhen deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's\nrouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86\nand arm64, which explicitly look for KVM_IRQ_ROUTING_MSI.  Instead, to\nhandle a concurrent routing update, verify that the irqfd is still active\nbefore consuming the routing information.  As evidenced by the x86 and\narm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),\nclobbering the entry type without notifying arch code is surprising and\nerror prone.\n\nAs a bonus, checking that the irqfd is active provides a convenient\nlocation for documenting _why_ KVM must not consume the routing entry for\nan irqfd that is in the process of being deassigned: once the irqfd is\ndeleted from the list (which happens *before* the eventfd is detached), it\nwill no longer receive updates via kvm_irq_routing_update(), and so KVM\ncould deliver an event using stale routing information (relative to\nKVM_SET_GSI_ROUTING returning to userspace).\n\nAs an even better bonus, explicitly checking for the irqfd being active\nfixes a similar bug to the one the clobbering is trying to prevent: if an\nirqfd is deactivated, and then its routing is changed,\nkvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()\n(because the irqfd isn't in the list).  And so if the irqfd is in bypass\nmode, IRQs will continue to be posted using the old routing information.\n\nAs for kvm_arch_irq_bypass_del_producer(), clobbering the routing type\nresults in KVM incorrectly keeping the IRQ in bypass mode, which is\nespecially problematic on AMD as KVM tracks IRQs that are being posted to\na vCPU in a list whose lifetime is tied to the irqfd.\n\nWithout the help of KASAN to detect use-after-free, the most common\nsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to\nthe memory for irqfd structure being re-allocated and zeroed, resulting\nin irqfd->irq_bypass_data being NULL when read by\navic_update_iommu_vcpu_affinity():\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000018\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0\n  Oops: Oops: 0000 [#1] SMP\n  CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test\n  Tainted: G     U  W  O        6.19.0-smp--5dddc257e6b2-irqfd #31 NONE\n  Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n  RIP: 0010:amd_iommu_update_ga+0x19/0xe0\n  Call Trace:\n   <TASK>\n   avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]\n   __avic_vcpu_load+0xf4/0x130 [kvm_amd]\n   kvm_arch_vcpu_load+0x89/0x210 [kvm]\n   vcpu_load+0x30/0x40 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]\n   kvm_vcpu_ioctl+0x571/0x6a0 [kvm]\n   __se_sys_ioctl+0x6d/0xb0\n   do_syscall_64+0x6f/0x9d0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  RIP: 0033:0x46893b\n    </TASK>\n  ---[ end trace 0000000000000000 ]---\n\nIf AVIC is inhibited when the irfd is deassigned, the bug will manifest as\nlist corruption, e.g. on the next irqfd assignment.\n\n  list_add corruption. next->prev should be prev (ffff8d474d5cd588),\n                       but was 0000000000000000. (next=ffff8d8658f86530).\n  ------------[ cut here ]------------\n  kernel BUG at lib/list_debug.c:31!\n  Oops: invalid opcode: 0000 [#1] SMP\n  CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test\n  Tainted: G     U  W  O        6.19.0-smp--f19dc4d680ba-irqfd #28 NONE\n  Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n  RIP: 0010:__list_add_valid_or_report+0x97/0xc0\n  Call Trace:\n   <TASK>\n   avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]\n   kvm_pi_update_irte+0xbf/0x190 [kvm]\n   kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]\n   irq_bypass_register_consumer+0xcd/0x170 [irqbypa\n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02348,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2284bc168b148a17b5ca3b37b3d95c411f18a08d","https://git.kernel.org/stable/c/4385b2f2843549bfb932e0dcf76bf4b065543a3c","https://git.kernel.org/stable/c/6d14ba1e144e796b5fc81044f08cfba9024ca195","https://git.kernel.org/stable/c/959a063e7f12524bc1871ad1f519787967bbcd45","https://git.kernel.org/stable/c/b4d37cdb77a0015f51fee083598fa227cc07aaf1","https://git.kernel.org/stable/c/b61f9b2fcf181451d0a319889478cc53c001123e","https://git.kernel.org/stable/c/ff48c9312d042bfbe826ca675e98acc6c623211c"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23199","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nprocfs: avoid fetching build ID while holding VMA lock\n\nFix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock\nor per-VMA lock, whichever was used to lock VMA under question, to avoid\ndeadlock reported by syzbot:\n\n -> #1 (&mm->mmap_lock){++++}-{4:4}:\n        __might_fault+0xed/0x170\n        _copy_to_iter+0x118/0x1720\n        copy_page_to_iter+0x12d/0x1e0\n        filemap_read+0x720/0x10a0\n        blkdev_read_iter+0x2b5/0x4e0\n        vfs_read+0x7f4/0xae0\n        ksys_read+0x12a/0x250\n        do_syscall_64+0xcb/0xf80\n        entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n -> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}:\n        __lock_acquire+0x1509/0x26d0\n        lock_acquire+0x185/0x340\n        down_read+0x98/0x490\n        blkdev_read_iter+0x2a7/0x4e0\n        __kernel_read+0x39a/0xa90\n        freader_fetch+0x1d5/0xa80\n        __build_id_parse.isra.0+0xea/0x6a0\n        do_procmap_query+0xd75/0x1050\n        procfs_procmap_ioctl+0x7a/0xb0\n        __x64_sys_ioctl+0x18e/0x210\n        do_syscall_64+0xcb/0xf80\n        entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n other info that might help us debug this:\n\n  Possible unsafe locking scenario:\n\n        CPU0                    CPU1\n        ----                    ----\n   rlock(&mm->mmap_lock);\n                                lock(&sb->s_type->i_mutex_key#8);\n                                lock(&mm->mmap_lock);\n   rlock(&sb->s_type->i_mutex_key#8);\n\n  *** DEADLOCK ***\n\nThis seems to be exacerbated (as we haven't seen these syzbot reports\nbefore that) by the recent:\n\n\t777a8560fd29 (\"lib/buildid: use __kernel_read() for sleepable context\")\n\nTo make this safe, we need to grab file refcount while VMA is still locked, but\nother than that everything is pretty straightforward. Internal build_id_parse()\nAPI assumes VMA is passed, but it only needs the underlying file reference, so\njust add another variant build_id_parse_file() that expects file passed\ndirectly.\n\n[akpm@linux-foundation.org: fix up kerneldoc]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02389,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/b5cbacd7f86f4f62b8813688c8e73be94e8e1951","https://git.kernel.org/stable/c/b9b97e6aeb534315f9646b2090d1a5024c6a4e82","https://git.kernel.org/stable/c/cbc03ce3e6ce7e21214c3f02218213574c1a2d08"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23200","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF\n\nsyzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6\nroute. [0]\n\nCommit f72514b3c569 (\"ipv6: clear RA flags when adding a static\nroute\") introduced logic to clear RTF_ADDRCONF from existing routes\nwhen a static route with the same nexthop is added. However, this\ncauses a problem when the existing route has a gateway.\n\nWhen RTF_ADDRCONF is cleared from a route that has a gateway, that\nroute becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns\ntrue. The issue is that this route was never added to the\nfib6_siblings list.\n\nThis leads to a mismatch between the following counts:\n\n- The sibling count computed by iterating fib6_next chain, which\n  includes the newly ECMP-eligible route\n\n- The actual siblings in fib6_siblings list, which does not include\n  that route\n\nWhen a subsequent ECMP route is added, fib6_add_rt2node() hits\nBUG_ON(sibling->fib6_nsiblings != rt->fib6_nsiblings) because the\ncounts don't match.\n\nFix this by only clearing RTF_ADDRCONF when the existing route does\nnot have a gateway. Routes without a gateway cannot qualify for ECMP\nanyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing\nRTF_ADDRCONF on them is safe and matches the original intent of the\ncommit.\n\n[0]:\nkernel BUG at net/ipv6/ip6_fib.c:1217!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nRIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217\n[...]\nCall Trace:\n <TASK>\n fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532\n __ip6_ins_rt net/ipv6/route.c:1351 [inline]\n ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946\n ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571\n inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577\n sock_do_ioctl+0xdc/0x300 net/socket.c:1245\n sock_ioctl+0x576/0x790 net/socket.c:1366\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/50b7c7a255858a85c4636a1e990ca04591153dca","https://git.kernel.org/stable/c/b8ad2d53f706aeea833d23d45c0758398fede580","https://git.kernel.org/stable/c/bbf4a17ad9ffc4e3d7ec13d73ecd59dea149ed25","https://git.kernel.org/stable/c/d8143c54ceeba232dc8a13aa0afa14a44b371d93"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23201","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix oops due to invalid pointer for kfree() in parse_longname()\n\nThis fixes a kernel oops when reading ceph snapshot directories (.snap),\nfor example by simply running `ls /mnt/my_ceph/.snap`.\n\nThe variable str is guarded by __free(kfree), but advanced by one for\nskipping the initial '_' in snapshot names. Thus, kfree() is called\nwith an invalid pointer.  This patch removes the need for advancing the\npointer so kfree() is called with correct memory pointer.\n\nSteps to reproduce:\n\n1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)\n\n2. Add cephfs mount to fstab\n$ echo \"samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6      /mnt/test/stuff   ceph     acl,noatime,_netdev    0       0\" >> /etc/fstab\n\n3. Reboot the system\n$ systemctl reboot\n\n4. Check if it's really mounted\n$ mount | grep stuff\n\n5. List snapshots (expected 63 snapshots on my system)\n$ ls /mnt/test/stuff/.snap\n\nNow ls hangs forever and the kernel log shows the oops.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/8c9af7339de419819cfc641d551675d38ff99abf","https://git.kernel.org/stable/c/bc8dedae022ce3058659c3addef3ec4b41d15e00","https://git.kernel.org/stable/c/e258ed369c9e04caa7d2fd49785d753ae4034cb6"],"published_time":"2026-02-14T17:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23184","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix UAF in binder_netlink_report()\n\nOneway transactions sent to frozen targets via binder_proc_transaction()\nreturn a BR_TRANSACTION_PENDING_FROZEN error but they are still treated\nas successful since the target is expected to thaw at some point. It is\nthen not safe to access 't' after BR_TRANSACTION_PENDING_FROZEN errors\nas the transaction could have been consumed by the now thawed target.\n\nThis is the case for binder_netlink_report() which derreferences 't'\nafter a pending frozen error, as pointed out by the following KASAN\nreport:\n\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in binder_netlink_report.isra.0+0x694/0x6c8\n  Read of size 8 at addr ffff00000f98ba38 by task binder-util/522\n\n  CPU: 4 UID: 0 PID: 522 Comm: binder-util Not tainted 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   binder_netlink_report.isra.0+0x694/0x6c8\n   binder_transaction+0x66e4/0x79b8\n   binder_thread_write+0xab4/0x4440\n   binder_ioctl+0x1fd4/0x2940\n   [...]\n\n  Allocated by task 522:\n   __kmalloc_cache_noprof+0x17c/0x50c\n   binder_transaction+0x584/0x79b8\n   binder_thread_write+0xab4/0x4440\n   binder_ioctl+0x1fd4/0x2940\n   [...]\n\n  Freed by task 488:\n   kfree+0x1d0/0x420\n   binder_free_transaction+0x150/0x234\n   binder_thread_read+0x2d08/0x3ce4\n   binder_ioctl+0x488/0x2940\n   [...]\n  ==================================================================\n\nInstead, make a transaction copy so the data can be safely accessed by\nbinder_netlink_report() after a pending frozen error. While here, add a\ncomment about not using t->buffer in binder_netlink_report().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5e8a3d01544282e50d887d76f30d1496a0a53562","https://git.kernel.org/stable/c/a6050dedb6f1cc23e518e3a132ab74a0aad6df90"],"published_time":"2026-02-14T17:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23185","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mld: cancel mlo_scan_start_wk\n\nmlo_scan_start_wk is not canceled on disconnection. In fact, it is not\ncanceled anywhere except in the restart cleanup, where we don't really\nhave to.\n\nThis can cause an init-after-queue issue: if, for example, the work was\nqueued and then drv_change_interface got executed.\n\nThis can also cause use-after-free: if the work is executed after the\nvif is freed.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5ff641011ab7fb63ea101251087745d9826e8ef5","https://git.kernel.org/stable/c/9b9f52f052f4953fecd2190ae2dde3aa76d10962"],"published_time":"2026-02-14T17:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23186","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()\n\nThe acpi_power_meter driver's .notify() callback function,\nacpi_power_meter_notify(), calls hwmon_device_unregister() under a lock\nthat is also acquired by callbacks in sysfs attributes of the device\nbeing unregistered which is prone to deadlocks between sysfs access and\ndevice removal.\n\nAddress this by moving the hwmon device removal in\nacpi_power_meter_notify() outside the lock in question, but notice\nthat doing it alone is not sufficient because two concurrent\nMETER_NOTIFY_CONFIG notifications may be attempting to remove the\nsame device at the same time.  To prevent that from happening, add a\nnew lock serializing the execution of the switch () statement in\nacpi_power_meter_notify().  For simplicity, it is a static mutex\nwhich should not be a problem from the performance perspective.\n\nThe new lock also allows the hwmon_device_register_with_info()\nin acpi_power_meter_notify() to be called outside the inner lock\nbecause it prevents the other notifications handled by that function\nfrom manipulating the \"resource\" object while the hwmon device based\non it is being registered.  The sending of ACPI netlink messages from\nacpi_power_meter_notify() is serialized by the new lock too which\ngenerally helps to ensure that the order of handling firmware\nnotifications is the same as the order of sending netlink messages\nrelated to them.\n\nIn addition, notice that hwmon_device_register_with_info() may fail\nin which case resource->hwmon_dev will become an error pointer,\nso add checks to avoid attempting to unregister the hwmon device\npointer to by it in that case to acpi_power_meter_notify() and\nacpi_power_meter_remove().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00016,"ranking_epss":0.03485,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/615901b57b7ef8eb655f71358f7e956e42bcd16b","https://git.kernel.org/stable/c/8860ddf0e07be37169d4ef9f2618e39fca934a66"],"published_time":"2026-02-14T17:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23187","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\npmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domains\n\nFix out-of-range access of bc->domains in imx8m_blk_ctrl_remove().","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00013,"ranking_epss":0.02326,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/071159ff5c0bf2e5efff79501e23faf3775cbcd1","https://git.kernel.org/stable/c/4390dcdabb5fca4647bf56a5a6b050bbdfa5760f","https://git.kernel.org/stable/c/6bd8b4a92a901fae1a422e6f914801063c345e8d","https://git.kernel.org/stable/c/7842b5dfcac888ece025a2321257d74b2264b099","https://git.kernel.org/stable/c/eb54ce033b344b531b374496e68a2554b2b56b5a"],"published_time":"2026-02-14T17:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23188","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: r8152: fix resume reset deadlock\n\nrtl8152 can trigger device reset during reset which\npotentially can result in a deadlock:\n\n **** DPM device timeout after 10 seconds; 15 seconds until panic ****\n Call Trace:\n <TASK>\n schedule+0x483/0x1370\n schedule_preempt_disabled+0x15/0x30\n __mutex_lock_common+0x1fd/0x470\n __rtl8152_set_mac_address+0x80/0x1f0\n dev_set_mac_address+0x7f/0x150\n rtl8152_post_reset+0x72/0x150\n usb_reset_device+0x1d0/0x220\n rtl8152_resume+0x99/0xc0\n usb_resume_interface+0x3e/0xc0\n usb_resume_both+0x104/0x150\n usb_resume+0x22/0x110\n\nThe problem is that rtl8152 resume calls reset under\ntp->control mutex while reset basically re-enters rtl8152\nand attempts to acquire the same tp->control lock once\nagain.\n\nReset INACCESSIBLE device outside of tp->control mutex\nscope to avoid recursive mutex_lock() deadlock.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02389,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1b2efc593dca99d8e8e6f6d6c7ccd9a972679702","https://git.kernel.org/stable/c/61c8091b7937f91f9bc0b7f6b578de270fe35dc7","https://git.kernel.org/stable/c/6d06bc83a5ae8777a5f7a81c32dd75b8d9b2fe04"],"published_time":"2026-02-14T17:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23189","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix NULL pointer dereference in ceph_mds_auth_match()\n\nThe CephFS kernel client has regression starting from 6.18-rc1.\nWe have issue in ceph_mds_auth_match() if fs_name == NULL:\n\n    const char fs_name = mdsc->fsc->mount_options->mds_namespace;\n    ...\n    if (auth->match.fs_name && strcmp(auth->match.fs_name, fs_name)) {\n            / fsname mismatch, try next one */\n            return 0;\n    }\n\nPatrick Donnelly suggested that: In summary, we should definitely start\ndecoding `fs_name` from the MDSMap and do strict authorizations checks\nagainst it. Note that the `-o mds_namespace=foo` should only be used for\nselecting the file system to mount and nothing else. It's possible\nno mds_namespace is specified but the kernel will mount the only\nfile system that exists which may have name \"foo\".\n\nThis patch reworks ceph_mdsmap_decode() and namespace_equals() with\nthe goal of supporting the suggested concept. Now struct ceph_mdsmap\ncontains m_fs_name field that receives copy of extracted FS name\nby ceph_extract_encoded_string(). For the case of \"old\" CephFS file\nsystems, it is used \"cephfs\" name.\n\n[ idryomov: replace redundant %*pE with %s in ceph_mdsmap_decode(),\n  get rid of a series of strlen() calls in ceph_namespace_match(),\n  drop changes to namespace_equals() body to avoid treating empty\n  mds_namespace as equal, drop changes to ceph_mdsc_handle_fsmap()\n  as namespace_equals() isn't an equivalent substitution there ]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/57b36ffc8881dd455d875f85c105901974af2130","https://git.kernel.org/stable/c/7987cce375ac8ce98e170a77aa2399f2cf6eb99f","https://git.kernel.org/stable/c/c6f8326f26bd20d648d9a55afd68148d1b6afe28"],"published_time":"2026-02-14T17:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23190","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: amd: fix memory leak in acp3x pdm dma ops","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05153,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0e0120214b5dcb0bf6b2171bb4e68e38968b2861","https://git.kernel.org/stable/c/279cb9180510f7e13c3a4dfde8c16a8fbc7c5709","https://git.kernel.org/stable/c/6d33640404968fe9f14a1252b337362b62fff490","https://git.kernel.org/stable/c/7f67ba5413f98d93116a756e7f17cd2c1d6c2bd6","https://git.kernel.org/stable/c/9f23800c7eed06cb8ccae8a225f5e3d421b0d4cc","https://git.kernel.org/stable/c/c9c14d2abe4c5546fcd3a7347fadc4aad2b308d8","https://git.kernel.org/stable/c/d7ead6512650447a4cd6db774a2379acb259650c"],"published_time":"2026-02-14T17:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23191","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: aloop: Fix racy access at PCM trigger\n\nThe PCM trigger callback of aloop driver tries to check the PCM state\nand stop the stream of the tied substream in the corresponding cable.\nSince both check and stop operations are performed outside the cable\nlock, this may result in UAF when a program attempts to trigger\nfrequently while opening/closing the tied stream, as spotted by\nfuzzers.\n\nFor addressing the UAF, this patch changes two things:\n- It covers the most of code in loopback_check_format() with\n  cable->lock spinlock, and add the proper NULL checks.  This avoids\n  already some racy accesses.\n- In addition, now we try to check the state of the capture PCM stream\n  that may be stopped in this function, which was the major pain point\n  leading to UAF.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0314,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5727ccf9d19ca414cb76d9b647883822e2789c2e","https://git.kernel.org/stable/c/826af7fa62e347464b1b4e0ba2fe19a92438084f","https://git.kernel.org/stable/c/bad15420050db1803767e58756114800cce91ea4"],"published_time":"2026-02-14T17:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71203","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Sanitize syscall table indexing under speculation\n\nThe syscall number is a user-controlled value used to index into the\nsyscall table. Use array_index_nospec() to clamp this value after the\nbounds check to prevent speculative out-of-bounds access and subsequent\ndata leakage via cache side channels.","cvss":7.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.0,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/25fd7ee7bf58ac3ec7be3c9f82ceff153451946c","https://git.kernel.org/stable/c/33743ec6679aa364ee19d1afbaa50593e9e6e443","https://git.kernel.org/stable/c/8b44e753795107a22ba31495686e83f4aca48f36","https://git.kernel.org/stable/c/c45848936ebdb4fcab92f8c39510db83c16d0239"],"published_time":"2026-02-14T17:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71204","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: fix refcount leak in parse_durable_handle_context()\n\nWhen the command is a replay operation and -ENOEXEC is returned,\nthe refcount of ksmbd_file must be released.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/07df5ff4f6490a5c96715b7c562e0b2908422e04","https://git.kernel.org/stable/c/3296c3012a9d9a27e81e34910384e55a6ff3cff0","https://git.kernel.org/stable/c/70dd3513ed6ac8c6cab23f72c5b19f44ca89de9d","https://git.kernel.org/stable/c/8a15107c4c031fb19737bf2eb4000f847f1d5e4c"],"published_time":"2026-02-14T17:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71220","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: call ksmbd_session_rpc_close() on error path in create_smb2_pipe()\n\nWhen ksmbd_iov_pin_rsp() fails, we should call ksmbd_session_rpc_close().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02348,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/04dd114b682a4ccaeba2c2bad049c8b50ce740d8","https://git.kernel.org/stable/c/2b7b4df87fe6f2db6ee45f475de6b37b8b8e5d29","https://git.kernel.org/stable/c/7c28f8eef5ac5312794d8a52918076dcd787e53b","https://git.kernel.org/stable/c/a2c68e256fb7a4ac34154c6e865a1389acca839f","https://git.kernel.org/stable/c/ac18761b530b5dd40f59af8a25902282e5512854","https://git.kernel.org/stable/c/fdda836fcee6fdbcccc24e3679097efb583f581f"],"published_time":"2026-02-14T17:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71221","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()\n\nAdd proper locking in mmp_pdma_residue() to prevent use-after-free when\naccessing descriptor list and descriptor contents.\n\nThe race occurs when multiple threads call tx_status() while the tasklet\non another CPU is freeing completed descriptors:\n\nCPU 0                              CPU 1\n-----                              -----\nmmp_pdma_tx_status()\nmmp_pdma_residue()\n  -> NO LOCK held\n     list_for_each_entry(sw, ..)\n                                   DMA interrupt\n                                   dma_do_tasklet()\n                                     -> spin_lock(&desc_lock)\n                                        list_move(sw->node, ...)\n                                        spin_unlock(&desc_lock)\n  |                                     dma_pool_free(sw) <- FREED!\n  -> access sw->desc <- UAF!\n\nThis issue can be reproduced when running dmatest on the same channel with\nmultiple threads (threads_per_chan > 1).\n\nFix by protecting the chain_running list iteration and descriptor access\nwith the chan->desc_lock spinlock.","cvss":7.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.0,"epss":0.00014,"ranking_epss":0.02519,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/9f665b3c3d9a168410251f27a5d019b7bf93185c","https://git.kernel.org/stable/c/a143545855bc2c6e1330f6f57ae375ac44af00a7","https://git.kernel.org/stable/c/dfb5e05227745de43b7fd589721817a4337c970d","https://git.kernel.org/stable/c/eba0c75670c022cb1f948600db972524bcfe8166","https://git.kernel.org/stable/c/fc023b8fab057f0c910856ff36d3e12a30b7af4a"],"published_time":"2026-02-14T17:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71222","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wlcore: ensure skb headroom before skb_push\n\nThis avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom is\nless than needed (typically 110 - 94 = 16 bytes).","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05153,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/689a7980e4788e13e766763d53569fb78dea2513","https://git.kernel.org/stable/c/71de0b6e04bbee5575caf9a1e4d424e7dcc50018","https://git.kernel.org/stable/c/745a0810dbc96a0471e5f5e627ba1e978c3116d4","https://git.kernel.org/stable/c/88295a55fefe5414e64293638b6f7549646e58ed","https://git.kernel.org/stable/c/b167312390fdd461c81ead516f2b0b44e83a9edb","https://git.kernel.org/stable/c/cd89a4656c03f8db0c57350aaec69cd3cfaa3522","https://git.kernel.org/stable/c/e75665dd096819b1184087ba5718bd93beafff51"],"published_time":"2026-02-14T17:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71223","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: fix refcount leak in smb2_open()\n\nWhen ksmbd_vfs_getattr() fails, the reference count of ksmbd_file\nmust be released.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2456fde2b137703328f1695f60c68fe488d17e36","https://git.kernel.org/stable/c/39ca11ff158c98fb092176f06047628c54bcf7a1","https://git.kernel.org/stable/c/4665e52bde3b1f8f442895ce7d88fa62a43e48c4","https://git.kernel.org/stable/c/f416c556997aa56ec4384c6b6efd6a0e6ac70aa7"],"published_time":"2026-02-14T17:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23168","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nflex_proportions: make fprop_new_period() hardirq safe\n\nBernd has reported a lockdep splat from flexible proportions code that is\nessentially complaining about the following race:\n\n<timer fires>\nrun_timer_softirq - we are in softirq context\n  call_timer_fn\n    writeout_period\n      fprop_new_period\n        write_seqcount_begin(&p->sequence);\n\n        <hardirq is raised>\n        ...\n        blk_mq_end_request()\n\t  blk_update_request()\n\t    ext4_end_bio()\n\t      folio_end_writeback()\n\t\t__wb_writeout_add()\n\t\t  __fprop_add_percpu_max()\n\t\t    if (unlikely(max_frac < FPROP_FRAC_BASE)) {\n\t\t      fprop_fraction_percpu()\n\t\t\tseq = read_seqcount_begin(&p->sequence);\n\t\t\t  - sees odd sequence so loops indefinitely\n\nNote that a deadlock like this is only possible if the bdi has configured\nmaximum fraction of writeout throughput which is very rare in general but\nfrequent for example for FUSE bdis.  To fix this problem we have to make\nsure write section of the sequence counter is irqsafe.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0acc9ba7a1b5ba4d998c5753e709be904e179b75","https://git.kernel.org/stable/c/78ede9ebd679dadf480dce6f7b798e3603f88348","https://git.kernel.org/stable/c/884b2590ffcc7222cbbd6298051f4c243cc36f5d","https://git.kernel.org/stable/c/b91a84299d72ae0e05551e851e47cd3008bd025b","https://git.kernel.org/stable/c/dd9e2f5b38f1fdd49b1ab6d3a85f81c14369eacc"],"published_time":"2026-02-14T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23169","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix race in mptcp_pm_nl_flush_addrs_doit()\n\nsyzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()\nand/or mptcp_pm_nl_is_backup()\n\nRoot cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()\nwhich is not RCU ready.\n\nlist_splice_init_rcu() can not be called here while holding pernet->lock\nspinlock.\n\nMany thanks to Eulgyu Kim for providing a repro and testing our patches.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":8e-05,"ranking_epss":0.00697,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1f1b9523527df02685dde603f20ff6e603d8e4a1","https://git.kernel.org/stable/c/338d40bab283da2639780ee3e458fb61f1567d8c","https://git.kernel.org/stable/c/455e882192c9833f176f3fbbbb2f036b6c5bf555","https://git.kernel.org/stable/c/51223bdd0f60b06cfc7f25885c4d4be917adba94","https://git.kernel.org/stable/c/7896dbe990d56d5bb8097863b2645355633665eb","https://git.kernel.org/stable/c/e2a9eeb69f7d4ca4cf4c70463af77664fdb6ab1d"],"published_time":"2026-02-14T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23170","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imx/tve: fix probe device leak\n\nMake sure to drop the reference taken to the DDC device during probe on\nprobe failure (e.g. probe deferral) and on driver unbind.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4aaff8f6ab38f81e00ab8aa1fcfb7eb20cd87ba1","https://git.kernel.org/stable/c/52755c5680ce333b33d0750a200fbc99420ed2b2","https://git.kernel.org/stable/c/77365382585b40559d63538d09e26e4b2af28fbc","https://git.kernel.org/stable/c/9a15d3fdc22d48f597792aee0cf1bf0947fc62e6","https://git.kernel.org/stable/c/ca68745e820ecd210e3ab018497c9e6b69025c4b","https://git.kernel.org/stable/c/e535c23513c63f02f67e3e09e0787907029efeaf","https://git.kernel.org/stable/c/f212652982c6725986cfa42fbf10d1dfa92c010e"],"published_time":"2026-02-14T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23171","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix use-after-free due to enslave fail after slave array update\n\nFix a use-after-free which happens due to enslave failure after the new\nslave has been added to the array. Since the new slave can be used for Tx\nimmediately, we can use it after it has been freed by the enslave error\ncleanup path which frees the allocated slave memory. Slave update array is\nsupposed to be called last when further enslave failures are not expected.\nMove it after xdp setup to avoid any problems.\n\nIt is very easy to reproduce the problem with a simple xdp_pass prog:\n ip l add bond1 type bond mode balance-xor\n ip l set bond1 up\n ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass\n ip l add dumdum type dummy\n\nThen run in parallel:\n while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done;\n mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp \"dp=1-1023, flags=syn\"\n\nThe crash happens almost immediately:\n [  605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI\n [  605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]\n [  605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G    B               6.19.0-rc6+ #21 PREEMPT(voluntary)\n [  605.602979] Tainted: [B]=BAD_PAGE\n [  605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n [  605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210\n [  605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89\n [  605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213\n [  605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000\n [  605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be\n [  605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c\n [  605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000\n [  605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84\n [  605.603286] FS:  00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000\n [  605.603319] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [  605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0\n [  605.603373] Call Trace:\n [  605.603392]  <TASK>\n [  605.603410]  __dev_queue_xmit+0x448/0x32a0\n [  605.603434]  ? __pfx_vprintk_emit+0x10/0x10\n [  605.603461]  ? __pfx_vprintk_emit+0x10/0x10\n [  605.603484]  ? __pfx___dev_queue_xmit+0x10/0x10\n [  605.603507]  ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [  605.603546]  ? _printk+0xcb/0x100\n [  605.603566]  ? __pfx__printk+0x10/0x10\n [  605.603589]  ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [  605.603627]  ? add_taint+0x5e/0x70\n [  605.603648]  ? add_taint+0x2a/0x70\n [  605.603670]  ? end_report.cold+0x51/0x75\n [  605.603693]  ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [  605.603731]  bond_start_xmit+0x623/0xc20 [bonding]","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/bd25b092a06a3e05f7e8bd6da6fa7318777d8c3d","https://git.kernel.org/stable/c/e9acda52fd2ee0cdca332f996da7a95c5fd25294"],"published_time":"2026-02-14T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23172","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: t7xx: fix potential skb->frags overflow in RX path\n\nWhen receiving data in the DPMAIF RX path,\nthe t7xx_dpmaif_set_frag_to_skb() function adds\npage fragments to an skb without checking if the number of\nfragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow\nin skb_shinfo(skb)->frags[] array, corrupting adjacent memory and\npotentially causing kernel crashes or other undefined behavior.\n\nThis issue was identified through static code analysis by comparing with a\nsimilar vulnerability fixed in the mt76 driver commit b102f0c522cf (\"mt76:\nfix array overflow on receiving too many fragments for a packet\").\n\nThe vulnerability could be triggered if the modem firmware sends packets\nwith excessive fragments. While under normal protocol conditions (MTU 3080\nbytes, BAT buffer 3584 bytes),\na single packet should not require additional\nfragments, the kernel should not blindly trust firmware behavior.\nMalicious, buggy, or compromised firmware could potentially craft packets\nwith more fragments than the kernel expects.\n\nFix this by adding a bounds check before calling skb_add_rx_frag() to\nensure nr_frags does not exceed MAX_SKB_FRAGS.\n\nThe check must be performed before unmapping to avoid a page leak\nand double DMA unmap during device teardown.","cvss":8.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.4,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2a0522f564acd34442652ea083091c329fa7c5d5","https://git.kernel.org/stable/c/2c0fb0f60bc1545c52da61bc6bd4855c1e7814ba","https://git.kernel.org/stable/c/af4b8577d0b388cc3d0039eb0cdd9ca5bbbc9276","https://git.kernel.org/stable/c/f0813bcd2d9d97fdbdf2efb9532ab03ae92e99e6","https://git.kernel.org/stable/c/f9747a7521a48afded5bff2faf1f2dcfff48c577"],"published_time":"2026-02-14T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23173","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: TC, delete flows only for existing peers\n\nWhen deleting TC steering flows, iterate only over actual devcom\npeers instead of assuming all possible ports exist. This avoids\ntouching non-existent peers and ensures cleanup is limited to\ndevices the driver is currently connected to.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 133c8a067 P4D 0\n Oops: Oops: 0002 [#1] SMP\n CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core]\n Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49\n RSP: 0018:ff11000143867528 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000\n RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0\n RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002\n R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78\n R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0\n FS:  00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0\n Call Trace:\n  <TASK>\n  mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]\n  mlx5e_flow_put+0x25/0x50 [mlx5_core]\n  mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]\n  tc_setup_cb_reoffload+0x20/0x80\n  fl_reoffload+0x26f/0x2f0 [cls_flower]\n  ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]\n  ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]\n  tcf_block_playback_offloads+0x9e/0x1c0\n  tcf_block_unbind+0x7b/0xd0\n  tcf_block_setup+0x186/0x1d0\n  tcf_block_offload_cmd.isra.0+0xef/0x130\n  tcf_block_offload_unbind+0x43/0x70\n  __tcf_block_put+0x85/0x160\n  ingress_destroy+0x32/0x110 [sch_ingress]\n  __qdisc_destroy+0x44/0x100\n  qdisc_graft+0x22b/0x610\n  tc_get_qdisc+0x183/0x4d0\n  rtnetlink_rcv_msg+0x2d7/0x3d0\n  ? rtnl_calcit.isra.0+0x100/0x100\n  netlink_rcv_skb+0x53/0x100\n  netlink_unicast+0x249/0x320\n  ? __alloc_skb+0x102/0x1f0\n  netlink_sendmsg+0x1e3/0x420\n  __sock_sendmsg+0x38/0x60\n  ____sys_sendmsg+0x1ef/0x230\n  ? copy_msghdr_from_user+0x6c/0xa0\n  ___sys_sendmsg+0x7f/0xc0\n  ? ___sys_recvmsg+0x8a/0xc0\n  ? __sys_sendto+0x119/0x180\n  __sys_sendmsg+0x61/0xb0\n  do_syscall_64+0x55/0x640\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f35238bb764\n Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55\n RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764\n RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003\n RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20\n R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790\n R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2652e2f1253c53f9a3ce84cc972568b32c892734","https://git.kernel.org/stable/c/62e1d8920f6920543f4b095a65fb964448c9901d","https://git.kernel.org/stable/c/f67666938ae626cbda63fbf5176b3583c07e7124","https://git.kernel.org/stable/c/fdf8437016f578f18b160c6e14f13ab96bfbc3ba"],"published_time":"2026-02-14T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23159","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nperf: sched: Fix perf crash with new is_user_task() helper\n\nIn order to do a user space stacktrace the current task needs to be a user\ntask that has executed in user space. It use to be possible to test if a\ntask is a user task or not by simply checking the task_struct mm field. If\nit was non NULL, it was a user task and if not it was a kernel task.\n\nBut things have changed over time, and some kernel tasks now have their\nown mm field.\n\nAn idea was made to instead test PF_KTHREAD and two functions were used to\nwrap this check in case it became more complex to test if a task was a\nuser task or not[1]. But this was rejected and the C code simply checked\nthe PF_KTHREAD directly.\n\nIt was later found that not all kernel threads set PF_KTHREAD. The io-uring\nhelpers instead set PF_USER_WORKER and this needed to be added as well.\n\nBut checking the flags is still not enough. There's a very small window\nwhen a task exits that it frees its mm field and it is set back to NULL.\nIf perf were to trigger at this moment, the flags test would say its a\nuser space task but when perf would read the mm field it would crash with\nat NULL pointer dereference.\n\nNow there are flags that can be used to test if a task is exiting, but\nthey are set in areas that perf may still want to profile the user space\ntask (to see where it exited). The only real test is to check both the\nflags and the mm field.\n\nInstead of making this modification in every location, create a new\nis_user_task() helper function that does all the tests needed to know if\nit is safe to read the user space memory or not.\n\n[1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5aac392fcd3d981d7997f1a0766829e1afdeac2e","https://git.kernel.org/stable/c/76ed27608f7dd235b727ebbb12163438c2fbb617","https://git.kernel.org/stable/c/a28fce0365e1cb9cb8c04c893b9334e5ca9d9f1c","https://git.kernel.org/stable/c/d84a4836dc246b7dc244e46a08ff992956b68db0"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23160","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: Fix memory leak in octep_device_setup()\n\nIn octep_device_setup(), if octep_ctrl_net_init() fails, the function\nreturns directly without unmapping the mapped resources and freeing the\nallocated configuration memory.\n\nFix this by jumping to the unsupported_dev label, which performs the\nnecessary cleanup. This aligns with the error handling logic of other\npaths in this function.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5058d3f8f17202e673f90af1446252322bd0850f","https://git.kernel.org/stable/c/8016dc5ee19a77678c264f8ba368b1e873fa705b","https://git.kernel.org/stable/c/d753f3c3f9d7a6e6dbb4d3a97b73007d71624551","https://git.kernel.org/stable/c/fdfd28e13c244d7c3345e74f339fd1b67605b694"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23161","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem, swap: fix race of truncate and swap entry split\n\nThe helper for shmem swap freeing is not handling the order of swap\nentries correctly.  It uses xa_cmpxchg_irq to erase the swap entry, but it\ngets the entry order before that using xa_get_order without lock\nprotection, and it may get an outdated order value if the entry is split\nor changed in other ways after the xa_get_order and before the\nxa_cmpxchg_irq.\n\nAnd besides, the order could grow and be larger than expected, and cause\ntruncation to erase data beyond the end border.  For example, if the\ntarget entry and following entries are swapped in or freed, then a large\nfolio was added in place and swapped out, using the same entry, the\nxa_cmpxchg_irq will still succeed, it's very unlikely to happen though.\n\nTo fix that, open code the Xarray cmpxchg and put the order retrieval and\nvalue checking in the same critical section.  Also, ensure the order won't\nexceed the end border, skip it if the entry goes across the border.\n\nSkipping large swap entries crosses the end border is safe here.  Shmem\ntruncate iterates the range twice, in the first iteration,\nfind_lock_entries already filtered such entries, and shmem will swapin the\nentries that cross the end border and partially truncate the folio (split\nthe folio or at least zero part of it).  So in the second loop here, if we\nsee a swap entry that crosses the end order, it must at least have its\ncontent erased already.\n\nI observed random swapoff hangs and kernel panics when stress testing\nZSWAP with shmem.  After applying this patch, all problems are gone.","cvss":7.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.3,"epss":0.00014,"ranking_epss":0.02383,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/8a1968bd997f45a9b11aefeabdd1232e1b6c7184","https://git.kernel.org/stable/c/a99f9a4669a04662c8f9efe0e62cafc598153139","https://git.kernel.org/stable/c/b23bee8cdb7aabce5701a7f57414db5a354ae8ed"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23162","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/nvm: Fix double-free on aux add failure\n\nAfter a successful auxiliary_device_init(), aux_dev->dev.release\n(xe_nvm_release_dev()) is responsible for the kfree(nvm). When\nthere is failure with auxiliary_device_add(), driver will call\nauxiliary_device_uninit(), which call put_device(). So that the\n.release callback will be triggered to free the memory associated\nwith the auxiliary_device.\n\nMove the kfree(nvm) into the auxiliary_device_init() failure path\nand remove the err goto path to fix below error.\n\n\"\n[   13.232905] ==================================================================\n[   13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe]\n[   13.233112] Free of addr ffff888120635000 by task systemd-udevd/273\n\n[   13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary)\n...\n[   13.233125] Call Trace:\n[   13.233126]  <TASK>\n[   13.233127]  dump_stack_lvl+0x7f/0xc0\n[   13.233132]  print_report+0xce/0x610\n[   13.233136]  ? kasan_complete_mode_report_info+0x5d/0x1e0\n[   13.233139]  ? xe_nvm_init+0x751/0xf10 [xe]\n...\n\"\n\nv2: drop err goto path. (Alexander)\n\n(cherry picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215)","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/32887d8e4bc0696b3cb6c5915a42b39cfd3434f4","https://git.kernel.org/stable/c/8a44241b0b83a6047c5448da1fff03fcc29496b5"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23163","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove\n\nOn APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and\nih2 interrupt ring buffers are not initialized. This is by design, as\nthese secondary IH rings are only available on discrete GPUs. See\nvega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when\nAMD_IS_APU is set.\n\nHowever, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to\nget the timestamp of the last interrupt entry. When retry faults are\nenabled on APUs (noretry=0), this function is called from the SVM page\nfault recovery path, resulting in a NULL pointer dereference when\namdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[].\n\nThe crash manifests as:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000004\n  RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]\n  Call Trace:\n   amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]\n   svm_range_restore_pages+0xae5/0x11c0 [amdgpu]\n   amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]\n   gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]\n   amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]\n   amdgpu_ih_process+0x84/0x100 [amdgpu]\n\nThis issue was exposed by commit 1446226d32a4 (\"drm/amdgpu: Remove GC HW\nIP 9.3.0 from noretry=1\") which changed the default for Renoir APU from\nnoretry=1 to noretry=0, enabling retry fault handling and thus\nexercising the buggy code path.\n\nFix this by adding a check for ih1.ring_size before attempting to use\nit. Also restore the soft_ih support from commit dd299441654f (\"drm/amdgpu:\nRework retry fault removal\").  This is needed if the hardware doesn't\nsupport secondary HW IH rings.\n\nv2: additional updates (Alex)\n\n(cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7611d7faccc1218be477671f892a89b25c0cb352","https://git.kernel.org/stable/c/8b1ecc9377bc641533cd9e76dfa3aee3cd04a007","https://git.kernel.org/stable/c/ac251d17d8af58ddc3daba65eaf0a99e63dc4284","https://git.kernel.org/stable/c/c74e2dbb5316898fb2113a8ea3a93b27698dbf68"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23164","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrocker: fix memory leak in rocker_world_port_post_fini()\n\nIn rocker_world_port_pre_init(), rocker_port->wpriv is allocated with\nkzalloc(wops->port_priv_size, GFP_KERNEL). However, in\nrocker_world_port_post_fini(), the memory is only freed when\nwops->port_post_fini callback is set:\n\n    if (!wops->port_post_fini)\n        return;\n    wops->port_post_fini(rocker_port);\n    kfree(rocker_port->wpriv);\n\nSince rocker_ofdpa_ops does not implement port_post_fini callback\n(it is NULL), the wpriv memory allocated for each port is never freed\nwhen ports are removed. This leads to a memory leak of\nsizeof(struct ofdpa_port) bytes per port on every device removal.\n\nFix this by always calling kfree(rocker_port->wpriv) regardless of\nwhether the port_post_fini callback exists.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2a3a64d75d2d0727da285749476761ebcad557a3","https://git.kernel.org/stable/c/8ce2e85889939c02740b4245301aa5c35fc94887","https://git.kernel.org/stable/c/8d7ba71e46216b8657a82ca2ec118bc93812a4d0","https://git.kernel.org/stable/c/b11e6f926480ab0939fec44781f28558c54be4e7","https://git.kernel.org/stable/c/d448bf96889f1905e740c554780f5c9fa0440566","https://git.kernel.org/stable/c/d8723917efda3b4f4c3de78d1ec1e1af015c0be1","https://git.kernel.org/stable/c/dce375f4afc348c310d171abcde7ec1499a4c26a"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23165","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix deadlock in RSS config read\n\nSince cited commit, core locks the net_device's rss_lock when handling\n ethtool -x command, so driver's implementation should not lock it\n again.  Remove the latter.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03072,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/590c8179ffb01c17644181408821b55b8704c50c","https://git.kernel.org/stable/c/944c614b0a7afa5b87612c3fb557b95a50ad654c"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23166","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix NULL pointer dereference in ice_vsi_set_napi_queues\n\nAdd NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashes\nduring resume from suspend when rings[q_idx]->q_vector is NULL.\n\nTested adaptor:\n60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02)\n        Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]\n\nSR-IOV state: both disabled and enabled can reproduce this issue.\n\nkernel version: v6.18\n\nReproduce steps:\nBoot up and execute suspend like systemctl suspend or rtcwake.\n\nLog:\n<1>[  231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040\n<1>[  231.444052] #PF: supervisor read access in kernel mode\n<1>[  231.444484] #PF: error_code(0x0000) - not-present page\n<6>[  231.444913] PGD 0 P4D 0\n<4>[  231.445342] Oops: Oops: 0000 [#1] SMP NOPTI\n<4>[  231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170\n<4>[  231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89\n<4>[  231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202\n<4>[  231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010\n<4>[  231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000\n<4>[  231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000\n<4>[  231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001\n<4>[  231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000\n<4>[  231.450265] FS:  00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000\n<4>[  231.450715] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n<4>[  231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0\n<4>[  231.451629] PKRU: 55555554\n<4>[  231.452076] Call Trace:\n<4>[  231.452549]  <TASK>\n<4>[  231.452996]  ? ice_vsi_set_napi_queues+0x4d/0x110 [ice]\n<4>[  231.453482]  ice_resume+0xfd/0x220 [ice]\n<4>[  231.453977]  ? __pfx_pci_pm_resume+0x10/0x10\n<4>[  231.454425]  pci_pm_resume+0x8c/0x140\n<4>[  231.454872]  ? __pfx_pci_pm_resume+0x10/0x10\n<4>[  231.455347]  dpm_run_callback+0x5f/0x160\n<4>[  231.455796]  ? dpm_wait_for_superior+0x107/0x170\n<4>[  231.456244]  device_resume+0x177/0x270\n<4>[  231.456708]  dpm_resume+0x209/0x2f0\n<4>[  231.457151]  dpm_resume_end+0x15/0x30\n<4>[  231.457596]  suspend_devices_and_enter+0x1da/0x2b0\n<4>[  231.458054]  enter_state+0x10e/0x570\n\nAdd defensive checks for both the ring pointer and its q_vector\nbefore dereferencing, allowing the system to resume successfully even when\nq_vectors are unmapped.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/36126ddbe924727add05a594dedf230d3b575e4d","https://git.kernel.org/stable/c/9bb30be4d89ff9a8d7ab1aa0eb2edaca83431f85","https://git.kernel.org/stable/c/d75c7b7c3c2b8e3569043099e6bdcefc983856c5"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23167","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: Fix race between rfkill and nci_unregister_device().\n\nsyzbot reported the splat below [0] without a repro.\n\nIt indicates that struct nci_dev.cmd_wq had been destroyed before\nnci_close_device() was called via rfkill.\n\nnci_dev.cmd_wq is only destroyed in nci_unregister_device(), which\n(I think) was called from virtual_ncidev_close() when syzbot close()d\nan fd of virtual_ncidev.\n\nThe problem is that nci_unregister_device() destroys nci_dev.cmd_wq\nfirst and then calls nfc_unregister_device(), which removes the\ndevice from rfkill by rfkill_unregister().\n\nSo, the device is still visible via rfkill even after nci_dev.cmd_wq\nis destroyed.\n\nLet's unregister the device from rfkill first in nci_unregister_device().\n\nNote that we cannot call nfc_unregister_device() before\nnci_close_device() because\n\n  1) nfc_unregister_device() calls device_del() which frees\n     all memory allocated by devm_kzalloc() and linked to\n     ndev->conn_info_list\n\n  2) nci_rx_work() could try to queue nci_conn_info to\n     ndev->conn_info_list which could be leaked\n\nThus, nfc_unregister_device() is split into two functions so we\ncan remove rfkill interfaces only before nci_close_device().\n\n[0]:\nDEBUG_LOCKS_WARN_ON(1)\nWARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349\nWARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349\nWARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349\nModules linked in:\nCPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026\nRIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]\nRIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline]\nRIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187\nCode: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f\nRSP: 0018:ffffc9000c767680 EFLAGS: 00010046\nRAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000\nRDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0\nRBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4\nR10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2\nR13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30\nFS:  00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0\nCall Trace:\n <TASK>\n lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868\n touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940\n __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982\n nci_close_device+0x302/0x630 net/nfc/nci/core.c:567\n nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639\n nfc_dev_down+0x152/0x290 net/nfc/core.c:161\n nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179\n rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346\n rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301\n vfs_write+0x29a/0xb90 fs/read_write.c:684\n ksys_write+0x150/0x270 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fa59b39acb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9\nRDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007\nRBP: 00007fa59b408bf7 R08: \n---truncated---","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00014,"ranking_epss":0.02455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/126cd30cad37bc7c2c85fe2df2a522d4edf0a5c5","https://git.kernel.org/stable/c/546eba0b10989de9ccc7fd619e874a30561e2b88","https://git.kernel.org/stable/c/8ea4d96419fb20f15a52ce657d49f1e7c91eb7ac","https://git.kernel.org/stable/c/c3369fc5e6120a72169e71acd72e987907a682af","https://git.kernel.org/stable/c/cd4412d5905ee580e96c48360dc98fcd9e6f3208","https://git.kernel.org/stable/c/d2492688bb9fed6ab6e313682c387ae71a66ebae","https://git.kernel.org/stable/c/eaa5da5130deda26420273d4610cf6e4f794ed75"],"published_time":"2026-02-14T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23149","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl()\n\nSince GEM bo handles are u32 in the uapi and the internal implementation\nuses idr_alloc() which uses int ranges, passing a new handle larger than\nINT_MAX trivially triggers a kernel warning:\n\nidr_alloc():\n...\n\tif (WARN_ON_ONCE(start < 0))\n\t\treturn -EINVAL;\n...\n\nFix it by rejecting new handles above INT_MAX and at the same time make\nthe end limit calculation more obvious by moving into int domain.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/12f15d52d38ac53f7c70ea3d4b3d76afed04e064","https://git.kernel.org/stable/c/ae8831ee0fb2f5f41f39722e7b3749d65bb78d08"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23150","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().\n\nsyzbot reported various memory leaks related to NFC, struct\nnfc_llcp_sock, sk_buff, nfc_dev, etc. [0]\n\nThe leading log hinted that nfc_llcp_send_ui_frame() failed\nto allocate skb due to sock_error(sk) being -ENXIO.\n\nENXIO is set by nfc_llcp_socket_release() when struct\nnfc_llcp_local is destroyed by local_cleanup().\n\nThe problem is that there is no synchronisation between\nnfc_llcp_send_ui_frame() and local_cleanup(), and skb\ncould be put into local->tx_queue after it was purged in\nlocal_cleanup():\n\n  CPU1                          CPU2\n  ----                          ----\n  nfc_llcp_send_ui_frame()      local_cleanup()\n  |- do {                       '\n     |- pdu = nfc_alloc_send_skb(..., &err)\n     |                          .\n     |                          |- nfc_llcp_socket_release(local, false, ENXIO);\n     |                          |- skb_queue_purge(&local->tx_queue);      |\n     |                          '                                          |\n     |- skb_queue_tail(&local->tx_queue, pdu);                             |\n    ...                                                                    |\n     |- pdu = nfc_alloc_send_skb(..., &err)                                |\n                                       ^._________________________________.'\n\nlocal_cleanup() is called for struct nfc_llcp_local only\nafter nfc_llcp_remove_local() unlinks it from llcp_devices.\n\nIf we hold local->tx_queue.lock then, we can synchronise\nthe thread and nfc_llcp_send_ui_frame().\n\nLet's do that and check list_empty(&local->list) before\nqueuing skb to local->tx_queue in nfc_llcp_send_ui_frame().\n\n[0]:\n[   56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)\n[   64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nBUG: memory leak\nunreferenced object 0xffff8881272f6800 (size 1024):\n  comm \"syz.0.17\", pid 6096, jiffies 4294942766\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00  '..@............\n  backtrace (crc da58d84d):\n    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]\n    slab_post_alloc_hook mm/slub.c:4979 [inline]\n    slab_alloc_node mm/slub.c:5284 [inline]\n    __do_kmalloc_node mm/slub.c:5645 [inline]\n    __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658\n    kmalloc_noprof include/linux/slab.h:961 [inline]\n    sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239\n    sk_alloc+0x36/0x360 net/core/sock.c:2295\n    nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979\n    llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044\n    nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31\n    __sock_create+0x1a9/0x340 net/socket.c:1605\n    sock_create net/socket.c:1663 [inline]\n    __sys_socket_create net/socket.c:1700 [inline]\n    __sys_socket+0xb9/0x1a0 net/socket.c:1747\n    __do_sys_socket net/socket.c:1761 [inline]\n    __se_sys_socket net/socket.c:1759 [inline]\n    __x64_sys_socket+0x1b/0x30 net/socket.c:1759\n    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n    do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94\n    entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nBUG: memory leak\nunreferenced object 0xffff88810fbd9800 (size 240):\n  comm \"syz.0.17\", pid 6096, jiffies 4294942850\n  hex dump (first 32 bytes):\n    68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff  h.......h.......\n    00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff  .........h/'....\n  backtrace (crc 6cc652b1):\n    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]\n    slab_post_alloc_hook mm/slub.c:4979 [inline]\n    slab_alloc_node mm/slub.c:5284 [inline]\n    kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336\n    __alloc_skb+0x203/0x240 net/core/skbuff.c:660\n    alloc_skb include/linux/skbuff.h:1383 [inline]\n    alloc_skb_with_frags+0x69/0x3f0 net/core/sk\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/165c34fb6068ff153e3fc99a932a80a9d5755709","https://git.kernel.org/stable/c/3098e5c8af0f4c8f7eebbb370798df8aa2e12ba5","https://git.kernel.org/stable/c/61858cbce6ca4bef9ed116c689a4be9520841339","https://git.kernel.org/stable/c/65e976e1f474ae3bf5681d7abafb8f3fdb34b8cc","https://git.kernel.org/stable/c/6734ff1ac6beba1d0c22dc9a3dc1849b773b511f","https://git.kernel.org/stable/c/ab660cb8e17aa93426d1e821c2cce60e4b9bc56a","https://git.kernel.org/stable/c/f8d002626d434f5fea9085e2557711c16a15cec6"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23151","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix memory leak in set_ssp_complete\n\nFix memory leak in set_ssp_complete() where mgmt_pending_cmd structures\nare not freed after being removed from the pending list.\n\nCommit 302a1f674c00 (\"Bluetooth: MGMT: Fix possible UAFs\") replaced\nmgmt_pending_foreach() calls with individual command handling but missed\nadding mgmt_pending_free() calls in both error and success paths of\nset_ssp_complete(). Other completion functions like set_le_complete()\nwere fixed correctly in the same commit.\n\nThis causes a memory leak of the mgmt_pending_cmd structure and its\nassociated parameter data for each SSP command that completes.\n\nAdd the missing mgmt_pending_free(cmd) calls in both code paths to fix\nthe memory leak. Also fix the same issue in set_advertising_complete().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1850a558d116d7e3e2ef36d06a56f59b640cc214","https://git.kernel.org/stable/c/1b9c17fd0a7fdcbe69ec5d6fe8e50bc5ed7f01f2","https://git.kernel.org/stable/c/3b6318505378828ee415d6ef678db6a74c077504"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23152","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: correctly decode TTLM with default link map\n\nTID-To-Link Mapping (TTLM) elements do not contain any link mapping\npresence indicator if a default mapping is used and parsing needs to be\nskipped.\n\nNote that access points should not explicitly report an advertised TTLM\nwith a default mapping as that is the implied mapping if the element is\nnot included, this is even the case when switching back to the default\nmapping. However, mac80211 would incorrectly parse the frame and would\nalso read one byte beyond the end of the element.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1eab33aa63c993685dd341e03bd5b267dd7403fa","https://git.kernel.org/stable/c/aabc36857bd39da65fe2d047bfaf63a0a09917d4"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23153","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfirewire: core: fix race condition against transaction list\n\nThe list of transaction is enumerated without acquiring card lock when\nprocessing AR response event. This causes a race condition bug when\nprocessing AT request completion event concurrently.\n\nThis commit fixes the bug by put timer start for split transaction\nexpiration into the scope of lock. The value of jiffies in card structure\nis referred before acquiring the lock.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00015,"ranking_epss":0.03072,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/20e01bba2ae4898ce65cdcacd1bd6bec5111abd9","https://git.kernel.org/stable/c/b038874e31fc3caa0b0d5abd259dd54b918ad4a1"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23154","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix segmentation of forwarding fraglist GRO\n\nThis patch enhances GSO segment handling by properly checking\nthe SKB_GSO_DODGY flag for frag_list GSO packets, addressing\nlow throughput issues observed when a station accesses IPv4\nservers via hotspots with an IPv6-only upstream interface.\n\nSpecifically, it fixes a bug in GSO segmentation when forwarding\nGRO packets containing a frag_list. The function skb_segment_list\ncannot correctly process GRO skbs that have been converted by XLAT,\nsince XLAT only translates the header of the head skb. Consequently,\nskbs in the frag_list may remain untranslated, resulting in protocol\ninconsistencies and reduced throughput.\n\nTo address this, the patch explicitly sets the SKB_GSO_DODGY flag\nfor GSO packets in XLAT's IPv4/IPv6 protocol translation helpers\n(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSO\npackets as potentially modified after protocol translation. As a\nresult, GSO segmentation will avoid using skb_segment_list and\ninstead falls back to skb_segment for packets with the SKB_GSO_DODGY\nflag. This ensures that only safe and fully translated frag_list\npackets are processed by skb_segment_list, resolving protocol\ninconsistencies and improving throughput when forwarding GRO packets\nconverted by XLAT.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2cbef9ea5a0ac51863ede35c45f26931a85d3888","https://git.kernel.org/stable/c/3d48d59235c494d34e32052f768393111c0806ef","https://git.kernel.org/stable/c/3e62db1e3140449608975e29e0979cc5f3b1cc07","https://git.kernel.org/stable/c/426ca15c7f6cb6562a081341ca88893a50c59fa2","https://git.kernel.org/stable/c/9122d7280b2303e835cdfec156bd932ac1f586ed"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23155","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncan: gs_usb: gs_usb_receive_bulk_callback(): fix error message\n\nSinc commit 79a6d1bfe114 (\"can: gs_usb: gs_usb_receive_bulk_callback():\nunanchor URL on usb_submit_urb() error\") a failing resubmit URB will print\nan info message.\n\nIn the case of a short read where netdev has not yet been assigned,\ninitialize as NULL to avoid dereferencing an undefined value. Also report\nthe error value of the failed resubmit.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/494fc029f662c331e06b7c2031deff3c64200eed","https://git.kernel.org/stable/c/713ba826ae114ab339c9a1b31e209bebdadb0ac9","https://git.kernel.org/stable/c/8986cdf52f86208df9c7887fee23365b5d37da26","https://git.kernel.org/stable/c/923379f1d7e3af8ccbf11edbbcf41f1bb3e9cfe6","https://git.kernel.org/stable/c/aed58a28ea71a0d7d0947190fab1e3f4daa1d4a5"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23156","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: fix error propagation in efivar_entry_get()\n\nefivar_entry_get() always returns success even if the underlying\n__efivar_entry_get() fails, masking errors.\n\nThis may result in uninitialized heap memory being copied to userspace\nin the efivarfs_file_read() path.\n\nFix it by returning the error from __efivar_entry_get().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3960f1754664661a970dc9ebbab44ff93a0b4c42","https://git.kernel.org/stable/c/4b22ec1685ce1fc0d862dcda3225d852fb107995","https://git.kernel.org/stable/c/510a16f1c5c1690b33504052bc13fbc2772c23f8","https://git.kernel.org/stable/c/89b8ca709eeeabcc11ebba64806677873a2787a8","https://git.kernel.org/stable/c/e4e15a0a4403c96d9898d8398f0640421df9cb16"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23157","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not strictly require dirty metadata threshold for metadata writepages\n\n[BUG]\nThere is an internal report that over 1000 processes are\nwaiting at the io_schedule_timeout() of balance_dirty_pages(), causing\na system hang and trigger a kernel coredump.\n\nThe kernel is v6.4 kernel based, but the root problem still applies to\nany upstream kernel before v6.18.\n\n[CAUSE]\nFrom Jan Kara for his wisdom on the dirty page balance behavior first.\n\n  This cgroup dirty limit was what was actually playing the role here\n  because the cgroup had only a small amount of memory and so the dirty\n  limit for it was something like 16MB.\n\n  Dirty throttling is responsible for enforcing that nobody can dirty\n  (significantly) more dirty memory than there's dirty limit. Thus when\n  a task is dirtying pages it periodically enters into balance_dirty_pages()\n  and we let it sleep there to slow down the dirtying.\n\n  When the system is over dirty limit already (either globally or within\n  a cgroup of the running task), we will not let the task exit from\n  balance_dirty_pages() until the number of dirty pages drops below the\n  limit.\n\n  So in this particular case, as I already mentioned, there was a cgroup\n  with relatively small amount of memory and as a result with dirty limit\n  set at 16MB. A task from that cgroup has dirtied about 28MB worth of\n  pages in btrfs btree inode and these were practically the only dirty\n  pages in that cgroup.\n\nSo that means the only way to reduce the dirty pages of that cgroup is\nto writeback the dirty pages of btrfs btree inode, and only after that\nthose processes can exit balance_dirty_pages().\n\nNow back to the btrfs part, btree_writepages() is responsible for\nwriting back dirty btree inode pages.\n\nThe problem here is, there is a btrfs internal threshold that if the\nbtree inode's dirty bytes are below the 32M threshold, it will not\ndo any writeback.\n\nThis behavior is to batch as much metadata as possible so we won't write\nback those tree blocks and then later re-COW them again for another\nmodification.\n\nThis internal 32MiB is higher than the existing dirty page size (28MiB),\nmeaning no writeback will happen, causing a deadlock between btrfs and\ncgroup:\n\n- Btrfs doesn't want to write back btree inode until more dirty pages\n\n- Cgroup/MM doesn't want more dirty pages for btrfs btree inode\n  Thus any process touching that btree inode is put into sleep until\n  the number of dirty pages is reduced.\n\nThanks Jan Kara a lot for the analysis of the root cause.\n\n[ENHANCEMENT]\nSince kernel commit b55102826d7d (\"btrfs: set AS_KERNEL_FILE on the\nbtree_inode\"), btrfs btree inode pages will only be charged to the root\ncgroup which should have a much larger limit than btrfs' 32MiB\nthreshold.\nSo it should not affect newer kernels.\n\nBut for all current LTS kernels, they are all affected by this problem,\nand backporting the whole AS_KERNEL_FILE may not be a good idea.\n\nEven for newer kernels I still think it's a good idea to get\nrid of the internal threshold at btree_writepages(), since for most cases\ncgroup/MM has a better view of full system memory usage than btrfs' fixed\nthreshold.\n\nFor internal callers using btrfs_btree_balance_dirty() since that\nfunction is already doing internal threshold check, we don't need to\nbother them.\n\nBut for external callers of btree_writepages(), just respect their\nrequests and write back whatever they want, ignoring the internal\nbtrfs threshold to avoid such deadlock on btree inode dirty page\nbalancing.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00604,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0c3666ec188640c20e254011e7adf4464c32ee58","https://git.kernel.org/stable/c/4357e02cafabe01c2d737ceb4c4c6382fc2ee10a","https://git.kernel.org/stable/c/4e159150a9a56d66d247f4b5510bed46fe58aa1c","https://git.kernel.org/stable/c/629666d20c7dcd740e193ec0631fdff035b1f7d6","https://git.kernel.org/stable/c/bb9be3f713652e330df00f3724c18c7a5469e7ac"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23158","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: virtuser: fix UAF in configfs release path\n\nThe gpio-virtuser configfs release path uses guard(mutex) to protect\nthe device structure. However, the device is freed before the guard\ncleanup runs, causing mutex_unlock() to operate on freed memory.\n\nSpecifically, gpio_virtuser_device_config_group_release() destroys\nthe mutex and frees the device while still inside the guard(mutex)\nscope. When the function returns, the guard cleanup invokes\nmutex_unlock(&dev->lock), resulting in a slab use-after-free.\n\nLimit the mutex lifetime by using a scoped_guard() only around the\nactivation check, so that the lock is released before mutex_destroy()\nand kfree() are called.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0314,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/53ad4a948a4586359b841d607c08fb16c5503230","https://git.kernel.org/stable/c/7bec90f605cfb138006f5ba575f2310593347110","https://git.kernel.org/stable/c/815a8e3bf72811d402b30bd4a53cde5e9df7a563"],"published_time":"2026-02-14T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23140","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, test_run: Subtract size of xdp_frame from allowed metadata size\n\nThe xdp_frame structure takes up part of the XDP frame headroom,\nlimiting the size of the metadata. However, in bpf_test_run, we don't\ntake this into account, which makes it possible for userspace to supply\na metadata size that is too large (taking up the entire headroom).\n\nIf userspace supplies such a large metadata size in live packet mode,\nthe xdp_update_frame_from_buff() call in xdp_test_run_init_page() call\nwill fail, after which packet transmission proceeds with an\nuninitialised frame structure, leading to the usual Bad Stuff.\n\nThe commit in the Fixes tag fixed a related bug where the second check\nin xdp_update_frame_from_buff() could fail, but did not add any\nadditional constraints on the metadata size. Complete the fix by adding\nan additional check on the metadata size. Reorder the checks slightly to\nmake the logic clearer and add a comment.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/31e37f44b60679d90b9f999c91371b15291be8e0","https://git.kernel.org/stable/c/6447e697cfa8a43a8e491cb81bcc390d0f28f8ba","https://git.kernel.org/stable/c/7c81ad5e580bd8441f8a521a8d34824ce6582ae5","https://git.kernel.org/stable/c/e558cca217790286e799a8baacd1610bda31b261","https://git.kernel.org/stable/c/e7440935063949d6f2c10f7328d960d0ff4bce90"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23141","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: send: check for inline extents in range_is_hole_in_parent()\n\nBefore accessing the disk_bytenr field of a file extent item we need\nto check if we are dealing with an inline extent.\nThis is because for inline extents their data starts at the offset of\nthe disk_bytenr field. So accessing the disk_bytenr\nmeans we are accessing inline data or in case the inline data is less\nthan 8 bytes we can actually cause an invalid\nmemory access if this inline extent item is the first item in the leaf\nor access metadata from other items.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/08b096c1372cd69627f4f559fb47c9fb67a52b39","https://git.kernel.org/stable/c/39f83f10772310ba4a77f2b5256aaf36994ef7e8","https://git.kernel.org/stable/c/d948055bd46a9c14d1d4217aed65c5c258c32903","https://git.kernel.org/stable/c/db00636643e66898d79f2530ac9c56ebd5eca369","https://git.kernel.org/stable/c/f2dc6ab3a14c2d2eb0b14783427eb9b03bf631c9"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23142","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure\n\nWhen a DAMOS-scheme DAMON sysfs directory setup fails after setup of\naccess_pattern/ directory, subdirectories of access_pattern/ directory are\nnot cleaned up.  As a result, DAMON sysfs interface is nearly broken until\nthe system reboots, and the memory for the unremoved directory is leaked.\n\nCleanup the directories under such failures.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/16236b0b4a08fa3e326cf1373ef789dabdc2e30d","https://git.kernel.org/stable/c/392b3d9d595f34877dd745b470c711e8ebcd225c","https://git.kernel.org/stable/c/725d4fdaa01bd1161782081f419e1568cc7432e0","https://git.kernel.org/stable/c/ae8ac0066b48ed957bdcab58f0d3543549c57a29","https://git.kernel.org/stable/c/e9711bd0e64812c694a228cf58c9e6032decee54"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23143","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix misalignment bug in struct virtnet_info\n\nUse the new TRAILING_OVERLAP() helper to fix a misalignment bug\nalong with the following warning:\n\ndrivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]\n\nThis helper creates a union between a flexible-array member (FAM)\nand a set of members that would otherwise follow it (in this case\n`u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This\noverlays the trailing members (rss_hash_key_data) onto the FAM\n(hash_key_data) while keeping the FAM and the start of MEMBERS aligned.\nThe static_assert() ensures this alignment remains.\n\nNotice that due to tail padding in flexible `struct\nvirtio_net_rss_config_trailer`, `rss_trailer.hash_key_data`\n(at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at\noffset 84 in struct virtnet_info) are misaligned by one byte. See\nbelow:\n\nstruct virtio_net_rss_config_trailer {\n        __le16                     max_tx_vq;            /*     0     2 */\n        __u8                       hash_key_length;      /*     2     1 */\n        __u8                       hash_key_data[];      /*     3     0 */\n\n        /* size: 4, cachelines: 1, members: 3 */\n        /* padding: 1 */\n        /* last cacheline: 4 bytes */\n};\n\nstruct virtnet_info {\n...\n        struct virtio_net_rss_config_trailer rss_trailer; /*    80     4 */\n\n        /* XXX last struct has 1 byte of padding */\n\n        u8                         rss_hash_key_data[40]; /*    84    40 */\n...\n        /* size: 832, cachelines: 13, members: 48 */\n        /* sum members: 801, holes: 8, sum holes: 31 */\n        /* paddings: 2, sum paddings: 5 */\n};\n\nAfter changes, those members are correctly aligned at offset 795:\n\nstruct virtnet_info {\n...\n        union {\n                struct virtio_net_rss_config_trailer rss_trailer; /*   792     4 */\n                struct {\n                        unsigned char __offset_to_hash_key_data[3]; /*   792     3 */\n                        u8         rss_hash_key_data[40]; /*   795    40 */\n                };                                       /*   792    43 */\n        };                                               /*   792    44 */\n...\n        /* size: 840, cachelines: 14, members: 47 */\n        /* sum members: 801, holes: 8, sum holes: 35 */\n        /* padding: 4 */\n        /* paddings: 1, sum paddings: 4 */\n        /* last cacheline: 8 bytes */\n};\n\nAs a result, the RSS key passed to the device is shifted by 1\nbyte: the last byte is cut off, and instead a (possibly\nuninitialized) byte is added at the beginning.\n\nAs a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also\nmoved to the end, since it seems those three members should stick\naround together. :)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4156c3745f06bc197094b9ee97a9584e69ed00bf","https://git.kernel.org/stable/c/ae48108c2310f1dd700e0dbb655c2f1d92ed00fc"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23144","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/sysfs: cleanup attrs subdirs on context dir setup failure\n\nWhen a context DAMON sysfs directory setup is failed after setup of attrs/\ndirectory, subdirectories of attrs/ directory are not cleaned up.  As a\nresult, DAMON sysfs interface is nearly broken until the system reboots,\nand the memory for the unremoved directory is leaked.\n\nCleanup the directories under such failures.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/43964644348f6b1add3055c4a6cae8f77d892a6e","https://git.kernel.org/stable/c/5651c0c391c0029541794f9c4c9597faecfd401f","https://git.kernel.org/stable/c/78b4eb99751ebd37ceade78810bf94de80f7fb3a","https://git.kernel.org/stable/c/9814cc832b88bd040fc2a1817c2b5469d0f7e862","https://git.kernel.org/stable/c/db7dfe78fc81bdd2b532d77f340fe453f2360426"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23145","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix iloc.bh leak in ext4_xattr_inode_update_ref\n\nThe error branch for ext4_xattr_inode_update_ref forget to release the\nrefcount for iloc.bh. Find this when review code.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/06e26287f2e349a28ad363941ffd9076bfed8b2e","https://git.kernel.org/stable/c/0b06cde92f2f960f4ebe3c988c69f2711f2a24dc","https://git.kernel.org/stable/c/3b00c16e42428a1ecd3a5eb9cc37f8ad9bd47626","https://git.kernel.org/stable/c/6241cd1d0acc2363016ac55b8773ba1332dd59d7","https://git.kernel.org/stable/c/7c9f059c3d531a12d7ad96cd34a44b8af7c00d5f","https://git.kernel.org/stable/c/8e8542c539927ae3898a4d02941f84e252e2dea1","https://git.kernel.org/stable/c/d250bdf531d9cd4096fedbb9f172bb2ca660c868"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23146","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work\n\nhci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling\nhci_uart_register_dev(), which calls proto->open() to initialize\nhu->priv. However, if a TTY write wakeup occurs during this window,\nhci_uart_tx_wakeup() may schedule write_work before hu->priv is\ninitialized, leading to a NULL pointer dereference in\nhci_uart_write_work() when proto->dequeue() accesses hu->priv.\n\nThe race condition is:\n\n  CPU0                              CPU1\n  ----                              ----\n  hci_uart_set_proto()\n    set_bit(HCI_UART_PROTO_INIT)\n    hci_uart_register_dev()\n                                    tty write wakeup\n                                      hci_uart_tty_wakeup()\n                                        hci_uart_tx_wakeup()\n                                          schedule_work(&hu->write_work)\n      proto->open(hu)\n        // initializes hu->priv\n                                    hci_uart_write_work()\n                                      hci_uart_dequeue()\n                                        proto->dequeue(hu)\n                                          // accesses hu->priv (NULL!)\n\nFix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open()\nsucceeds, ensuring hu->priv is initialized before any work can be\nscheduled.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03e8c90c62233382042b7bd0fa8b8900552fdb62","https://git.kernel.org/stable/c/0c3cd7a0b862c37acbee6d9502107146cc944398","https://git.kernel.org/stable/c/186d147cf7689ba1f9b3ddb753ab634a84940cc9","https://git.kernel.org/stable/c/53e54cb31e667fca05b1808b990eac0807d1dab0","https://git.kernel.org/stable/c/937a573423ce5a96fdb1fd425dc6b8d8d4ab5779","https://git.kernel.org/stable/c/b0a900939e7e4866d9b90e9112514b72c451e873","https://git.kernel.org/stable/c/ccc683f597ceb28deb966427ae948e5ac739a909"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23147","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zlib: fix the folio leak on S390 hardware acceleration\n\n[BUG]\nAfter commit aa60fe12b4f4 (\"btrfs: zlib: refactor S390x HW acceleration\nbuffer preparation\"), we no longer release the folio of the page cache\nof folio returned by btrfs_compress_filemap_get_folio() for S390\nhardware acceleration path.\n\n[CAUSE]\nBefore that commit, we call kumap_local() and folio_put() after handling\neach folio.\n\nAlthough the timing is not ideal (it release previous folio at the\nbeginning of the loop, and rely on some extra cleanup out of the loop),\nit at least handles the folio release correctly.\n\nMeanwhile the refactored code is easier to read, it lacks the call to\nrelease the filemap folio.\n\n[FIX]\nAdd the missing folio_put() for copy_data_into_buffer().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d0f1314e8f86f5205f71f9e31e272a1d008e40b","https://git.kernel.org/stable/c/e80617a5e1c246da2f112a1a072cdd535046adfe"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23148","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference\n\nThere is a race condition in nvmet_bio_done() that can cause a NULL\npointer dereference in blk_cgroup_bio_start():\n\n1. nvmet_bio_done() is called when a bio completes\n2. nvmet_req_complete() is called, which invokes req->ops->queue_response(req)\n3. The queue_response callback can re-queue and re-submit the same request\n4. The re-submission reuses the same inline_bio from nvmet_req\n5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete)\n   invokes bio_uninit() for inline_bio, which sets bio->bi_blkg to NULL\n6. The re-submitted bio enters submit_bio_noacct_nocheck()\n7. blk_cgroup_bio_start() dereferences bio->bi_blkg, causing a crash:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000028\n  #PF: supervisor read access in kernel mode\n  RIP: 0010:blk_cgroup_bio_start+0x10/0xd0\n  Call Trace:\n   submit_bio_noacct_nocheck+0x44/0x250\n   nvmet_bdev_execute_rw+0x254/0x370 [nvmet]\n   process_one_work+0x193/0x3c0\n   worker_thread+0x281/0x3a0\n\nFix this by reordering nvmet_bio_done() to call nvmet_req_bio_put()\nBEFORE nvmet_req_complete(). This ensures the bio is cleaned up before\nthe request can be re-submitted, preventing the race condition.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00036,"ranking_epss":0.10663,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0fcee2cfc4b2e16e62ff8e0cc2cd8dd24efad65e","https://git.kernel.org/stable/c/68207ceefd71cc74ce4e983fa9bd10c3122e349b","https://git.kernel.org/stable/c/ee10b06980acca1d46e0fa36d6fb4a9578eab6e4"],"published_time":"2026-02-14T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23132","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/bridge: synopsys: dw-dp: fix error paths of dw_dp_bind\n\nFix several issues in dw_dp_bind() error handling:\n\n1. Missing return after drm_bridge_attach() failure - the function\n   continued execution instead of returning an error.\n\n2. Resource leak: drm_dp_aux_register() is not a devm function, so\n   drm_dp_aux_unregister() must be called on all error paths after\n   aux registration succeeds. This affects errors from:\n   - drm_bridge_attach()\n   - phy_init()\n   - devm_add_action_or_reset()\n   - platform_get_irq()\n   - devm_request_threaded_irq()\n\n3. Bug fix: platform_get_irq() returns the IRQ number or a negative\n   error code, but the error path was returning ERR_PTR(ret) instead\n   of ERR_PTR(dp->irq).\n\nUse a goto label for cleanup to ensure consistent error handling.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04254,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1a0f69e3c28477b97d3609569b7e8feb4b6162e8","https://git.kernel.org/stable/c/569ed6a73e927a34cae4ae6de1464c0737a5ec44"],"published_time":"2026-02-14T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23133","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: fix dma_free_coherent() pointer\n\ndma_alloc_coherent() allocates a DMA mapped buffer and stores the\naddresses in XXX_unaligned fields.  Those should be reused when freeing\nthe buffer rather than the aligned addresses.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/07f363f305793baecad41816f73056252f3df61e","https://git.kernel.org/stable/c/1928851334ecfd6e0d663121ab69ac639d4217a6","https://git.kernel.org/stable/c/5d6fa4d2c9799c09389588da5118a72d97d87e92","https://git.kernel.org/stable/c/9282a1e171ad8d2205067e8ec3bbe4e3cef4f29f","https://git.kernel.org/stable/c/b0ad924332a96550a84b8c0ae5483e7042d65fa9","https://git.kernel.org/stable/c/e2dda298ef809aa201ea7c0904c4d064f6c497cb","https://git.kernel.org/stable/c/fc8da65f9fe1bc6802f8240b342cfff4f5c7e841"],"published_time":"2026-02-14T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23134","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nslab: fix kmalloc_nolock() context check for PREEMPT_RT\n\nOn PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current\ncheck in kmalloc_nolock() only verifies we're not in NMI or hard IRQ\ncontext, but misses the case where preemption is disabled.\n\nWhen a BPF program runs from a tracepoint with preemption disabled\n(preempt_count > 0), kmalloc_nolock() proceeds to call\nlocal_lock_irqsave() which attempts to acquire a sleeping lock,\ntriggering:\n\n  BUG: sleeping function called from invalid context\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128\n  preempt_count: 2, expected: 0\n\nFix this by checking !preemptible() on PREEMPT_RT, which directly\nexpresses the constraint that we cannot take a sleeping lock when\npreemption is disabled. This encompasses the previous checks for NMI\nand hard IRQ contexts while also catching cases where preemption is\ndisabled.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/99a3e3a1cfc93b8fe318c0a3a5cfb01f1d4ad53c","https://git.kernel.org/stable/c/f60ba4a97ae3f94e4818722ed2e4d260bbb17b44"],"published_time":"2026-02-14T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23135","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix dma_free_coherent() pointer\n\ndma_alloc_coherent() allocates a DMA mapped buffer and stores the\naddresses in XXX_unaligned fields.  Those should be reused when freeing\nthe buffer rather than the aligned addresses.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/24585a13c41ea7253ee59aac74441fb570f5824a","https://git.kernel.org/stable/c/36e0bc5e8b282564906fca636c4ebc99814de4e7","https://git.kernel.org/stable/c/4846b32be324f4dd3653f38a3f69c049543d52ae","https://git.kernel.org/stable/c/bb97131fbf9b708dd9616ac2bdc793ad102b5c48"],"published_time":"2026-02-14T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23136","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: reset sparse-read state in osd_fault()\n\nWhen a fault occurs, the connection is abandoned, reestablished, and any\npending operations are retried. The OSD client tracks the progress of a\nsparse-read reply using a separate state machine, largely independent of\nthe messenger's state.\n\nIf a connection is lost mid-payload or the sparse-read state machine\nreturns an error, the sparse-read state is not reset. The OSD client\nwill then interpret the beginning of a new reply as the continuation of\nthe old one. If this makes the sparse-read machinery enter a failure\nstate, it may never recover, producing loops like:\n\n  libceph:  [0] got 0 extents\n  libceph: data len 142248331 != extent len 0\n  libceph: osd0 (1)...:6801 socket error on read\n  libceph: data len 142248331 != extent len 0\n  libceph: osd0 (1)...:6801 socket error on read\n\nTherefore, reset the sparse-read state in osd_fault(), ensuring retries\nstart from a clean state.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00035,"ranking_epss":0.10512,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/10b7c72810364226f7b27916ea3e2a4f870bc04b","https://git.kernel.org/stable/c/11194b416ef95012c2cfe5f546d71af07b639e93","https://git.kernel.org/stable/c/90a60fe61908afa0eaf7f8fcf1421b9b50e5f7ff","https://git.kernel.org/stable/c/e94075e950a6598e710b9f7dffea5aa388f40313"],"published_time":"2026-02-14T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23137","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nof: unittest: Fix memory leak in unittest_data_add()\n\nIn unittest_data_add(), if of_resolve_phandles() fails, the allocated\nunittest_data is not freed, leading to a memory leak.\n\nFix this by using scope-based cleanup helper __free(kfree) for automatic\nresource cleanup. This ensures unittest_data is automatically freed when\nit goes out of scope in error paths.\n\nFor the success path, use retain_and_null_ptr() to transfer ownership\nof the memory to the device tree and prevent double freeing.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/235a1eb8d2dcc49a6cf0a5ee1aa85544a5d0054b","https://git.kernel.org/stable/c/f09b0f705bd7197863b90256ef533a6414d1db2c"],"published_time":"2026-02-14T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23138","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add recursion protection in kernel stack trace recording\n\nA bug was reported about an infinite recursion caused by tracing the rcu\nevents with the kernel stack trace trigger enabled. The stack trace code\ncalled back into RCU which then called the stack trace again.\n\nExpand the ftrace recursion protection to add a set of bits to protect\nevents from recursion. Each bit represents the context that the event is\nin (normal, softirq, interrupt and NMI).\n\nHave the stack trace code use the interrupt context to protect against\nrecursion.\n\nNote, the bug showed an issue in both the RCU code as well as the tracing\nstacktrace code. This only handles the tracing stack trace side of the\nbug. The RCU fix will be handled separately.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/19e18e6dabb1bbba76d2809ca7d8ae9e1f5975fe","https://git.kernel.org/stable/c/5b7f91acffd2c4c000971553d22efa1e1bb4feae","https://git.kernel.org/stable/c/5f1ef0dfcb5b7f4a91a9b0e0ba533efd9f7e2cdb","https://git.kernel.org/stable/c/9b03768037d91ce727effb1c5d92d2c7781bf692"],"published_time":"2026-02-14T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23139","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conncount: update last_gc only when GC has been performed\n\nCurrently last_gc is being updated everytime a new connection is\ntracked, that means that it is updated even if a GC wasn't performed.\nWith a sufficiently high packet rate, it is possible to always bypass\nthe GC, causing the list to grow infinitely.\n\nUpdate the last_gc value only when a GC has been actually performed.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00031,"ranking_epss":0.08966,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/26a82dce2beee39c43c109d9647e16f49cb02a35","https://git.kernel.org/stable/c/2c7c71113ed6d3e2f3aca4c088f22283016ff34f","https://git.kernel.org/stable/c/3cd717359e56f82f06cbf8279b47a7d79880c6f3","https://git.kernel.org/stable/c/7811ba452402d58628e68faedf38745b3d485e3c","https://git.kernel.org/stable/c/8bdafdf4900040a81422056cabe5e00a37bd101a","https://git.kernel.org/stable/c/9f45588993d7f115280fc726119ca86fba32a811","https://git.kernel.org/stable/c/c4cde57c8affdcca5bcff53a1047e15d268bdca1"],"published_time":"2026-02-14T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71201","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix early read unlock of page with EOF in middle\n\nThe read result collection for buffered reads seems to run ahead of the\ncompletion of subrequests under some circumstances, as can be seen in the\nfollowing log snippet:\n\n    9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0\n    ...\n    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0\n    ...\n    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2\n    netfs_folio: i=157f3 ix=00004-00004 read-done\n    netfs_folio: i=157f3 ix=00004-00004 read-unlock\n    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2\n    netfs_folio: i=157f3 ix=00005-00005 read-done\n    netfs_folio: i=157f3 ix=00005-00005 read-unlock\n    ...\n    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c\n    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8\n    ...\n    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0\n    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0\n\nThe 'cto=5fb2' indicates the collected file pos we've collected results to\nso far - but we still have 0x4e more bytes to go - so we shouldn't have\ncollected folio ix=00005 yet.  The 'ZERO' subreq that clears the tail\nhappens after we unlock the folio, allowing the application to see the\nuncleared tail through mmap.\n\nThe problem is that netfs_read_unlock_folios() will unlock a folio in which\nthe amount of read results collected hits EOF position - but the ZERO\nsubreq lies beyond that and so happens after.\n\nFix this by changing the end check to always be the end of the folio and\nnever the end of the file.\n\nIn the future, I should look at clearing to the end of the folio here rather\nthan adding a ZERO subreq to do this.  On the other hand, the ZERO subreq can\nrun in parallel with an async READ subreq.  Further, the ZERO subreq may still\nbe necessary to, say, handle extents in a ceph file that don't have any\nbacking store and are thus implicitly all zeros.\n\nThis can be reproduced by creating a file, the size of which doesn't align\nto a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something\nlike:\n\n    xfs_io -c \"mmap -r 0 0x6000\" -c \"madvise -d 0 0x6000\" \\\n           -c \"mread -v 0 0x6000\" /xfstest.test/x\n\nThe last 0x4e bytes should all be 00, but if the tail hasn't been cleared\nyet, you may see rubbish there.  This can be reproduced with kafs by\nmodifying the kernel to disable the call to netfs_read_subreq_progress()\nand to stop afs_issue_read() from doing the async call for NETFS_READAHEAD.\nReproduction can be made easier by inserting an mdelay(100) in\nnetfs_issue_read() for the ZERO-subreq case.\n\nAFS and CIFS are normally unlikely to show this as they dispatch READ ops\nasynchronously, which allows the ZERO-subreq to finish first.  9P's READ op is\ncompletely synchronous, so the ZERO-subreq will always happen after.  It isn't\nseen all the time, though, because the collection may be done in a worker\nthread.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/570ad253a3455a520f03c2136af8714bc780186d","https://git.kernel.org/stable/c/5b5482c0e5ee740b35a70759d3582477aea8e8e4"],"published_time":"2026-02-14T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71202","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/sva: invalidate stale IOTLB entries for kernel address space\n\nIntroduce a new IOMMU interface to flush IOTLB paging cache entries for\nthe CPU kernel address space.  This interface is invoked from the x86\narchitecture code that manages combined user and kernel page tables,\nspecifically before any kernel page table page is freed and reused.\n\nThis addresses the main issue with vfree() which is a common occurrence\nand can be triggered by unprivileged users.  While this resolves the\nprimary problem, it doesn't address some extremely rare case related to\nmemory unplug of memory that was present as reserved memory at boot, which\ncannot be triggered by unprivileged users.  The discussion can be found at\nthe link below.\n\nEnable SVA on x86 architecture since the IOMMU can now receive\nnotification to flush the paging cache before freeing the CPU kernel page\ntable pages.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/9f0a7ab700f8620e433b05c57fbd26c92ea186d9","https://git.kernel.org/stable/c/e37d5a2d60a338c5917c45296bac65da1382eda5"],"published_time":"2026-02-14T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23128","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: Set __nocfi on swsusp_arch_resume()\n\nA DABT is reported[1] on an android based system when resume from hiberate.\nThis happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*()\nand does not have a CFI hash, but swsusp_arch_resume() will attempt to\nverify the CFI hash when calling a copy of swsusp_arch_suspend_exit().\n\nGiven that there's an existing requirement that the entrypoint to\nswsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text\nsection, we cannot fix this by marking swsusp_arch_suspend_exit() with\nSYM_FUNC_*(). The simplest fix for now is to disable the CFI check in\nswsusp_arch_resume().\n\nMark swsusp_arch_resume() as __nocfi to disable the CFI check.\n\n[1]\n[   22.991934][    T1] Unable to handle kernel paging request at virtual address 0000000109170ffc\n[   22.991934][    T1] Mem abort info:\n[   22.991934][    T1]   ESR = 0x0000000096000007\n[   22.991934][    T1]   EC = 0x25: DABT (current EL), IL = 32 bits\n[   22.991934][    T1]   SET = 0, FnV = 0\n[   22.991934][    T1]   EA = 0, S1PTW = 0\n[   22.991934][    T1]   FSC = 0x07: level 3 translation fault\n[   22.991934][    T1] Data abort info:\n[   22.991934][    T1]   ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n[   22.991934][    T1]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[   22.991934][    T1]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[   22.991934][    T1] [0000000109170ffc] user address but active_mm is swapper\n[   22.991934][    T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP\n[   22.991934][    T1] Dumping ftrace buffer:\n[   22.991934][    T1]    (ftrace buffer empty)\n[   22.991934][    T1] Modules linked in:\n[   22.991934][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419\n[   22.991934][    T1] Hardware name: Unisoc UMS9360-base Board (DT)\n[   22.991934][    T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   22.991934][    T1] pc : swsusp_arch_resume+0x2ac/0x344\n[   22.991934][    T1] lr : swsusp_arch_resume+0x294/0x344\n[   22.991934][    T1] sp : ffffffc08006b960\n[   22.991934][    T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000\n[   22.991934][    T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820\n[   22.991934][    T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000\n[   22.991934][    T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058\n[   22.991934][    T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004\n[   22.991934][    T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000\n[   22.991934][    T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000\n[   22.991934][    T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b\n[   22.991934][    T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530\n[   22.991934][    T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000\n[   22.991934][    T1] Call trace:\n[   22.991934][    T1]  swsusp_arch_resume+0x2ac/0x344\n[   22.991934][    T1]  hibernation_restore+0x158/0x18c\n[   22.991934][    T1]  load_image_and_restore+0xb0/0xec\n[   22.991934][    T1]  software_resume+0xf4/0x19c\n[   22.991934][    T1]  software_resume_initcall+0x34/0x78\n[   22.991934][    T1]  do_one_initcall+0xe8/0x370\n[   22.991934][    T1]  do_initcall_level+0xc8/0x19c\n[   22.991934][    T1]  do_initcalls+0x70/0xc0\n[   22.991934][    T1]  do_basic_setup+0x1c/0x28\n[   22.991934][    T1]  kernel_init_freeable+0xe0/0x148\n[   22.991934][    T1]  kernel_init+0x20/0x1a8\n[   22.991934][    T1]  ret_from_fork+0x10/0x20\n[   22.991934][    T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)\n\n[catalin.marinas@arm.com: commit log updated by Mark Rutland]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/122b7cb80f7d468fcc2d18cf7eb320f09f310a96","https://git.kernel.org/stable/c/6e32070d29d1a35d8f4b3c03babf6c0e5efd1d08","https://git.kernel.org/stable/c/8557bdd9af8dd04911fba56ff92b17842b0b5c7f","https://git.kernel.org/stable/c/9773a886f26766a8db92d4b342b620a82c2de7dd","https://git.kernel.org/stable/c/e2f8216ca2d8e61a23cb6ec355616339667e0ba6"],"published_time":"2026-02-14T15:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23129","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndpll: Prevent duplicate registrations\n\nModify the internal registration helpers dpll_xa_ref_{dpll,pin}_add()\nto reject duplicate registration attempts.\n\nPreviously, if a caller attempted to register the same pin multiple\ntimes (with the same ops, priv, and cookie) on the same device, the core\nsilently increments the reference count and return success. This behavior\nis incorrect because if the caller makes these duplicate registrations\nthen for the first one dpll_pin_registration is allocated and for others\nthe associated dpll_pin_ref.refcount is incremented. During the first\nunregistration the associated dpll_pin_registration is freed and for\nothers WARN is fired.\n\nFix this by updating the logic to return `-EEXIST` if a matching\nregistration is found to enforce a strict \"register once\" policy.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/236a657422a564859dcd0db7bdb486abb21a721a","https://git.kernel.org/stable/c/dfec0501dba8f4711ef142a6a890e4812b7af88c","https://git.kernel.org/stable/c/f3ddbaaaaf4d0633b40482f471753f9c71294a4a"],"published_time":"2026-02-14T15:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23130","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix dead lock while flushing management frames\n\nCommit [1] converted the management transmission work item into a\nwiphy work. Since a wiphy work can only run under wiphy lock\nprotection, a race condition happens in below scenario:\n\n1. a management frame is queued for transmission.\n2. ath12k_mac_op_flush() gets called to flush pending frames associated\n   with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush()\n   the process waits for the transmission done.\n3. Since wiphy lock has been taken by the flush process, the transmission\n   work item has no chance to run, hence the dead lock.\n\n>From user view, this dead lock results in below issue:\n\n wlp8s0: authenticate with xxxxxx (local address=xxxxxx)\n wlp8s0: send auth to xxxxxx (try 1/3)\n wlp8s0: authenticate with xxxxxx (local address=xxxxxx)\n wlp8s0: send auth to xxxxxx (try 1/3)\n wlp8s0: authenticated\n wlp8s0: associate with xxxxxx (try 1/3)\n wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)\n ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1\n\nThe dead lock can be avoided by invoking wiphy_work_flush() to proactively\nrun the queued work item. Note actually it is already present in\nath12k_mac_op_flush(), however it does not protect the case where vif\nbeing NULL. Hence move it ahead to cover this case as well.\n\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03072,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/06ac2aa13f701a0296e92f5f54ae24224d426b28","https://git.kernel.org/stable/c/f88e9fc30a261d63946ddc6cc6a33405e6aa27c3"],"published_time":"2026-02-14T15:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23131","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names\n\nThe hp-bioscfg driver attempts to register kobjects with empty names when\nthe HP BIOS returns attributes with empty name strings. This causes\nmultiple kernel warnings:\n\n  kobject: (00000000135fb5e6): attempted to be registered with empty name!\n  WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310\n\nAdd validation in hp_init_bios_buffer_attribute() to check if the\nattribute name is empty after parsing it from the WMI buffer. If empty,\nlog a debug message and skip registration of that attribute, allowing the\nmodule to continue processing other valid attributes.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/29917c80aa96a25cbcf5876fd774a1cfd72b01a9","https://git.kernel.org/stable/c/6476be59b7162b891b7bddbd0c2924d87379ef6c","https://git.kernel.org/stable/c/800b2767905d6b409b8bbe357121970f0b489a89","https://git.kernel.org/stable/c/fdee1b09721605f532352628d0a24623e7062efb"],"published_time":"2026-02-14T15:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23119","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: provide a net pointer to __skb_flow_dissect()\n\nAfter 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\")\nwe have to provide a net pointer to __skb_flow_dissect(),\neither via skb->dev, skb->sk, or a user provided pointer.\n\nIn the following case, syzbot was able to cook a bare skb.\n\nWARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053\nCall Trace:\n <TASK>\n  bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline]\n  __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157\n  bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline]\n  bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline]\n  bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515\n  xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388\n  bpf_prog_run_xdp include/net/xdp.h:700 [inline]\n  bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421\n  bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390\n  bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703\n  __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182\n  __do_sys_bpf kernel/bpf/syscall.c:6274 [inline]\n  __se_sys_bpf kernel/bpf/syscall.c:6272 [inline]\n  __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0efee0b992f28bd5ee01c7a86ef6a307c42eb907","https://git.kernel.org/stable/c/3be945abdd228fd00f6afcf8d137002867a4651b","https://git.kernel.org/stable/c/5f9b329096596b7e53e07d041d7fca4cbe1be752","https://git.kernel.org/stable/c/8e53780732ee881394406f79da5263b81eb48f7e","https://git.kernel.org/stable/c/bc3c8d2493c6f4d2038844dc8b7ee93de050f7fa","https://git.kernel.org/stable/c/de97735a40a144974bf3896ee4cc0270db2e47db","https://git.kernel.org/stable/c/f4faaa1297ecf3255a8591fff2633df05bd5ec84"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23120","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: avoid one data-race in l2tp_tunnel_del_work()\n\nWe should read sk->sk_socket only when dealing with kernel sockets.\n\nsyzbot reported the following data-race:\n\nBUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release\n\nwrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:\n  sk_set_socket include/net/sock.h:2092 [inline]\n  sock_orphan include/net/sock.h:2118 [inline]\n  sk_common_release+0xae/0x230 net/core/sock.c:4003\n  udp_lib_close+0x15/0x20 include/net/udp.h:325\n  inet_release+0xce/0xf0 net/ipv4/af_inet.c:437\n  __sock_release net/socket.c:662 [inline]\n  sock_close+0x6b/0x150 net/socket.c:1455\n  __fput+0x29b/0x650 fs/file_table.c:468\n  ____fput+0x1c/0x30 fs/file_table.c:496\n  task_work_run+0x131/0x1a0 kernel/task_work.c:233\n  resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n  __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]\n  exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75\n  __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]\n  syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]\n  syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]\n  syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]\n  do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:\n  l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418\n  process_one_work kernel/workqueue.c:3257 [inline]\n  process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340\n  worker_thread+0x582/0x770 kernel/workqueue.c:3421\n  kthread+0x489/0x510 kernel/kthread.c:463\n  ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n\nvalue changed: 0xffff88811b818000 -> 0x0000000000000000","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1f63ca44b4f419a1663d94d1bb0b4e2beb73fdb4","https://git.kernel.org/stable/c/32d417497b79efb403d75f4c185fe6fd9d64b94f","https://git.kernel.org/stable/c/36c40a80109f1771d59558050b1a71e13c60c759","https://git.kernel.org/stable/c/3d6d414b214ce31659bded2f8df50c93a3769474","https://git.kernel.org/stable/c/68e92085427c84e7679ddb53c0d68836d220b6e7","https://git.kernel.org/stable/c/7a29f6bf60f2590fe5e9c4decb451e19afad2bcf","https://git.kernel.org/stable/c/eae074dab764ea181bbed5e88626889319177498"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23121","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: annotate data-race around dev->work\n\ndev->work can re read locklessly in mISDN_read()\nand mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.\n\nBUG: KCSAN: data-race in mISDN_ioctl / mISDN_read\n\nwrite to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1:\n  misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline]\n  mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233\n  vfs_ioctl fs/ioctl.c:51 [inline]\n  __do_sys_ioctl fs/ioctl.c:597 [inline]\n  __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583\n  __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583\n  x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0:\n  mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112\n  do_loop_readv_writev fs/read_write.c:847 [inline]\n  vfs_readv+0x3fb/0x690 fs/read_write.c:1020\n  do_readv+0xe7/0x210 fs/read_write.c:1080\n  __do_sys_readv fs/read_write.c:1165 [inline]\n  __se_sys_readv fs/read_write.c:1162 [inline]\n  __x64_sys_readv+0x45/0x50 fs/read_write.c:1162\n  x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nvalue changed: 0x00000000 -> 0x00000001","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/13f3b3b87068898056db4c79ee67052fbde11d43","https://git.kernel.org/stable/c/7ac345a93af31358e18e9606eb7b354691bf6757","https://git.kernel.org/stable/c/8175dbf174d487afab81e936a862a8d9b8a1ccb6","https://git.kernel.org/stable/c/aa6e33cd74ca4965f2bbcb025e0b672fb0168a69","https://git.kernel.org/stable/c/accc3f8266d2a49881dbcf78c459477f4efa0ff3","https://git.kernel.org/stable/c/d5d99cb9e0839093cd53aa3b28176fce2f820ca0","https://git.kernel.org/stable/c/fc8ba17fd3337bd8b1913c30b95df0fee00d8fb7"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23122","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nigc: Reduce TSN TX packet buffer from 7KB to 5KB per queue\n\nThe previous 7 KB per queue caused TX unit hangs under heavy\ntimestamping load. Reducing to 5 KB avoids these hangs and matches\nthe TSN recommendation in I225/I226 SW User Manual Section 7.5.4.\n\nThe 8 KB \"freed\" by this change is currently unused. This reduction\nis not expected to impact throughput, as the i226 is PCIe-limited\nfor small TSN packets rather than TX-buffer-limited.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/88037973c8ef6032bf84e9955595f8b20bc14c21","https://git.kernel.org/stable/c/8ad1b6c1e63d25f5465b7a8aa403bdcee84b86f9"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23123","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: debugfs: initialize src_node and dst_node to empty strings\n\nThe debugfs_create_str() API assumes that the string pointer is either NULL\nor points to valid kmalloc() memory. Leaving the pointer uninitialized can\ncause problems.\n\nInitialize src_node and dst_node to empty strings before creating the\ndebugfs entries to guarantee that reads and writes are safe.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5d7c7e1fb3ec24fdd0f9faa27b666d6789e891e8","https://git.kernel.org/stable/c/8cc27f5c6dd17dd090f3a696683f04336c162ff5","https://git.kernel.org/stable/c/935d0938b570589c8b0a1733d2cba3c39d027f25","https://git.kernel.org/stable/c/aa79a5a959c7c414bd6fba01ea8dbaddd44f13e7"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23124","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: annotate data-race in ndisc_router_discovery()\n\nsyzbot found that ndisc_router_discovery() could read and write\nin6_dev->ra_mtu without holding a lock [1]\n\nThis looks fine, IFLA_INET6_RA_MTU is best effort.\n\nAdd READ_ONCE()/WRITE_ONCE() to document the race.\n\nNote that we might also reject illegal MTU values\n(mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.\n\n[1]\nBUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery\n\nread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1:\n  ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558\n  ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841\n  icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989\n  ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438\n  ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n  ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500\n  ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590\n  dst_input include/net/dst.h:474 [inline]\n  ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79\n...\n\nwrite to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0:\n  ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559\n  ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841\n  icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989\n  ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438\n  ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n  ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500\n  ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590\n  dst_input include/net/dst.h:474 [inline]\n  ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79\n...\n\nvalue changed: 0x00000000 -> 0xe5400659","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2619499169fb1c2ac4974b0f2d87767fb543582b","https://git.kernel.org/stable/c/2a2b9d25f801afecf2f83cacce98afa8fd73e3c9","https://git.kernel.org/stable/c/4630897eb1a039b5d7b737b8dc9521d9d4b568b5","https://git.kernel.org/stable/c/9a063f96d87efc3a6cc667f8de096a3d38d74bb5","https://git.kernel.org/stable/c/e3c1040252e598f7b4e33a42dc7c38519bc22428","https://git.kernel.org/stable/c/fad8f4ff7928f4d52a062ffdcffa484989c79c47"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23125","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT\n\nA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key\ninitialization fails:\n\n  ==================================================================\n  KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n  CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2\n  RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]\n  RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401\n  Call Trace:\n\n  sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189\n  sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111\n  sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217\n  sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787\n  sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n  sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169\n  sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052\n  sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88\n  sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243\n  sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127\n\nThe issue is triggered when sctp_auth_asoc_init_active_key() fails in\nsctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the\ncommand sequence is currently:\n\n- SCTP_CMD_PEER_INIT\n- SCTP_CMD_TIMER_STOP (T1_INIT)\n- SCTP_CMD_TIMER_START (T1_COOKIE)\n- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)\n- SCTP_CMD_ASSOC_SHKEY\n- SCTP_CMD_GEN_COOKIE_ECHO\n\nIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while\nasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by\nSCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL\nto be queued by sctp_datamsg_from_user().\n\nSince command interpretation stops on failure, no COOKIE_ECHO should been\nsent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already\nbeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. As\na result, the DATA chunk can be transmitted together with the COOKIE_ECHO\nin sctp_outq_flush_data(), leading to the observed issue.\n\nSimilar to the other places where it calls sctp_auth_asoc_init_active_key()\nright after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY\nimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting\nT1_COOKIE. This ensures that if shared key generation fails, authenticated\nDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,\ngiving the client another chance to process INIT_ACK and retry key setup.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02856,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0c4adb1f391a7b92a0405e9d7c05624c0d9f8a65","https://git.kernel.org/stable/c/5a309bedf02ee08b0653215f06c94d61ec7a214a","https://git.kernel.org/stable/c/784428ab1889eb185a1459e9d6bc52df33d572ef","https://git.kernel.org/stable/c/a80c9d945aef55b23b54838334345f20251dad83","https://git.kernel.org/stable/c/bf2b543b3cc4ebb4ab5bca4f8dfa5612035d45b8","https://git.kernel.org/stable/c/e7e81abbcc5620c9532080538f9709a6ea382855","https://git.kernel.org/stable/c/e94294798548e8cfbd80869e1d2f97efce92582c"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23126","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: fix a race issue related to the operation on bpf_bound_progs list\n\nThe netdevsim driver lacks a protection mechanism for operations on the\nbpf_bound_progs list. When the nsim_bpf_create_prog() performs\nlist_add_tail, it is possible that nsim_bpf_destroy_prog() is\nsimultaneously performs list_del. Concurrent operations on the list may\nlead to list corruption and trigger a kernel crash as follows:\n\n[  417.290971] kernel BUG at lib/list_debug.c:62!\n[  417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[  417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1\n[  417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  417.291007] Workqueue: events bpf_prog_free_deferred\n[  417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0\n[  417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8\n[  417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246\n[  417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000\n[  417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180\n[  417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003\n[  417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20\n[  417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000\n[  417.291074] FS:  0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000\n[  417.291079] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0\n[  417.291088] PKRU: 55555554\n[  417.291091] Call Trace:\n[  417.291096]  <TASK>\n[  417.291103]  nsim_bpf_destroy_prog+0x31/0x80 [netdevsim]\n[  417.291154]  __bpf_prog_offload_destroy+0x2a/0x80\n[  417.291163]  bpf_prog_dev_bound_destroy+0x6f/0xb0\n[  417.291171]  bpf_prog_free_deferred+0x18e/0x1a0\n[  417.291178]  process_one_work+0x18a/0x3a0\n[  417.291188]  worker_thread+0x27b/0x3a0\n[  417.291197]  ? __pfx_worker_thread+0x10/0x10\n[  417.291207]  kthread+0xe5/0x120\n[  417.291214]  ? __pfx_kthread+0x10/0x10\n[  417.291221]  ret_from_fork+0x31/0x50\n[  417.291230]  ? __pfx_kthread+0x10/0x10\n[  417.291236]  ret_from_fork_asm+0x1a/0x30\n[  417.291246]  </TASK>\n\nAdd a mutex lock, to prevent simultaneous addition and deletion operations\non the list.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00014,"ranking_epss":0.02431,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3f560cfc7706029294132482fff5d1bc7884b70d","https://git.kernel.org/stable/c/68462ecc40ea8f780fb3c74ebfddd05506bb731b","https://git.kernel.org/stable/c/b97d5eedf4976cc94321243be83b39efe81a0e15","https://git.kernel.org/stable/c/d77379ca82efcb2fe563359cc795027d680410db","https://git.kernel.org/stable/c/f1f9cfd2f46a73b7de2982d01be822eac3a0efaa"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23127","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix refcount warning on event->mmap_count increment\n\nWhen calling refcount_inc(&event->mmap_count) inside perf_mmap_rb(), the\nfollowing warning is triggered:\n\n        refcount_t: addition on 0; use-after-free.\n        WARNING: lib/refcount.c:25\n\nPoC:\n\n    struct perf_event_attr attr = {0};\n    int fd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0);\n    mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);\n    int victim = syscall(__NR_perf_event_open, &attr, 0, -1, fd,\n                         PERF_FLAG_FD_OUTPUT);\n    mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0);\n\nThis occurs when creating a group member event with the flag\nPERF_FLAG_FD_OUTPUT. The group leader should be mmap-ed and then mmap-ing\nthe event triggers the warning.\n\nSince the event has copied the output_event in perf_event_set_output(),\nevent->rb is set. As a result, perf_mmap_rb() calls\nrefcount_inc(&event->mmap_count) when event->mmap_count = 0.\n\nDisallow the case when event->mmap_count = 0. This also prevents two\nevents from updating the same user_page.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/23c0e4bd93d0b250775162faf456470485ac9fc7","https://git.kernel.org/stable/c/d06bf78e55d5159c1b00072e606ab924ffbbad35"],"published_time":"2026-02-14T15:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23113","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\n\nCurrently this is checked before running the pending work. Normally this\nis quite fine, as work items either end up blocking (which will create a\nnew worker for other items), or they complete fairly quickly. But syzbot\nreports an issue where io-wq takes seemingly forever to exit, and with a\nbit of debugging, this turns out to be because it queues a bunch of big\n(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't\nsupport ->read_iter(), loop_rw_iter() ends up handling them. Each read\nreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch of\nthese pending, processing the whole chain can take a long time. Easily\nlonger than the syzbot uninterruptible sleep timeout of 140 seconds.\nThis then triggers a complaint off the io-wq exit path:\n\nINFO: task syz.4.135:6326 blocked for more than 143 seconds.\n      Not tainted syzkaller #0\n      Blocked by coredump.\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:syz.4.135       state:D stack:26824 pid:6326  tgid:6324  ppid:5957   task_flags:0x400548 flags:0x00080000\nCall Trace:\n <TASK>\n context_switch kernel/sched/core.c:5256 [inline]\n __schedule+0x1139/0x6150 kernel/sched/core.c:6863\n __schedule_loop kernel/sched/core.c:6945 [inline]\n schedule+0xe7/0x3a0 kernel/sched/core.c:6960\n schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75\n do_wait_for_common kernel/sched/completion.c:100 [inline]\n __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121\n io_wq_exit_workers io_uring/io-wq.c:1328 [inline]\n io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356\n io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203\n io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651\n io_uring_files_cancel include/linux/io_uring.h:19 [inline]\n do_exit+0x2ce/0x2bd0 kernel/exit.c:911\n do_group_exit+0xd3/0x2a0 kernel/exit.c:1112\n get_signal+0x2671/0x26d0 kernel/signal.c:3034\n arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337\n __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]\n exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75\n __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]\n syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]\n do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fa02738f749\nRSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca\nRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749\nRDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098\nRBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98\n\nThere's really nothing wrong here, outside of processing these reads\nwill take a LONG time. However, we can speed up the exit by checking the\nIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will\nexit the ring after queueing up all of these reads. Then once the first\nitem is processed, io-wq will simply cancel the rest. That should avoid\nsyzbot running into this complaint again.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/10dc959398175736e495f71c771f8641e1ca1907","https://git.kernel.org/stable/c/2e8ca1078b14142db2ce51cbd18ff9971560046b","https://git.kernel.org/stable/c/85eb83694a91c89d9abe615d717c0053c3efa714","https://git.kernel.org/stable/c/bdf0bf73006ea8af9327cdb85cfdff4c23a5f966","https://git.kernel.org/stable/c/d05d99573f81a091547b1778b9a50120f5d6c68a"],"published_time":"2026-02-14T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23114","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: ptrace: Fix SVE writes on !SME systems\n\nWhen SVE is supported but SME is not supported, a ptrace write to the\nNT_ARM_SVE regset can place the tracee into an invalid state where\n(non-streaming) SVE register data is stored in FP_STATE_SVE format but\nTIF_SVE is clear. This can result in a later warning from\nfpsimd_restore_current_state(), e.g.\n\n  WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748\n\nWhen this happens, fpsimd_restore_current_state() will set TIF_SVE,\nplacing the task into the correct state. This occurs before any other\ncheck of TIF_SVE can possibly occur, as other checks of TIF_SVE only\nhappen while the FPSIMD/SVE/SME state is live. Thus, aside from the\nwarning, there is no functional issue.\n\nThis bug was introduced during rework to error handling in commit:\n\n  9f8bf718f2923 (\"arm64/fpsimd: ptrace: Gracefully handle errors\")\n\n... where the setting of TIF_SVE was moved into a block which is only\nexecuted when system_supports_sme() is true.\n\nFix this by removing the system_supports_sme() check. This ensures that\nTIF_SVE is set for (SVE-formatted) writes to NT_ARM_SVE, at the cost of\nunconditionally manipulating the tracee's saved svcr value. The\nmanipulation of svcr is benign and inexpensive, and we already do\nsimilar elsewhere (e.g. during signal handling), so I don't think it's\nworth guarding this with system_supports_sme() checks.\n\nAside from the above, there is no functional change. The 'type' argument\nto sve_set_common() is only set to ARM64_VEC_SME (in ssve_set())) when\nsystem_supports_sme(), so the ARM64_VEC_SME case in the switch statement\nis still unreachable when !system_supports_sme(). When\nCONFIG_ARM64_SME=n, the only caller of sve_set_common() is sve_set(),\nand the compiler can constant-fold for the case where type is\nARM64_VEC_SVE, removing the logic for other cases.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/128a7494a9f15aad60cc6b7e3546bf481ac54a13","https://git.kernel.org/stable/c/4f39984176e7edcaba3432b6c649c6fe93bf2f80"],"published_time":"2026-02-14T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23115","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nserial: Fix not set tty->port race condition\n\nRevert commit bfc467db60b7 (\"serial: remove redundant\ntty_port_link_device()\") because the tty_port_link_device() is not\nredundant: the tty->port has to be confured before we call\nuart_configure_port(), otherwise user-space can open console without TTY\nlinked to the driver.\n\nThis tty_port_link_device() was added explicitly to avoid this exact\nissue in commit fb2b90014d78 (\"tty: link tty and port before configuring\nit as console\"), so offending commit basically reverted the fix saying\nit is redundant without addressing the actual race condition presented\nthere.\n\nReproducible always as tty->port warning on Qualcomm SoC with most of\ndevices disabled, so with very fast boot, and one serial device being\nthe console:\n\n  printk: legacy console [ttyMSM0] enabled\n  printk: legacy console [ttyMSM0] enabled\n  printk: legacy bootconsole [qcom_geni0] disabled\n  printk: legacy bootconsole [qcom_geni0] disabled\n  ------------[ cut here ]------------\n  tty_init_dev: ttyMSM driver does not set tty->port. This would crash the kernel. Fix the driver!\n  WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1\n  Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6\n  CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S                  6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT\n  Tainted: [S]=CPU_OUT_OF_SPEC\n  Hardware name: Qualcomm Technologies, Inc. Eliza (DT)\n  ...\n  tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)\n  tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))\n  chrdev_open (fs/char_dev.c:411)\n  do_dentry_open (fs/open.c:962)\n  vfs_open (fs/open.c:1094)\n  do_open (fs/namei.c:4634)\n  path_openat (fs/namei.c:4793)\n  do_filp_open (fs/namei.c:4820)\n  do_sys_openat2 (fs/open.c:1391 (discriminator 3))\n  ...\n  Starting Network Name Resolution...\n\nApparently the flow with this small Yocto-based ramdisk user-space is:\n\ndriver (qcom_geni_serial.c):                  user-space:\n============================                  ===========\nqcom_geni_serial_probe()\n uart_add_one_port()\n  serial_core_register_port()\n   serial_core_add_one_port()\n    uart_configure_port()\n     register_console()\n    |\n    |                                         open console\n    |                                          ...\n    |                                          tty_init_dev()\n    |                                           driver->ports[idx] is NULL\n    |\n    tty_port_register_device_attr_serdev()\n     tty_port_link_device() <- set driver->ports[idx]","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00015,"ranking_epss":0.03072,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2501c49306238b54a2de0f93de43d50ab6e76c84","https://git.kernel.org/stable/c/32f37e57583f869140cff445feedeea8a5fea986"],"published_time":"2026-02-14T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23116","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\npmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu\n\nFor i.MX8MQ platform, the ADB in the VPUMIX domain has no separate reset\nand clock enable bits, but is ungated and reset together with the VPUs.\nSo we can't reset G1 or G2 separately, it may led to the system hang.\nRemove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data.\nLet imx8mq_vpu_power_notifier() do really vpu reset.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3de49966499634454fd59e0e6fecd50baab7febd","https://git.kernel.org/stable/c/5c56a6f4b5a4f87c094c92a30fa17e28e37ec2ab","https://git.kernel.org/stable/c/8859e336d233e61a4c40d40dc6a9f21e8b9b719c","https://git.kernel.org/stable/c/cad7003d951e8899db58ee2fef211586af726f09","https://git.kernel.org/stable/c/fd675de6bddf7e9bdf42ae3929d4c27ba6d1ef76"],"published_time":"2026-02-14T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23117","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nice: add missing ice_deinit_hw() in devlink reinit path\n\ndevlink-reload results in ice_init_hw failed error, and then removing\nthe ice driver causes a NULL pointer dereference.\n\n[  +0.102213] ice 0000:ca:00.0: ice_init_hw failed: -16\n...\n[  +0.000001] Call Trace:\n[  +0.000003]  <TASK>\n[  +0.000006]  ice_unload+0x8f/0x100 [ice]\n[  +0.000081]  ice_remove+0xba/0x300 [ice]\n\nCommit 1390b8b3d2be (\"ice: remove duplicate call to ice_deinit_hw() on\nerror paths\") removed ice_deinit_hw() from ice_deinit_dev(). As a result\nice_devlink_reinit_down() no longer calls ice_deinit_hw(), but\nice_devlink_reinit_up() still calls ice_init_hw(). Since the control\nqueues are not uninitialized, ice_init_hw() fails with -EBUSY.\n\nAdd ice_deinit_hw() to ice_devlink_reinit_down() to correspond with\nice_init_hw() in ice_devlink_reinit_up().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/42fb5f3deb582cb96440e4683745017dbabb83d6","https://git.kernel.org/stable/c/a3d99e2fbf01446d31a0d0dfc46444e915a1f6d4"],"published_time":"2026-02-14T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23118","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix data-race warning and potential load/store tearing\n\nFix the following:\n\n        BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet\n\nwhich is reporting an issue with the reads and writes to ->last_tx_at in:\n\n        conn->peer->last_tx_at = ktime_get_seconds();\n\nand:\n\n        keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;\n\nThe lockless accesses to these to values aren't actually a problem as the\nread only needs an approximate time of last transmission for the purposes\nof deciding whether or not the transmission of a keepalive packet is\nwarranted yet.\n\nAlso, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bit\narch.\n\nFix both of these by switching to an unsigned int for ->last_tx_at and only\nstoring the LSW of the time64_t.  It can then be reconstructed at need\nprovided no more than 68 years has elapsed since the last transmission.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00013,"ranking_epss":0.02328,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5d5fe8bcd331f1e34e0943ec7c18432edfcf0e8b","https://git.kernel.org/stable/c/a426f29ac3fa3465093567ab763ada46762fb57c","https://git.kernel.org/stable/c/c08cf314191cd0f8699089715efb9eff030f0086","https://git.kernel.org/stable/c/f8cf1368e0a5491b27189a695c36f64e48f3d19d"],"published_time":"2026-02-14T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71200","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode\n\nWhen operating in HS200 or HS400 timing modes, reducing the clock frequency\nbelow 52MHz will lead to link broken as the Rockchip DWC MSHC controller\nrequires maintaining a minimum clock of 52MHz in these modes.\n\nAdd a check to prevent illegal clock reduction through debugfs:\n\nroot@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock\nroot@debian:/# [   30.090146] mmc0: running CQE recovery\nmmc0: cqhci: Failed to halt\nmmc0: cqhci: spurious TCN for tag 0\nWARNING: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24\nModules linked in:\nCPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT\nHardware name: Rockchip RK3588 EVB1 V10 Board (DT)\nWorkqueue: kblockd blk_mq_run_work_fn\npstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : cqhci_irq+0x254/0x818\nlr : cqhci_irq+0x254/0x818\n...","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3009738a855cf938bbfc9078bec725031ae623a4","https://git.kernel.org/stable/c/36be050f21dea7a3a76dff5a031da6274e8ee468","https://git.kernel.org/stable/c/59b8a1ca6df4db2ca250e9eeab74e2b0068d69e9","https://git.kernel.org/stable/c/de0ad7156036a50982bcb75a080e4af284502be2","https://git.kernel.org/stable/c/f2677d6e2bbc5ba2030825522d2afd0542b038a3"],"published_time":"2026-02-14T15:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2441","summary":"Use after free in CSS in Google Chrome prior to 145.0.7632.75 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00203,"ranking_epss":0.42425,"kev":true,"propose_action":"Google Chromium CSS contains a use-after-free vulnerability that could allow a remote attacker to potentially exploit heap corruption via a crafted HTML page. This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera.","ransomware_campaign":"Unknown","references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/483569511","https://github.com/huseyinstif/CVE-2026-2441-PoC/blob/main/poc.html","https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-2441"],"published_time":"2026-02-13T19:17:31","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23111","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()\n\nnft_map_catchall_activate() has an inverted element activity check\ncompared to its non-catchall counterpart nft_mapelem_activate() and\ncompared to what is logically required.\n\nnft_map_catchall_activate() is called from the abort path to re-activate\ncatchall map elements that were deactivated during a failed transaction.\nIt should skip elements that are already active (they don't need\nre-activation) and process elements that are inactive (they need to be\nrestored). Instead, the current code does the opposite: it skips inactive\nelements and processes active ones.\n\nCompare the non-catchall activate callback, which is correct:\n\n  nft_mapelem_activate():\n    if (nft_set_elem_active(ext, iter->genmask))\n        return 0;   /* skip active, process inactive */\n\nWith the buggy catchall version:\n\n  nft_map_catchall_activate():\n    if (!nft_set_elem_active(ext, genmask))\n        continue;   /* skip inactive, process active */\n\nThe consequence is that when a DELSET operation is aborted,\nnft_setelem_data_activate() is never called for the catchall element.\nFor NFT_GOTO verdict elements, this means nft_data_hold() is never\ncalled to restore the chain->use reference count. Each abort cycle\npermanently decrements chain->use. Once chain->use reaches zero,\nDELCHAIN succeeds and frees the chain while catchall verdict elements\nstill reference it, resulting in a use-after-free.\n\nThis is exploitable for local privilege escalation from an unprivileged\nuser via user namespaces + nftables on distributions that enable\nCONFIG_USER_NS and CONFIG_NF_TABLES.\n\nFix by removing the negation so the check matches nft_mapelem_activate():\nskip active elements, process inactive ones.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02348,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1444ff890b4653add12f734ffeffc173d42862dd","https://git.kernel.org/stable/c/42c574c1504aa089a0a142e4c13859327570473d","https://git.kernel.org/stable/c/8b68a45f9722f2babe9e7bad00aa74638addf081","https://git.kernel.org/stable/c/8c760ba4e36c750379d13569f23f5a6e185333f5","https://git.kernel.org/stable/c/b9b6573421de51829f7ec1cce76d85f5f6fbbd7f","https://git.kernel.org/stable/c/f41c5d151078c5348271ffaf8e7410d96f2d82f8"],"published_time":"2026-02-13T14:16:10","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23112","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec\n\nnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU\nlength or offset exceeds sg_cnt and then use bogus sg->length/offset\nvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining\nentries, and sg->length/offset before building the bvec.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00068,"ranking_epss":0.21202,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/043b4307a99f902697349128fde93b2ddde4686c","https://git.kernel.org/stable/c/1385be357e8acd09b36e026567f3a9d5c61139de","https://git.kernel.org/stable/c/19672ae68d52ff75347ebe2420dde1b07adca09f","https://git.kernel.org/stable/c/42afe8ed8ad2de9c19457156244ef3e1eca94b5d","https://git.kernel.org/stable/c/52a0a98549344ca20ad81a4176d68d28e3c05a5c","https://git.kernel.org/stable/c/ab200d71553bdcf4de554a5985b05b2dd606bc57","https://git.kernel.org/stable/c/dca1a6ba0da9f472ef040525fab10fd9956db59f"],"published_time":"2026-02-13T14:16:10","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2319","summary":"Race in DevTools in Google Chrome prior to 145.0.7632.45 allowed a remote attacker who convinced a user to engage in specific UI gestures and install a malicious extension to potentially exploit object corruption via a malicious file. (Chromium security severity: Medium)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00028,"ranking_epss":0.07982,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/40071155"],"published_time":"2026-02-11T19:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2320","summary":"Inappropriate implementation in File input in Google Chrome prior to 145.0.7632.45 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00031,"ranking_epss":0.08826,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/435684924"],"published_time":"2026-02-11T19:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2321","summary":"Use after free in Ozone in Google Chrome prior to 145.0.7632.45 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00128,"ranking_epss":0.32338,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/461877477"],"published_time":"2026-02-11T19:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2322","summary":"Inappropriate implementation in File input in Google Chrome prior to 145.0.7632.45 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00021,"ranking_epss":0.05744,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/470928605"],"published_time":"2026-02-11T19:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2323","summary":"Inappropriate implementation in Downloads in Google Chrome prior to 145.0.7632.45 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.0001,"ranking_epss":0.01041,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/467442136"],"published_time":"2026-02-11T19:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2313","summary":"Use after free in CSS in Google Chrome prior to 145.0.7632.45 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0007,"ranking_epss":0.21679,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/467297219"],"published_time":"2026-02-11T19:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2314","summary":"Heap buffer overflow in Codecs in Google Chrome prior to 145.0.7632.45 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00047,"ranking_epss":0.14757,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/478560268"],"published_time":"2026-02-11T19:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2315","summary":"Inappropriate implementation in WebGPU in Google Chrome prior to 145.0.7632.45 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00032,"ranking_epss":0.09201,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/479242793"],"published_time":"2026-02-11T19:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2316","summary":"Insufficient policy enforcement in Frames in Google Chrome prior to 145.0.7632.45 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00029,"ranking_epss":0.0812,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/422531206"],"published_time":"2026-02-11T19:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2317","summary":"Inappropriate implementation in Animation in Google Chrome prior to 145.0.7632.45 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00018,"ranking_epss":0.04424,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/464173573"],"published_time":"2026-02-11T19:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-2318","summary":"Inappropriate implementation in PictureInPicture in Google Chrome prior to 145.0.7632.45 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00031,"ranking_epss":0.08826,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/363930141"],"published_time":"2026-02-11T19:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-21218","summary":"Improper handling of missing special element in .NET allows an unauthorized attacker to perform spoofing over a network.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00043,"ranking_epss":0.1333,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21218"],"published_time":"2026-02-10T18:16:22","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23102","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: signal: Fix restoration of SVE context\n\nWhen SME is supported, Restoring SVE signal context can go wrong in a\nfew ways, including placing the task into an invalid state where the\nkernel may read from out-of-bounds memory (and may potentially take a\nfatal fault) and/or may kill the task with a SIGKILL.\n\n(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into\n    an invalid state where SVCR.SM is set (and sve_state is non-NULL)\n    but TIF_SME is clear, consequently resuting in out-of-bounds memory\n    reads and/or killing the task with SIGKILL.\n\n    This can only occur in unusual (but legitimate) cases where the SVE\n    signal context has either been modified by userspace or was saved in\n    the context of another task (e.g. as with CRIU), as otherwise the\n    presence of an SVE signal context with SVE_SIG_FLAG_SM implies that\n    TIF_SME is already set.\n\n    While in this state, task_fpsimd_load() will NOT configure SMCR_ELx\n    (leaving some arbitrary value configured in hardware) before\n    restoring SVCR and attempting to restore the streaming mode SVE\n    registers from memory via sve_load_state(). As the value of\n    SMCR_ELx.LEN may be larger than the task's streaming SVE vector\n    length, this may read memory outside of the task's allocated\n    sve_state, reading unrelated data and/or triggering a fault.\n\n    While this can result in secrets being loaded into streaming SVE\n    registers, these values are never exposed. As TIF_SME is clear,\n    fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0\n    accesses to streaming mode SVE registers, so these cannot be\n    accessed directly at EL0. As fpsimd_save_user_state() verifies the\n    live vector length before saving (S)SVE state to memory, no secret\n    values can be saved back to memory (and hence cannot be observed via\n    ptrace, signals, etc).\n\n    When the live vector length doesn't match the expected vector length\n    for the task, fpsimd_save_user_state() will send a fatal SIGKILL\n    signal to the task. Hence the task may be killed after executing\n    userspace for some period of time.\n\n(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the\n    task's SVCR.SM. If SVCR.SM was set prior to restoring the context,\n    then the task will be left in streaming mode unexpectedly, and some\n    register state will be combined inconsistently, though the task will\n    be left in legitimate state from the kernel's PoV.\n\n    This can only occur in unusual (but legitimate) cases where ptrace\n    has been used to set SVCR.SM after entry to the sigreturn syscall,\n    as syscall entry clears SVCR.SM.\n\n    In these cases, the the provided SVE register data will be loaded\n    into the task's sve_state using the non-streaming SVE vector length\n    and the FPSIMD registers will be merged into this using the\n    streaming SVE vector length.\n\nFix (1) by setting TIF_SME when setting SVCR.SM. This also requires\nensuring that the task's sme_state has been allocated, but as this could\ncontain live ZA state, it should not be zeroed. Fix (2) by clearing\nSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.\n\nFor consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME,\nand fp_type earlier, immediately after the allocation of\nsve_state/sme_state, before the restore of the actual register state.\nThis makes it easier to ensure that these are always modified\nconsistently, even if a fault is taken while reading the register data\nfrom the signal context. I do not expect any software to depend on the\nexact state restored when a fault is taken while reading the context.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7b5a52cf252a0d2e89787b645290ad288878f332","https://git.kernel.org/stable/c/9bc3adba8c35119be80ab20217027720446742f2","https://git.kernel.org/stable/c/ce820dd4e6e2d711242dc4331713b9bb4fe06d09","https://git.kernel.org/stable/c/d2907cbe9ea0a54cbe078076f9d089240ee1e2d9"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23103","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: Make the addrs_lock be per port\n\nMake the addrs_lock be per port, not per ipvlan dev.\n\nInitial code seems to be written in the assumption,\nthat any address change must occur under RTNL.\nBut it is not so for the case of IPv6. So\n\n1) Introduce per-port addrs_lock.\n\n2) It was needed to fix places where it was forgotten\nto take lock (ipvlan_open/ipvlan_close)\n\nThis appears to be a very minor problem though.\nSince it's highly unlikely that ipvlan_add_addr() will\nbe called on 2 CPU simultaneously. But nevertheless,\nthis could cause:\n\n1) False-negative of ipvlan_addr_busy(): one interface\niterated through all port->ipvlans + ipvlan->addrs\nunder some ipvlan spinlock, and another added IP\nunder its own lock. Though this is only possible\nfor IPv6, since looks like only ipvlan_addr6_event() can be\ncalled without rtnl_lock.\n\n2) Race since ipvlan_ht_addr_add(port) is called under\ndifferent ipvlan->addrs_lock locks\n\nThis should not affect performance, since add/remove IP\nis a rare situation and spinlock is not taken on fast\npaths.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02542,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/04ba6de6eff61238e5397c14ac26a6578c7735a5","https://git.kernel.org/stable/c/1f300c10d92c547c3a7d978e1212ff52f18256ed","https://git.kernel.org/stable/c/3c149b662cbb202a450e81f938e702ba333864ad","https://git.kernel.org/stable/c/6a81e2db096913d7e43aada1c350c1282e76db39","https://git.kernel.org/stable/c/70feb16e3fbfb10b15de1396557c38e99f1ab8df","https://git.kernel.org/stable/c/88f83e6c9cdb46b8c8ddd0ba01393362963cf589","https://git.kernel.org/stable/c/d3ba32162488283c0a4c5bedd8817aec91748802"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23104","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix devlink reload call trace\n\nCommit 4da71a77fc3b (\"ice: read internal temperature sensor\") introduced\ninternal temperature sensor reading via HWMON. ice_hwmon_init() was added\nto ice_init_feature() and ice_hwmon_exit() was added to ice_remove(). As a\nresult if devlink reload is used to reinit the device and then the driver\nis removed, a call trace can occur.\n\nBUG: unable to handle page fault for address: ffffffffc0fd4b5d\nCall Trace:\n string+0x48/0xe0\n vsnprintf+0x1f9/0x650\n sprintf+0x62/0x80\n name_show+0x1f/0x30\n dev_attr_show+0x19/0x60\n\nThe call trace repeats approximately every 10 minutes when system\nmonitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfs\nattributes that reference freed module memory.\n\nThe sequence is:\n1. Driver load, ice_hwmon_init() gets called from ice_init_feature()\n2. Devlink reload down, flow does not call ice_remove()\n3. Devlink reload up, ice_hwmon_init() gets called from\n   ice_init_feature() resulting in a second instance\n4. Driver unload, ice_hwmon_exit() called from ice_remove() leaving the\n   first hwmon instance orphaned with dangling pointer\n\nFix this by moving ice_hwmon_exit() from ice_remove() to\nice_deinit_features() to ensure proper cleanup symmetry with\nice_hwmon_init().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/87c1dacca197cc64e06fedeb269e3dd6699bae60","https://git.kernel.org/stable/c/8ac7dd0f813fb65ff2fd9543900c3009f8e84110","https://git.kernel.org/stable/c/d3f867e7a04678640ebcbfb81893c59f4af48586"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23105","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag\n\nThis is more of a preventive patch to make the code more consistent and\nto prevent possible exploits that employ child qlen manipulations on qfq.\nuse cl_is_active instead of relying on the child qdisc's qlen to determine\nclass activation.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03364,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/77f1afd0bb4d5da95236f6114e6d0dfcde187ff6","https://git.kernel.org/stable/c/93b8635974fb050c43d07e35e5edfe6e685ca28a","https://git.kernel.org/stable/c/abd9fc26ea577561a5ef6241a1b058755ffdad0c","https://git.kernel.org/stable/c/b8c24cf5268fb3bfb8d16324c3dbb985f698c835","https://git.kernel.org/stable/c/d837fbee92453fbb829f950c8e7cf76207d73f33","https://git.kernel.org/stable/c/f27047abf7cac1b6f90c3ad60de21ef9f717c26d","https://git.kernel.org/stable/c/fac2c67bb2bb732eae4283e45fc338af7e08c254"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23106","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntimekeeping: Adjust the leap state for the correct auxiliary timekeeper\n\nWhen __do_ajdtimex() was introduced to handle adjtimex for any\ntimekeeper, this reference to tk_core was not updated. When called on an\nauxiliary timekeeper, the core timekeeper would be updated incorrectly.\n\nThis gets caught by the lock debugging diagnostics because the\ntimekeepers sequence lock gets written to without holding its\nassociated spinlock:\n\nWARNING: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125\naux_clock_adj (kernel/time/timekeeping.c:2979)\n__do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)\n\nUpdate the correct auxiliary timekeeper.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/8f7c9dbeaa0be5810e44d323735967d3dba9239d","https://git.kernel.org/stable/c/e806f7dde8ba28bc72a7a0898589cac79f6362ac"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23107","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: signal: Allocate SSVE storage when restoring ZA\n\nThe code to restore a ZA context doesn't attempt to allocate the task's\nsve_state before setting TIF_SME. Consequently, restoring a ZA context\ncan place a task into an invalid state where TIF_SME is set but the\ntask's sve_state is NULL.\n\nIn legitimate but uncommon cases where the ZA signal context was NOT\ncreated by the kernel in the context of the same task (e.g. if the task\nis saved/restored with something like CRIU), we have no guarantee that\nsve_state had been allocated previously. In these cases, userspace can\nenter streaming mode without trapping while sve_state is NULL, causing a\nlater NULL pointer dereference when the kernel attempts to store the\nregister state:\n\n| # ./sigreturn-za\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n| Mem abort info:\n|   ESR = 0x0000000096000046\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x06: level 2 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000\n|   CM = 0, WnR = 1, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00\n| [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000\n| Internal error: Oops: 0000000096000046 [#1]  SMP\n| Modules linked in:\n| CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n| pc : sve_save_state+0x4/0xf0\n| lr : fpsimd_save_user_state+0xb0/0x1c0\n| sp : ffff80008070bcc0\n| x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658\n| x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000\n| x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40\n| x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000\n| x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c\n| x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020\n| x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0\n| x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48\n| x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000\n| x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440\n| Call trace:\n|  sve_save_state+0x4/0xf0 (P)\n|  fpsimd_thread_switch+0x48/0x198\n|  __switch_to+0x20/0x1c0\n|  __schedule+0x36c/0xce0\n|  schedule+0x34/0x11c\n|  exit_to_user_mode_loop+0x124/0x188\n|  el0_interrupt+0xc8/0xd8\n|  __el0_irq_handler_common+0x18/0x24\n|  el0t_64_irq_handler+0x10/0x1c\n|  el0t_64_irq+0x198/0x19c\n| Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)\n| ---[ end trace 0000000000000000 ]---\n\nFix this by having restore_za_context() ensure that the task's sve_state\nis allocated, matching what we do when taking an SME trap. Any live\nSVE/SSVE state (which is restored earlier from a separate signal\ncontext) must be preserved, and hence this is not zeroed.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0af233d66eff90fb8f3e0fc09f2316bba0b72bb9","https://git.kernel.org/stable/c/19b2c3f3ca1b4b6dccd2a42aca2692d8c79c4214","https://git.kernel.org/stable/c/70f7f54566afc23f2c71bf1411af81f5d8009e0f","https://git.kernel.org/stable/c/c5a5b150992ebab779c1ce54f54676786e47e94c","https://git.kernel.org/stable/c/ea8ccfddbce0bee6310da4f3fc560ad520f5e6b4"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23108","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncan: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak\n\nFix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb:\ngs_usb_receive_bulk_callback(): fix URB memory leak\").\n\nIn usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are\nallocated, added to the priv->rx_submitted anchor and submitted. In the\ncomplete callback usb_8dev_read_bulk_callback(), the URBs are processed and\nresubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by\ncalling usb_kill_anchored_urbs(&priv->rx_submitted).\n\nHowever, this does not take into account that the USB framework unanchors\nthe URB before the complete function is called. This means that once an\nin-URB has been completed, it is no longer anchored and is ultimately not\nreleased in usb_kill_anchored_urbs().\n\nFix the memory leak by anchoring the URB in the\nusb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/07e9373739c6388af9d99797cdb2e79dbbcbe92b","https://git.kernel.org/stable/c/59ff56992bba28051ad67cd8cc7b0edfe7280796","https://git.kernel.org/stable/c/60719661b4cbd7ffbed1a0e0fa3bbc82d8bd2be9","https://git.kernel.org/stable/c/ea4a98e924164586066b39f29bfcc7cc9da108cd","https://git.kernel.org/stable/c/ef6e608e5ee71eca0cd3475c737e684cef24f240","https://git.kernel.org/stable/c/f7a980b3b8f80fe367f679da376cf76e800f9480","https://git.kernel.org/stable/c/feb8243eaea7efd5279b19667d7189fd8654c87a"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23109","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()\n\nAbove the while() loop in wait_sb_inodes(), we document that we must wait\nfor all pages under writeback for data integrity.  Consequently, if a\nmapping, like fuse, traditionally does not have data integrity semantics,\nthere is no need to wait at all; we can simply skip these inodes.\n\nThis restores fuse back to prior behavior where syncs are no-ops.  This\nfixes a user regression where if a system is running a faulty fuse server\nthat does not reply to issued write requests, this causes wait_sb_inodes()\nto wait forever.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3f4ed5e2b8f111553562507ad6202432c7c57731","https://git.kernel.org/stable/c/f9a49aa302a05e91ca01f69031cb79a0ea33031f"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23110","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Wake up the error handler when final completions race against each other\n\nThe fragile ordering between marking commands completed or failed so\nthat the error handler only wakes when the last running command\ncompletes or times out has race conditions. These race conditions can\ncause the SCSI layer to fail to wake the error handler, leaving I/O\nthrough the SCSI host stuck as the error state cannot advance.\n\nFirst, there is an memory ordering issue within scsi_dec_host_busy().\nThe write which clears SCMD_STATE_INFLIGHT may be reordered with reads\ncounting in scsi_host_busy(). While the local CPU will see its own\nwrite, reordering can allow other CPUs in scsi_dec_host_busy() or\nscsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to\nsee a host busy equal to the host_failed count.\n\nThis race condition can be prevented with a memory barrier on the error\npath to force the write to be visible before counting host busy\ncommands.\n\nSecond, there is a general ordering issue with scsi_eh_inc_host_failed(). By\ncounting busy commands before incrementing host_failed, it can race with a\nfinal command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does\nnot see host_failed incremented but scsi_eh_inc_host_failed() counts busy\ncommands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),\nresulting in neither waking the error handler task.\n\nThis needs the call to scsi_host_busy() to be moved after host_failed is\nincremented to close the race condition.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00014,"ranking_epss":0.02455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/219f009ebfd1ef3970888ee9eef4c8a06357f862","https://git.kernel.org/stable/c/64ae21b9c4f0c7e60cf47a53fa7ab68852079ef0","https://git.kernel.org/stable/c/6d9a367be356101963c249ebf10ea10b32886607","https://git.kernel.org/stable/c/9fdc6f28d5e81350ab1d2cac8389062bd09e61e1","https://git.kernel.org/stable/c/cc872e35c0df80062abc71268d690a2f749e542e","https://git.kernel.org/stable/c/fe2f8ad6f0999db3b318359a01ee0108c703a8c3"],"published_time":"2026-02-04T17:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23092","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_source\n\nWhen simple_write_to_buffer() succeeds, it returns the number of bytes\nactually copied to the buffer. The code incorrectly uses 'count'\nas the index for null termination instead of the actual bytes copied.\nIf count exceeds the buffer size, this leads to out-of-bounds write.\nAdd a check for the count and use the return value as the index.\n\nThe bug was validated using a demo module that mirrors the original\ncode and was tested under QEMU.\n\nPattern of the bug:\n- A fixed 64-byte stack buffer is filled using count.\n- If count > 64, the code still does buf[count] = '\\0', causing an\n- out-of-bounds write on the stack.\n\nSteps for reproduce:\n- Opens the device node.\n- Writes 128 bytes of A to it.\n- This overflows the 64-byte stack buffer and KASAN reports the OOB.\n\nFound via static analysis. This is similar to the\ncommit da9374819eb3 (\"iio: backend: fix out-of-bound write\")","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/978d28136c53df38f8f0b747191930e2f95e9084","https://git.kernel.org/stable/c/db16e7c52032c79156930a337ee17232931794ba"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23093","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbd: fix dma_unmap_sg() nents\n\nThe dma_unmap_sg() functions should be called with the same nents as the\ndma_map_sg(), not the value the map function returned.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00022,"ranking_epss":0.05879,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4d1e9a4a450aae47277763562122cc80ed703ab2","https://git.kernel.org/stable/c/6ececffd3e9fe93a87738625dc0671165d27bf96","https://git.kernel.org/stable/c/70ba85e439221a5d6dda34a3004db6640f0525e6","https://git.kernel.org/stable/c/98e3e2b561bc88f4dd218d1c05890672874692f6","https://git.kernel.org/stable/c/d1943bc9dc9508f5933788a76f8a35d10e43a646","https://git.kernel.org/stable/c/f569f5b8bfd5133defdf9c7f8a72c63aa11f54ec"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23094","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nuacce: fix isolate sysfs check condition\n\nuacce supports the device isolation feature. If the driver\nimplements the isolate_err_threshold_read and\nisolate_err_threshold_write callback functions, uacce will create\nsysfs files now. Users can read and configure the isolation policy\nthrough sysfs. Currently, sysfs files are created as long as either\nisolate_err_threshold_read or isolate_err_threshold_write callback\nfunctions are present.\n\nHowever, accessing a non-existent callback function may cause the\nsystem to crash. Therefore, intercept the creation of sysfs if\nneither read nor write exists; create sysfs if either is supported,\nbut intercept unsupported operations at the call site.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/82821a681d5dcce31475a65190fc39ea8f372cc0","https://git.kernel.org/stable/c/98eec349259b1fd876f350b1c600403bcef8f85d","https://git.kernel.org/stable/c/9ab05cdcac354b1b1139918f49c6418b9005d042","https://git.kernel.org/stable/c/fdbbb47d15ae17bf39fafec7e2028c1f8efba15e"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23095","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngue: Fix skb memleak with inner IP protocol 0.\n\nsyzbot reported skb memleak below. [0]\n\nThe repro generated a GUE packet with its inner protocol 0.\n\ngue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\"\nin ip_protocol_deliver_rcu(), but this only works with\nnon-zero protocol number.\n\nLet's drop such packets.\n\nNote that 0 is a valid number (IPv6 Hop-by-Hop Option).\n\nI think it is not practical to encap HOPOPT in GUE, so once\nsomeone starts to complain, we could pass down a resubmit\nflag pointer to distinguish two zeros from the upper layer:\n\n  * no error\n  * resubmit HOPOPT\n\n[0]\nBUG: memory leak\nunreferenced object 0xffff888109695a00 (size 240):\n  comm \"syz.0.17\", pid 6088, jiffies 4294943096\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00  .@..............\n  backtrace (crc a84b336f):\n    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]\n    slab_post_alloc_hook mm/slub.c:4958 [inline]\n    slab_alloc_node mm/slub.c:5263 [inline]\n    kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270\n    __build_skb+0x23/0x60 net/core/skbuff.c:474\n    build_skb+0x20/0x190 net/core/skbuff.c:490\n    __tun_build_skb drivers/net/tun.c:1541 [inline]\n    tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636\n    tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770\n    tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999\n    new_sync_write fs/read_write.c:593 [inline]\n    vfs_write+0x45d/0x710 fs/read_write.c:686\n    ksys_write+0xa7/0x170 fs/read_write.c:738\n    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94\n    entry_SYSCALL_64_after_hwframe+0x77/0x7f","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00031,"ranking_epss":0.08966,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/380a82d36e37db49fd41ecc378c22fd29392e96a","https://git.kernel.org/stable/c/536f5bbc322eb1e175bdd1ced22b236a951c4d8f","https://git.kernel.org/stable/c/5437a279804ced8088cabb945dba88a26d828f8c","https://git.kernel.org/stable/c/886f186328b718400dbf79e1bc8cbcbd710ab766","https://git.kernel.org/stable/c/9a56796ad258786d3624eef5aefba394fc9bdded","https://git.kernel.org/stable/c/ce569b389a5c78d64788a5ea94560e17fa574b35","https://git.kernel.org/stable/c/f87b9b7a618c82e7465e872eb10e14c803871892"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23096","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nuacce: fix cdev handling in the cleanup path\n\nWhen cdev_device_add fails, it internally releases the cdev memory,\nand if cdev_device_del is then executed, it will cause a hang error.\nTo fix it, we check the return value of cdev_device_add() and clear\nuacce->cdev to avoid calling cdev_device_del in the uacce_remove.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1bc3e51367c420e6db31f41efa874c7a8e12194a","https://git.kernel.org/stable/c/819d647406200d0e83e56fd2df8f451b11290559","https://git.kernel.org/stable/c/98d67a1bd6caddd0a8b8c82a0b925742cf500936","https://git.kernel.org/stable/c/a3bece3678f6c88db1f44c602b2a63e84b4040ac","https://git.kernel.org/stable/c/bd2393ed7712513e7e2dbcb6e21464a67ff9e702","https://git.kernel.org/stable/c/c94c7188d325bc5137d447d67a2f18f7d4f2f4a3","https://git.kernel.org/stable/c/d9031575a2f8aabc53af3025dd79af313a2e046b"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23097","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmigrate: correct lock ordering for hugetlb file folios\n\nSyzbot has found a deadlock (analyzed by Lance Yang):\n\n1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).\n2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire\nfolio_lock.\n\nmigrate_pages()\n  -> migrate_hugetlbs()\n    -> unmap_and_move_huge_page()     <- Takes folio_lock!\n      -> remove_migration_ptes()\n        -> __rmap_walk_file()\n          -> i_mmap_lock_read()       <- Waits for i_mmap_rwsem(read lock)!\n\nhugetlbfs_fallocate()\n  -> hugetlbfs_punch_hole()           <- Takes i_mmap_rwsem(write lock)!\n    -> hugetlbfs_zero_partial_page()\n     -> filemap_lock_hugetlb_folio()\n      -> filemap_lock_folio()\n        -> __filemap_get_folio        <- Waits for folio_lock!\n\nThe migration path is the one taking locks in the wrong order according to\nthe documentation at the top of mm/rmap.c.  So expand the scope of the\nexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.\n\nThis is (mostly) how it used to be after commit c0d0381ade79.  That was\nremoved by 336bf30eb765 for both file & anon hugetlb pages when it should\nonly have been removed for anon hugetlb pages.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1b68efce6dd483d22f50d0d3800c4cfda14b1305","https://git.kernel.org/stable/c/526394af4e8ade89cacd1a9ce2b97712712fcc34","https://git.kernel.org/stable/c/5edb9854f8df5428b40990a1c7d60507da5bd330","https://git.kernel.org/stable/c/ad97b9a55246eb940a26ac977f80892a395cabf9","https://git.kernel.org/stable/c/b75070823b89009f5123fd0e05a8e0c3d39937c1","https://git.kernel.org/stable/c/b7880cb166ab62c2409046b2347261abf701530e","https://git.kernel.org/stable/c/e7396d23f9d5739f56cf9ab430c3a169f5508394"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23098","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: fix double-free in nr_route_frame()\n\nIn nr_route_frame(), old_skb is immediately freed without checking if\nnr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL,\nthe caller function will free old_skb again, causing a double-free bug.\n\nTherefore, to prevent this, we need to modify it to check whether\nnr_neigh->ax25 is NULL before freeing old_skb.","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00021,"ranking_epss":0.05544,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/25aab6bfc31017a7e52035b99aef5c2b6bde8ffb","https://git.kernel.org/stable/c/6e0110ea90313b7c0558a0b77038274a6821caf8","https://git.kernel.org/stable/c/7c48fdf2d1349bb54815b56fb012b9d577707708","https://git.kernel.org/stable/c/94d1a8bd08af1f4cc345c5c29f5db1ea72b8bb8c","https://git.kernel.org/stable/c/9f5fa78d9980fe75a69835521627ab7943cb3d67","https://git.kernel.org/stable/c/ba1096c315283ee3292765f6aea4cca15816c4f7","https://git.kernel.org/stable/c/bd8955337e3764f912f49b360e176d8aaecf7016"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23099","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: limit BOND_MODE_8023AD to Ethernet devices\n\nBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.\n\nsyzbot reported:\n\n BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\nRead of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497\n\nCPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G             L      syzkaller #0 PREEMPT(full)\nTainted: [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nCall Trace:\n <TASK>\n  dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n  print_address_description mm/kasan/report.c:378 [inline]\n  print_report+0xca/0x240 mm/kasan/report.c:482\n  kasan_report+0x118/0x150 mm/kasan/report.c:595\n check_region_inline mm/kasan/generic.c:-1 [inline]\n  kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200\n  __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n  __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n  __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\n  __dev_mc_add net/core/dev_addr_lists.c:868 [inline]\n  dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886\n  bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180\n  do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963\n  do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165\n  rtnl_changelink net/core/rtnetlink.c:3776 [inline]\n  __rtnl_newlink net/core/rtnetlink.c:3935 [inline]\n  rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072\n  rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958\n  netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550\n  netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]\n  netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344\n  netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894\n  sock_sendmsg_nosec net/socket.c:727 [inline]\n  __sock_sendmsg+0x21c/0x270 net/socket.c:742\n  ____sys_sendmsg+0x505/0x820 net/socket.c:2592\n  ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646\n  __sys_sendmsg+0x164/0x220 net/socket.c:2678\n  do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n  __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307\n  do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n </TASK>\n\nThe buggy address belongs to the variable:\n lacpdu_mcast_addr+0x0/0x40","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.03364,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/43dee6f7ef1d228821de1b61c292af3744c8d7da","https://git.kernel.org/stable/c/5063b2cd9b27d35ab788d707d7858ded0acc8f1d","https://git.kernel.org/stable/c/72925dbb0c8c7b16bf922e93c6cc03cbd8c955c4","https://git.kernel.org/stable/c/80c881e53a4fa0a80fa4bef7bc0ead0e8e88940d","https://git.kernel.org/stable/c/c84fcb79e5dbde0b8d5aeeaf04282d2149aebcf6","https://git.kernel.org/stable/c/ef68afb1bee8d35a18896c27d7358079353d8d8a"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23100","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix hugetlb_pmd_shared()\n\nPatch series \"mm/hugetlb: fixes for PMD table sharing (incl.  using\nmmu_gather)\", v3.\n\nOne functional fix, one performance regression fix, and two related\ncomment fixes.\n\nI cleaned up my prototype I recently shared [1] for the performance fix,\ndeferring most of the cleanups I had in the prototype to a later point. \nWhile doing that I identified the other things.\n\nThe goal of this patch set is to be backported to stable trees \"fairly\"\neasily. At least patch #1 and #4.\n\nPatch #1 fixes hugetlb_pmd_shared() not detecting any sharing\nPatch #2 + #3 are simple comment fixes that patch #4 interacts with.\nPatch #4 is a fix for the reported performance regression due to excessive\nIPI broadcasts during fork()+exit().\n\nThe last patch is all about TLB flushes, IPIs and mmu_gather.\nRead: complicated\n\nThere are plenty of cleanups in the future to be had + one reasonable\noptimization on x86. But that's all out of scope for this series.\n\nRuntime tested, with a focus on fixing the performance regression using\nthe original reproducer [2] on x86.\n\n\nThis patch (of 4):\n\nWe switched from (wrongly) using the page count to an independent shared\ncount.  Now, shared page tables have a refcount of 1 (excluding\nspeculative references) and instead use ptdesc->pt_share_count to identify\nsharing.\n\nWe didn't convert hugetlb_pmd_shared(), so right now, we would never\ndetect a shared PMD table as such, because sharing/unsharing no longer\ntouches the refcount of a PMD table.\n\nPage migration, like mbind() or migrate_pages() would allow for migrating\nfolios mapped into such shared PMD tables, even though the folios are not\nexclusive.  In smaps we would account them as \"private\" although they are\n\"shared\", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the\npagemap interface.\n\nFix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00022,"ranking_epss":0.05849,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3a18b452dd5f7f1652c2e92f8ae769aa17a66c9e","https://git.kernel.org/stable/c/51dcf459845fd28f5a0d83d408a379b274ec5cc5","https://git.kernel.org/stable/c/5b2aec77f92265a9028c5f632bdd9af5b57ec3a3","https://git.kernel.org/stable/c/69c4e241ff13545d410a8b2a688c932182a858bf","https://git.kernel.org/stable/c/ca1a47cd3f5f4c46ca188b1c9a27af87d1ab2216"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23101","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nleds: led-class: Only Add LED to leds_list when it is fully ready\n\nBefore this change the LED was added to leds_list before led_init_core()\ngets called adding it the list before led_classdev.set_brightness_work gets\ninitialized.\n\nThis leaves a window where led_trigger_register() of a LED's default\ntrigger will call led_trigger_set() which calls led_set_brightness()\nwhich in turn will end up queueing the *uninitialized*\nled_classdev.set_brightness_work.\n\nThis race gets hit by the lenovo-thinkpad-t14s EC driver which registers\n2 LEDs with a default trigger provided by snd_ctl_led.ko in quick\nsuccession. The first led_classdev_register() causes an async modprobe of\nsnd_ctl_led to run and that async modprobe manages to exactly hit\nthe window where the second LED is on the leds_list without led_init_core()\nbeing called for it, resulting in:\n\n ------------[ cut here ]------------\n WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390\n Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025\n ...\n Call trace:\n  __flush_work+0x344/0x390 (P)\n  flush_work+0x2c/0x50\n  led_trigger_set+0x1c8/0x340\n  led_trigger_register+0x17c/0x1c0\n  led_trigger_register_simple+0x84/0xe8\n  snd_ctl_led_init+0x40/0xf88 [snd_ctl_led]\n  do_one_initcall+0x5c/0x318\n  do_init_module+0x9c/0x2b8\n  load_module+0x7e0/0x998\n\nClose the race window by moving the adding of the LED to leds_list to\nafter the led_init_core() call.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2757f7748ce2d0fa44112024907bafb37e104d6e","https://git.kernel.org/stable/c/78822628165f3d817382f67f91129161159ca234","https://git.kernel.org/stable/c/d117fdcb21b05c0e0460261d017b92303cd9ba77","https://git.kernel.org/stable/c/d1883cefd31752f0504b94c3bcfa1f6d511d6e87","https://git.kernel.org/stable/c/da565bf98c9ad0eabcb09fc97859e0b52f98b7c3","https://git.kernel.org/stable/c/e90c861411fc84629a240384b0a72830539d3386","https://git.kernel.org/stable/c/f7a6df659af777058833802c29b3b7974db5e78a"],"published_time":"2026-02-04T17:16:20","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23082","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncan: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error\n\nIn commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix\nURB memory leak\"), the URB was re-anchored before usb_submit_urb() in\ngs_usb_receive_bulk_callback() to prevent a leak of this URB during\ncleanup.\n\nHowever, this patch did not take into account that usb_submit_urb() could\nfail. The URB remains anchored and\nusb_kill_anchored_urbs(&parent->rx_submitted) in gs_can_close() loops\ninfinitely since the anchor list never becomes empty.\n\nTo fix the bug, unanchor the URB when an usb_submit_urb() error occurs,\nalso print an info message.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/79a6d1bfe1148bc921b8d7f3371a7fbce44e30f7","https://git.kernel.org/stable/c/aa8a8866c533a150be4763bcb27993603bd5426c","https://git.kernel.org/stable/c/c3edc14da81a8d8398682f6e4ab819f09f37c0b7","https://git.kernel.org/stable/c/c610b550ccc0438d456dfe1df9f4f36254ccaae3","https://git.kernel.org/stable/c/ce4352057fc5a986c76ece90801b9755e7c6e56c"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23083","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfou: Don't allow 0 for FOU_ATTR_IPPROTO.\n\nfou_udp_recv() has the same problem mentioned in the previous\npatch.\n\nIf FOU_ATTR_IPPROTO is set to 0, skb is not freed by\nfou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu().\n\nLet's forbid 0 for FOU_ATTR_IPPROTO.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03364,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1cc98b8887cabb1808d2f4a37cd10a7be7574771","https://git.kernel.org/stable/c/611ef4bd9c73d9e6d87bed57a635ff1fdd8c91ea","https://git.kernel.org/stable/c/6e983789b7588ee59cbf303583546c043bad8e19","https://git.kernel.org/stable/c/7a9bc9e3f42391e4c187e099263cf7a1c4b69ff5","https://git.kernel.org/stable/c/9b75dff8446ec871030d8daf5a69e74f5fe8b956","https://git.kernel.org/stable/c/b7db31a52c3862a1a32202a273a4c32e7f5f4823","https://git.kernel.org/stable/c/c7498f9bc390479ccfad7c7f2332237ff4945b03"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23084","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list\n\nWhen the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is\nset to false, the driver may request the PMAC_ID from the firmware of the\nnetwork card, and this function will store that PMAC_ID at the provided\naddress pmac_id. This is the contract of this function.\n\nHowever, there is a location within the driver where both\npmac_id_valid == false and pmac_id == NULL are being passed. This could\nresult in dereferencing a NULL pointer.\n\nTo resolve this issue, it is necessary to pass the address of a stub\nvariable to the function.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/31410a01a86bcb98c798d01061abf1f789c4f75a","https://git.kernel.org/stable/c/47ffb4dcffe336f4a7bd0f3284be7aadc6484698","https://git.kernel.org/stable/c/4cba480c9b9a3861a515262225cb53a1f5978344","https://git.kernel.org/stable/c/6c3e00888dbec887125a08b51a705b9b163fcdd1","https://git.kernel.org/stable/c/8215794403d264739cc676668087512950b2ff31","https://git.kernel.org/stable/c/92c6dc181a18e6e0ddb872ed35cb48a9274829e4","https://git.kernel.org/stable/c/e206fb415db36bad52bb90c08d46ce71ffbe8a80"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23085","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gic-v3-its: Avoid truncating memory addresses\n\nOn 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem\nallocations to be backed by addresses physical memory above the 32-bit\naddress limit, as found while experimenting with larger VMSPLIT\nconfigurations.\n\nThis caused the qemu virt model to crash in the GICv3 driver, which\nallocates the 'itt' object using GFP_KERNEL. Since all memory below\nthe 4GB physical address limit is in ZONE_DMA in this configuration,\nkmalloc() defaults to higher addresses for ZONE_NORMAL, and the\nITS driver stores the physical address in a 32-bit 'unsigned long'\nvariable.\n\nChange the itt_addr variable to the correct phys_addr_t type instead,\nalong with all other variables in this driver that hold a physical\naddress.\n\nThe gicv5 driver correctly uses u64 variables, while all other irqchip\ndrivers don't call virt_to_phys or similar interfaces. It's expected that\nother device drivers have similar issues, but fixing this one is\nsufficient for booting a virtio based guest.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03faa61eb4b9ca9aa09bd91d4c3773d8e7b1ac98","https://git.kernel.org/stable/c/084ba3b99f2dfd991ce7e84fb17117319ec3cd9f","https://git.kernel.org/stable/c/1b323391560354d8c515de8658b057a1daa82adb","https://git.kernel.org/stable/c/85215d633983233809f7d4dad163b953331b8238","https://git.kernel.org/stable/c/8d76a7d89c12d08382b66e2f21f20d0627d14859","https://git.kernel.org/stable/c/e2f9c751f73a2d5bb62d94ab030aec118a811f27","https://git.kernel.org/stable/c/e332b3b69e5b3acf07204a4b185071bab15c2b88"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23086","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: cap TX credit to local buffer size\n\nThe virtio transports derives its TX credit directly from peer_buf_alloc,\nwhich is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.\n\nOn the host side this means that the amount of data we are willing to\nqueue for a connection is scaled by a guest-chosen buffer size, rather\nthan the host's own vsock configuration. A malicious guest can advertise\na large buffer and read slowly, causing the host to allocate a\ncorrespondingly large amount of sk_buff memory.\nThe same thing would happen in the guest with a malicious host, since\nvirtio transports share the same code base.\n\nIntroduce a small helper, virtio_transport_tx_buf_size(), that\nreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consume\npeer_buf_alloc.\n\nThis ensures the effective TX window is bounded by both the peer's\nadvertised buffer and our own buf_alloc (already clamped to\nbuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer\ncannot force the other to queue more data than allowed by its own\nvsock settings.\n\nOn an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with\n32 guest vsock connections advertising 2 GiB each and reading slowly\ndrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only\nrecovered after killing the QEMU process. That said, if QEMU memory is\nlimited with cgroups, the maximum memory used will be limited.\n\nWith this patch applied:\n\n  Before:\n    MemFree:        ~61.6 GiB\n    Slab:           ~142 MiB\n    SUnreclaim:     ~117 MiB\n\n  After 32 high-credit connections:\n    MemFree:        ~61.5 GiB\n    Slab:           ~178 MiB\n    SUnreclaim:     ~152 MiB\n\nOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest\nremains responsive.\n\nCompatibility with non-virtio transports:\n\n  - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per\n    socket based on the local vsk->buffer_* values; the remote side\n    cannot enlarge those queues beyond what the local endpoint\n    configured.\n\n  - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and\n    an MTU bound; there is no peer-controlled credit field comparable\n    to peer_buf_alloc, and the remote endpoint cannot drive in-flight\n    kernel memory above those ring sizes.\n\n  - The loopback path reuses virtio_transport_common.c, so it\n    naturally follows the same semantics as the virtio transport.\n\nThis change is limited to virtio_transport_common.c and thus affects\nvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the\n\"remote window intersected with local policy\" behaviour that VMCI and\nHyper-V already effectively have.\n\n[Stefano: small adjustments after changing the previous patch]\n[Stefano: tweak the commit message]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/84ef86aa7120449828d1e0ce438c499014839711","https://git.kernel.org/stable/c/8ee784fdf006cbe8739cfa093f54d326cbf54037","https://git.kernel.org/stable/c/c0e42fb0e054c2b2ec4ee80f48ccd256ae0227ce","https://git.kernel.org/stable/c/d9d5f222558b42f6277eafaaa6080966faf37676","https://git.kernel.org/stable/c/fef7110ae5617555c792a2bb4d27878d84583adf"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23087","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: xen: scsiback: Fix potential memory leak in scsiback_remove()\n\nMemory allocated for struct vscsiblk_info in scsiback_probe() is not\nfreed in scsiback_remove() leading to potential memory leaks on remove,\nas well as in the scsiback_probe() error paths. Fix that by freeing it\nin scsiback_remove().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/24c441f0e24da175d7912095663f526ac480dc4f","https://git.kernel.org/stable/c/32e52b56056daf0f0881fd9254706acf25b4be97","https://git.kernel.org/stable/c/427b0fb30ddec3bad05dcd73b00718f98c7026d2","https://git.kernel.org/stable/c/4a975c72429b050c234405668b742cdecc11548e","https://git.kernel.org/stable/c/901a5f309daba412e2a30364d7ec1492fa11c32c","https://git.kernel.org/stable/c/a8bb3ec8d85951a56af0a72d93ccbc2aee42eef9","https://git.kernel.org/stable/c/f86264ec0e2b102fcd49bf3e4f32fee669d482fc"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23088","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix crash on synthetic stacktrace field usage\n\nWhen creating a synthetic event based on an existing synthetic event that\nhad a stacktrace field and the new synthetic event used that field a\nkernel crash occurred:\n\n ~# cd /sys/kernel/tracing\n ~# echo 's:stack unsigned long stack[];' > dynamic_events\n ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger\n ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/trigger\n\nThe above creates a synthetic event that takes a stacktrace when a task\nschedules out in a non-running state and passes that stacktrace to the\nsched_switch event when that task schedules back in. It triggers the\n\"stack\" synthetic event that has a stacktrace as its field (called \"stack\").\n\n ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events\n ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger\n ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/trigger\n\nThe above makes another synthetic event called \"syscall_stack\" that\nattaches the first synthetic event (stack) to the sys_exit trace event and\nrecords the stacktrace from the stack event with the id of the system call\nthat is exiting.\n\nWhen enabling this event (or using it in a historgram):\n\n ~# echo 1 > events/synthetic/syscall_stack/enable\n\nProduces a kernel crash!\n\n BUG: unable to handle page fault for address: 0000000000400010\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP PTI\n CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy)  Debian 6.16.3-1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:trace_event_raw_event_synth+0x90/0x380\n Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f\n RSP: 0018:ffffd2670388f958 EFLAGS: 00010202\n RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0\n RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50\n R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010\n R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90\n FS:  00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0\n Call Trace:\n  <TASK>\n  ? __tracing_map_insert+0x208/0x3a0\n  action_trace+0x67/0x70\n  event_hist_trigger+0x633/0x6d0\n  event_triggers_call+0x82/0x130\n  trace_event_buffer_commit+0x19d/0x250\n  trace_event_raw_event_sys_exit+0x62/0xb0\n  syscall_exit_work+0x9d/0x140\n  do_syscall_64+0x20a/0x2f0\n  ? trace_event_raw_event_sched_switch+0x12b/0x170\n  ? save_fpregs_to_fpstate+0x3e/0x90\n  ? _raw_spin_unlock+0xe/0x30\n  ? finish_task_switch.isra.0+0x97/0x2c0\n  ? __rseq_handle_notify_resume+0xad/0x4c0\n  ? __schedule+0x4b8/0xd00\n  ? restore_fpregs_from_fpstate+0x3c/0x90\n  ? switch_fpu_return+0x5b/0xe0\n  ? do_syscall_64+0x1ef/0x2f0\n  ? do_fault+0x2e9/0x540\n  ? __handle_mm_fault+0x7d1/0xf70\n  ? count_memcg_events+0x167/0x1d0\n  ? handle_mm_fault+0x1d7/0x2e0\n  ? do_user_addr_fault+0x2c3/0x7f0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reason is that the stacktrace field is not labeled as such, and is\ntreated as a normal field and not as a dynamic event that it is.\n\nIn trace_event_raw_event_synth() the event is field is still treated as a\ndynamic array, but the retrieval of the data is considered a normal field,\nand the reference is just the meta data:\n\n// Meta data is retrieved instead of a dynamic array\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/327af07dff6ab5650b21491eb4f69694999ff3d1","https://git.kernel.org/stable/c/3b90d099efa2b67239bd3b3dc3521ec584261748","https://git.kernel.org/stable/c/90f9f5d64cae4e72defd96a2a22760173cb3c9ec","https://git.kernel.org/stable/c/98ecbfb2598c9c7ca755a29f402da9d36c057077"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23089","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()\n\nWhen snd_usb_create_mixer() fails, snd_usb_mixer_free() frees\nmixer->id_elems but the controls already added to the card still\nreference the freed memory. Later when snd_card_register() runs,\nthe OSS mixer layer calls their callbacks and hits a use-after-free read.\n\nCall trace:\n  get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411\n  get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241\n  mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381\n  snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887\n  ...\n  snd_card_register+0x4ed/0x6d0 sound/core/init.c:923\n  usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025\n\nFix by calling snd_ctl_remove() for all mixer controls before freeing\nid_elems. We save the next pointer first because snd_ctl_remove()\nfrees the current element.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03364,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/51b1aa6fe7dc87356ba58df06afb9677c9b841ea","https://git.kernel.org/stable/c/56fb6efd5d04caf6f14994d51ec85393b9a896c6","https://git.kernel.org/stable/c/7009daeefa945973a530b2f605fe445fc03747af","https://git.kernel.org/stable/c/7bff0156d13f0ad9436e5178b979b063d59f572a","https://git.kernel.org/stable/c/930e69757b74c3ae083b0c3c7419bfe7f0edc7b2","https://git.kernel.org/stable/c/dc1a5dd80af1ee1f29d8375b12dd7625f6294dad","https://git.kernel.org/stable/c/e6f103a22b08daf5df2f4aa158081840e5910963"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23090","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nslimbus: core: fix device reference leak on report present\n\nSlimbus devices can be allocated dynamically upon reception of\nreport-present messages.\n\nMake sure to drop the reference taken when looking up already registered\ndevices.\n\nNote that this requires taking an extra reference in case the device has\nnot yet been registered and has to be allocated.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/02b78bbfbafe49832e508079148cb87cdfa55825","https://git.kernel.org/stable/c/2ddc09f6a0a221b1d91a7cbc8cc2cefdbd334fe6","https://git.kernel.org/stable/c/54de72a7aabc0749938d7a2833a0c1a5d3ed7ac9","https://git.kernel.org/stable/c/6602bb4d1338e92b5838e50322b87697bdbd2ee0","https://git.kernel.org/stable/c/9391380eb91ea5ac792aae9273535c8da5b9aa01","https://git.kernel.org/stable/c/948615429c9f2ac9d25d4e1f1a4472926b217a9a","https://git.kernel.org/stable/c/b1217e40705b2f6d311c197b12866752656217ff"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23091","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nintel_th: fix device leak on output open()\n\nMake sure to drop the reference taken when looking up the th device\nduring output device open() on errors and on close().\n\nNote that a recent commit fixed the leak in a couple of open() error\npaths but not all of them, and the reference is still leaking on\nsuccessful open().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0fca16c5591534cc1fec8b6181277ee3a3d0f26c","https://git.kernel.org/stable/c/64015cbf06e8bb75b81ae95b997e847b55280f7f","https://git.kernel.org/stable/c/95fc36a234da24bbc5f476f8104a5a15f99ed3e3","https://git.kernel.org/stable/c/af4b9467296b9a16ebc008147238070236982b6d","https://git.kernel.org/stable/c/b71e64ef7ff9443835d1333e3e80ab1e49e5209f","https://git.kernel.org/stable/c/bf7785434b5d05d940d936b78925080950bd54dd","https://git.kernel.org/stable/c/f9b059bda4276f2bb72cb98ec7875a747f042ea2"],"published_time":"2026-02-04T17:16:19","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23073","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rsi: Fix memory corruption due to not set vif driver data size\n\nThe struct ieee80211_vif contains trailing space for vif driver data,\nwhen struct ieee80211_vif is allocated, the total memory size that is\nallocated is sizeof(struct ieee80211_vif) + size of vif driver data.\nThe size of vif driver data is set by each WiFi driver as needed.\n\nThe RSI911x driver does not set vif driver data size, no trailing space\nfor vif driver data is therefore allocated past struct ieee80211_vif .\nThe RSI911x driver does however use the vif driver data to store its\nvif driver data structure \"struct vif_priv\". An access to vif->drv_priv\nleads to access out of struct ieee80211_vif bounds and corruption of\nsome memory.\n\nIn case of the failure observed locally, rsi_mac80211_add_interface()\nwould write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv;\nvif_info->vap_id = vap_idx. This write corrupts struct fq_tin member\nstruct list_head new_flows . The flow = list_first_entry(head, struct\nfq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus\naddress, which when accessed causes a crash.\n\nThe trigger is very simple, boot the machine with init=/bin/sh , mount\ndevtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\",\n\"ip link set wlan0 down\" and the crash occurs.\n\nFix this by setting the correct size of vif driver data, which is the\nsize of \"struct vif_priv\", so that memory is allocated and the driver\ncan store its driver data in it, instead of corrupting memory around\nit.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04622,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d7c9e793e351cbbe9e06a9ca47d77b6ad288fb0","https://git.kernel.org/stable/c/31efbcff90884ea5f65bf3d1de01267db51ee3d1","https://git.kernel.org/stable/c/49ef094fdbc3526e5db2aebb404b84f79c5603dc","https://git.kernel.org/stable/c/4f431d88ea8093afc7ba55edf4652978c5a68f33","https://git.kernel.org/stable/c/7761d7801f40e61069b4df3db88b36d80d089f8a","https://git.kernel.org/stable/c/7c54d0c3e2cad4300be721ec2aecfcf8a63bc9f4","https://git.kernel.org/stable/c/99129d80a5d4989ef8566f434f3589f60f28042b"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23074","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Enforce that teql can only be used as root qdisc\n\nDesign intent of teql is that it is only supposed to be used as root qdisc.\nWe need to check for that constraint.\n\nAlthough not important, I will describe the scenario that unearthed this\nissue for the curious.\n\nGangMin Kim <km.kim1503@gmail.com> managed to concot a scenario as follows:\n\nROOT qdisc 1:0 (QFQ)\n  ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s\n  └── class 1:2 (weight=1, lmax=1514) teql\n\nGangMin sends a packet which is enqueued to 1:1 (netem).\nAny invocation of dequeue by QFQ from this class will not return a packet\nuntil after 6.4s. In the meantime, a second packet is sent and it lands on\n1:2. teql's enqueue will return success and this will activate class 1:2.\nMain issue is that teql only updates the parent visible qlen (sch->q.qlen)\nat dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's\npeek always returns NULL), dequeue will never be called and thus the qlen\nwill remain as 0. With that in mind, when GangMin updates 1:2's lmax value,\nthe qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's\nqlen was not incremented, qfq fails to deactivate the class, but still\nfrees its pointers from the aggregate. So when the first packet is\nrescheduled after 6.4 seconds (netem's delay), a dangling pointer is\naccessed causing GangMin's causing a UAF.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03364,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0686bedfed34155520f3f735cbf3210cb9044380","https://git.kernel.org/stable/c/16ed73c1282d376b956bff23e5139add061767ba","https://git.kernel.org/stable/c/4c7e8aa71c9232cba84c289b4b56cba80b280841","https://git.kernel.org/stable/c/50da4b9d07a7a463e2cfb738f3ad4cff6b2c9c3b","https://git.kernel.org/stable/c/73d970ff0eddd874a84c953387c7f4464b705fc6","https://git.kernel.org/stable/c/ae810e6a8ac4fe25042e6825d2a401207a2e41fb","https://git.kernel.org/stable/c/dad49a67c2d817bfec98e6e45121b351e3a0202c"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23075","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncan: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak\n\nFix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb:\ngs_usb_receive_bulk_callback(): fix URB memory leak\").\n\nIn esd_usb_open(), the URBs for USB-in transfers are allocated, added to\nthe dev->rx_submitted anchor and submitted. In the complete callback\nesd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In\nesd_usb_close() the URBs are freed by calling\nusb_kill_anchored_urbs(&dev->rx_submitted).\n\nHowever, this does not take into account that the USB framework unanchors\nthe URB before the complete function is called. This means that once an\nin-URB has been completed, it is no longer anchored and is ultimately not\nreleased in esd_usb_close().\n\nFix the memory leak by anchoring the URB in the\nesd_usb_read_bulk_callback() to the dev->rx_submitted anchor.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5a4391bdc6c8357242f62f22069c865b792406b3","https://git.kernel.org/stable/c/92d26ce07ac3b7a850dc68c8d73d487b39c39b33","https://git.kernel.org/stable/c/93b34d4ba7266030801a509c088ac77c0d7a12e9","https://git.kernel.org/stable/c/9d1807b442fc3286b204f8e59981b10e743533ce","https://git.kernel.org/stable/c/a9503ae43256e80db5cba9d449b238607164c51d","https://git.kernel.org/stable/c/adec5e1f9c99fe079ec4c92cca3f1109a3e257c3","https://git.kernel.org/stable/c/dc934d96673992af8568664c1b58e13eb164010d"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23076","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ctxfi: Fix potential OOB access in audio mixer handling\n\nIn the audio mixer handling code of ctxfi driver, the conf field is\nused as a kind of loop index, and it's referred in the index callbacks\n(amixer_index() and sum_index()).\n\nAs spotted recently by fuzzers, the current code causes OOB access at\nthose functions.\n| UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48\n| index 8 is out of range for type 'unsigned char [8]'\n\nAfter the analysis, the cause was found to be the lack of the proper\n(re-)initialization of conj field.\n\nThis patch addresses those OOB accesses by adding the proper\ninitializations of the loop indices.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.03364,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/61006c540cbdedea83b05577dc7fb7fa18fe1276","https://git.kernel.org/stable/c/6524205326e0c1a21263b5c14e48e14ef7e449ae","https://git.kernel.org/stable/c/873e2360d247eeee642878fcc3398babff7e387c","https://git.kernel.org/stable/c/8c1d09806e1441bc6a54b9a4f2818918046d5174","https://git.kernel.org/stable/c/a8c42d11b0526a89192bd2f79facb4c60c8a1f38","https://git.kernel.org/stable/c/afca7ff5d5d4d63a1acb95461f55ca9a729feedf","https://git.kernel.org/stable/c/d77ba72558cd66704f0fb7e0969f697e87c0f71c"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23077","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge\n\nPatch series \"mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted\nmerge\", v2.\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nHowever, it is handling merges incorrectly when it comes to mremap() of a\nfaulted VMA adjacent to an unfaulted VMA.  The issues arise in three\ncases:\n\n1. Previous VMA unfaulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|\n\t| unfaulted |(faulted VMA)|\n\t|-----------|.............|\n\t     prev\n\n2. Next VMA unfaulted:\n\n              copied -----|\n                          v\n\t            |.............|-----------|\n\t            |(faulted VMA)| unfaulted |\n                    |.............|-----------|\n\t\t                      next\n\n3. Both adjacent VMAs unfaulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)| unfaulted |\n\t|-----------|.............|-----------|\n\t     prev                      next\n\nThis series fixes each of these cases, and introduces self tests to assert\nthat the issues are corrected.\n\nI also test a further case which was already handled, to assert that my\nchanges continues to correctly handle it:\n\n4. prev unfaulted, next faulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)|  faulted  |\n\t|-----------|.............|-----------|\n\t     prev                      next\n\nThis bug was discovered via a syzbot report, linked to in the first patch\nin the series, I confirmed that this series fixes the bug.\n\nI also discovered that we are failing to check that the faulted VMA was\nnot forked when merging a copied VMA in cases 1-3 above, an issue this\nseries also addresses.\n\nI also added self tests to assert that this is resolved (and confirmed\nthat the tests failed prior to this).\n\nI also cleaned up vma_expand() as part of this work, renamed\nvma_had_uncowed_parents() to vma_is_fork_child() as the previous name was\nunduly confusing, and simplified the comments around this function.\n\n\nThis patch (of 4):\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nThe key piece of logic introduced was the ability to merge a faulted VMA\nimmediately next to an unfaulted VMA, which relies upon dup_anon_vma() to\ncorrectly handle anon_vma state.\n\nIn the case of the merge of an existing VMA (that is changing properties\nof a VMA and then merging if those properties are shared by adjacent\nVMAs), dup_anon_vma() is invoked correctly.\n\nHowever in the case of the merge of a new VMA, a corner case peculiar to\nmremap() was missed.\n\nThe issue is that vma_expand() only performs dup_anon_vma() if the target\n(the VMA that will ultimately become the merged VMA): is not the next VMA,\ni.e.  the one that appears after the range in which the new VMA is to be\nestablished.\n\nA key insight here is that in all other cases other than mremap(), a new\nVMA merge either expands an existing VMA, meaning that the target VMA will\nbe that VMA, or would have anon_vma be NULL.\n\nSpecifically:\n\n* __mmap_region() - no anon_vma in place, initial mapping.\n* do_brk_flags() - expanding an existing VMA.\n* vma_merge_extend() - expanding an existing VMA.\n* relocate_vma_down() - no anon_vma in place, initial mapping.\n\nIn addition, we are in the unique situation of needing to duplicate\nanon_vma state from a VMA that is neither the previous or next VMA being\nmerged with.\n\ndup_anon_vma() deals exclusively with the target=unfaulted, src=faulted\ncase.  This leaves four possibilities, in each case where the copied VMA\nis faulted:\n\n1. Previous VMA unfaulted:\n\n              copied -----|\n                       \n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.03936,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/61f67c230a5e7c741c352349ea80147fbe65bfae","https://git.kernel.org/stable/c/a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23078","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: scarlett2: Fix buffer overflow in config retrieval\n\nThe scarlett2_usb_get_config() function has a logic error in the\nendianness conversion code that can cause buffer overflows when\ncount > 1.\n\nThe code checks `if (size == 2)` where `size` is the total buffer size in\nbytes, then loops `count` times treating each element as u16 (2 bytes).\nThis causes the loop to access `count * 2` bytes when the buffer only\nhas `size` bytes allocated.\n\nFix by checking the element size (config_item->size) instead of the\ntotal buffer size. This ensures the endianness conversion matches the\nactual element type.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03364,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/27049f50be9f5ae3a62d272128ce0b381cb26a24","https://git.kernel.org/stable/c/31a3eba5c265a763260976674a22851e83128f6d","https://git.kernel.org/stable/c/51049f6e3f05d70660e2458ad3bb302a3721b751","https://git.kernel.org/stable/c/6f5c69f72e50d51be3a8c028ae7eda42c82902cb","https://git.kernel.org/stable/c/91a756d22f0482eac5bedb113c8922f90b254449","https://git.kernel.org/stable/c/d5e80d1f97ae55bcea1426f551e4419245b41b9c"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23079","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: cdev: Fix resource leaks on errors in lineinfo_changed_notify()\n\nOn error handling paths, lineinfo_changed_notify() doesn't free the\nallocated resources which results leaks.  Fix it.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/16414341b0dd58b650b5df45c79115bc5977bb76","https://git.kernel.org/stable/c/70b3c280533167749a8f740acaa8ef720f78f984"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23080","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncan: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak\n\nFix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb:\ngs_usb_receive_bulk_callback(): fix URB memory leak\").\n\nIn mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are\nallocated, added to the priv->rx_submitted anchor and submitted. In the\ncomplete callback mcba_usb_read_bulk_callback(), the URBs are processed and\nresubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by\ncalling usb_kill_anchored_urbs(&priv->rx_submitted).\n\nHowever, this does not take into account that the USB framework unanchors\nthe URB before the complete function is called. This means that once an\nin-URB has been completed, it is no longer anchored and is ultimately not\nreleased in usb_kill_anchored_urbs().\n\nFix the memory leak by anchoring the URB in the\nmcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/179f6f0cf5ae489743273b7c1644324c0c477ea9","https://git.kernel.org/stable/c/59153b6388e05609144ad56a9b354e9100a91983","https://git.kernel.org/stable/c/710a7529fb13c5a470258ff5508ed3c498d54729","https://git.kernel.org/stable/c/8b34c611a4feb81921bc4728c091e4e3ba0270c0","https://git.kernel.org/stable/c/94c9f6f7b953f6382fef4bdc48c046b861b8868f","https://git.kernel.org/stable/c/b5a1ccdc63b71d93a69a6b72f7a3f3934293ea60","https://git.kernel.org/stable/c/d374d715e338dfc3804aaa006fa6e470ffebb264"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23081","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: intel-xway: fix OF node refcount leakage\n\nAutomated review spotted am OF node reference count leakage when\nchecking if the 'leds' child node exists.\n\nCall of_put_node() to correctly maintain the refcount.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1f24dfd556401b75f78e8d9cbd94dd9f31411c3a","https://git.kernel.org/stable/c/79912b256e14054e6ba177d7e7e631485ce23dbe"],"published_time":"2026-02-04T17:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23064","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ife: avoid possible NULL deref\n\ntcf_ife_encode() must make sure ife_encode() does not return NULL.\n\nsyzbot reported:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166\nCPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)\nCall Trace:\n <TASK>\n  ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101\n  tcf_ife_encode net/sched/act_ife.c:841 [inline]\n  tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877\n  tc_act include/net/tc_wrapper.h:130 [inline]\n  tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152\n  tcf_exts_exec include/net/pkt_cls.h:349 [inline]\n  mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42\n  tc_classify include/net/tc_wrapper.h:197 [inline]\n  __tcf_classify net/sched/cls_api.c:1764 [inline]\n  tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860\n  multiq_classify net/sched/sch_multiq.c:39 [inline]\n  multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66\n  dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147\n  __dev_xmit_skb net/core/dev.c:4262 [inline]\n  __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03710cebfc0bcfe247a9e04381e79ea33896e278","https://git.kernel.org/stable/c/1440d749fe49c8665da6f744323b1671d25a56a0","https://git.kernel.org/stable/c/27880b0b0d35ad1c98863d09788254e36f874968","https://git.kernel.org/stable/c/374915dfc932adf57712df3be010667fd1190e3c","https://git.kernel.org/stable/c/4ef2c77851676b7ed106f0c47755bee9eeec9a40","https://git.kernel.org/stable/c/6c75fed55080014545f262b7055081cec4768b20","https://git.kernel.org/stable/c/dd9442aedbeae87c44cc64c0ee41abd296dc008b"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23065","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd: Fix memory leak in wbrf_record()\n\nThe tmp buffer is allocated using kcalloc() but is not freed if\nacpi_evaluate_dsm() fails. This causes a memory leak in the error path.\n\nFix this by explicitly freeing the tmp buffer in the error handling\npath of acpi_evaluate_dsm().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1152dffe01af86e42ce2b208b92ef7f8c275d130","https://git.kernel.org/stable/c/1a0072bd1f1e559eda3e91a24dbc51c9eb025c54","https://git.kernel.org/stable/c/2bf1877b7094c684e1d652cac6912cfbc507ad3e"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23066","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix recvmsg() unconditional requeue\n\nIf rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at\nthe front of the recvmsg queue already has its mutex locked, it requeues\nthe call - whether or not the call is already queued.  The call may be on\nthe queue because MSG_PEEK was also passed and so the call was not dequeued\nor because the I/O thread requeued it.\n\nThe unconditional requeue may then corrupt the recvmsg queue, leading to\nthings like UAFs or refcount underruns.\n\nFix this by only requeuing the call if it isn't already on the queue - and\nmoving it to the front if it is already queued.  If we don't queue it, we\nhave to put the ref we obtained by dequeuing it.\n\nAlso, MSG_PEEK doesn't dequeue the call so shouldn't call\nrxrpc_notify_socket() for the call if we didn't use up all the data on the\nqueue, so fix that also.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0464bf75590da75b8413c3e758c04647b4cdb3c6","https://git.kernel.org/stable/c/2c28769a51deb6022d7fbd499987e237a01dd63a","https://git.kernel.org/stable/c/930114425065f7ace6e0c0630fab4af75e059ea8","https://git.kernel.org/stable/c/cf969bddd6e69c5777fa89dc88402204e72f312a"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23067","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/io-pgtable-arm: fix size_t signedness bug in unmap path\n\n__arm_lpae_unmap() returns size_t but was returning -ENOENT (negative\nerror code) when encountering an unmapped PTE. Since size_t is unsigned,\n-ENOENT (typically -2) becomes a huge positive value (0xFFFFFFFFFFFFFFFE\non 64-bit systems).\n\nThis corrupted value propagates through the call chain:\n  __arm_lpae_unmap() returns -ENOENT as size_t\n  -> arm_lpae_unmap_pages() returns it\n  -> __iommu_unmap() adds it to iova address\n  -> iommu_pgsize() triggers BUG_ON due to corrupted iova\n\nThis can cause IOVA address overflow in __iommu_unmap() loop and\ntrigger BUG_ON in iommu_pgsize() from invalid address alignment.\n\nFix by returning 0 instead of -ENOENT. The WARN_ON already signals\nthe error condition, and returning 0 (meaning \"nothing unmapped\")\nis the correct semantic for size_t return type. This matches the\nbehavior of other io-pgtable implementations (io-pgtable-arm-v7s,\nio-pgtable-dart) which return 0 on error conditions.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/374e7af67d9d9d6103c2cfc8eb32abfecf3a2fd8","https://git.kernel.org/stable/c/41ec6988547819756fb65e94fc24f3e0dddf84ac"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23068","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-sprd-adi: Fix double free in probe error path\n\nThe driver currently uses spi_alloc_host() to allocate the controller\nbut registers it using devm_spi_register_controller().\n\nIf devm_register_restart_handler() fails, the code jumps to the\nput_ctlr label and calls spi_controller_put(). However, since the\ncontroller was registered via a devm function, the device core will\nautomatically call spi_controller_put() again when the probe fails.\nThis results in a double-free of the spi_controller structure.\n\nFix this by switching to devm_spi_alloc_host() and removing the\nmanual spi_controller_put() call.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0334,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/346775f2b4cf839177e8e86b94aa180a06dc15b0","https://git.kernel.org/stable/c/383d4f5cffcc8df930d95b06518a9d25a6d74aac","https://git.kernel.org/stable/c/417cdfd9b9f986e95bfcb1d68eb443e6e0a15f8c","https://git.kernel.org/stable/c/bddd3d10d039729b81cfb0804520c8832a701a0e","https://git.kernel.org/stable/c/f6d6b3f172df118db582fe5ec43ae223a55d99cf"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23069","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: fix potential underflow in virtio_transport_get_credit()\n\nThe credit calculation in virtio_transport_get_credit() uses unsigned\narithmetic:\n\n  ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);\n\nIf the peer shrinks its advertised buffer (peer_buf_alloc) while bytes\nare in flight, the subtraction can underflow and produce a large\npositive value, potentially allowing more data to be queued than the\npeer can handle.\n\nReuse virtio_transport_has_space() which already handles this case and\nadd a comment to make it clear why we are doing that.\n\n[Stefano: use virtio_transport_has_space() instead of duplicating the code]\n[Stefano: tweak the commit message]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/02f9af192b98d15883c70dd41ac76d1b0217c899","https://git.kernel.org/stable/c/3ef3d52a1a9860d094395c7a3e593f3aa26ff012","https://git.kernel.org/stable/c/d05bc313788f0684b27f0f5b60c52a844669b542","https://git.kernel.org/stable/c/d96de882d6b99955604669d962ae14e94b66a551","https://git.kernel.org/stable/c/ec0f1b3da8061be3173d1c39faaf9504f91942c3"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23070","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nOcteontx2-af: Add proper checks for fwdata\n\nfirmware populates MAC address, link modes (supported, advertised)\nand EEPROM data in shared firmware structure which kernel access\nvia MAC block(CGX/RPM).\n\nAccessing fwdata, on boards booted with out MAC block leading to\nkernel panics.\n\nInternal error: Oops: 0000000096000005 [#1]  SMP\n[   10.460721] Modules linked in:\n[   10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT\n[   10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT)\n[   10.479793] Workqueue: events work_for_cpu_fn\n[   10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   10.491124] pc : rvu_sdp_init+0x18/0x114\n[   10.495051] lr : rvu_probe+0xe58/0x1d18","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/079050a23de6b7505595e4af75b36c34f0e9627e","https://git.kernel.org/stable/c/4a3dba48188208e4f66822800e042686784d29d1","https://git.kernel.org/stable/c/e343973fab43c266a40e4e0dabdc4216db6d5eff"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23071","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nregmap: Fix race condition in hwspinlock irqsave routine\n\nPreviously, the address of the shared member '&map->spinlock_flags' was\npassed directly to 'hwspin_lock_timeout_irqsave'. This creates a race\ncondition where multiple contexts contending for the lock could overwrite\nthe shared flags variable, potentially corrupting the state for the\ncurrent lock owner.\n\nFix this by using a local stack variable 'flags' to store the IRQ state\ntemporarily.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00014,"ranking_epss":0.02455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/24f31be6ad70537fd7706269d99c92cade465a09","https://git.kernel.org/stable/c/4aab0ca0a0f7760e33edcb4e47576064d05128f5","https://git.kernel.org/stable/c/4b58aac989c1e3fafb1c68a733811859df388250","https://git.kernel.org/stable/c/766e243ae8c8b27087a4cc605752c0d5ee2daeab","https://git.kernel.org/stable/c/c2d2cf710dc3ee1a69e00b4ed8de607a92a07889","https://git.kernel.org/stable/c/e1a7072bc4f958c9e852dc7e57e39f12b0bb44b5","https://git.kernel.org/stable/c/f1e2fe26a51eca95b41420af76d22c2e613efd5e"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23072","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: Fix memleak in l2tp_udp_encap_recv().\n\nsyzbot reported memleak of struct l2tp_session, l2tp_tunnel,\nsock, etc. [0]\n\nThe cited commit moved down the validation of the protocol\nversion in l2tp_udp_encap_recv().\n\nThe new place requires an extra error handling to avoid the\nmemleak.\n\nLet's call l2tp_session_put() there.\n\n[0]:\nBUG: memory leak\nunreferenced object 0xffff88810a290200 (size 512):\n  comm \"syz.0.17\", pid 6086, jiffies 4294944299\n  hex dump (first 32 bytes):\n    7d eb 04 0c 00 00 00 00 01 00 00 00 00 00 00 00  }...............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace (crc babb6a4f):\n    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]\n    slab_post_alloc_hook mm/slub.c:4958 [inline]\n    slab_alloc_node mm/slub.c:5263 [inline]\n    __do_kmalloc_node mm/slub.c:5656 [inline]\n    __kmalloc_noprof+0x3e0/0x660 mm/slub.c:5669\n    kmalloc_noprof include/linux/slab.h:961 [inline]\n    kzalloc_noprof include/linux/slab.h:1094 [inline]\n    l2tp_session_create+0x3a/0x3b0 net/l2tp/l2tp_core.c:1778\n    pppol2tp_connect+0x48b/0x920 net/l2tp/l2tp_ppp.c:755\n    __sys_connect_file+0x7a/0xb0 net/socket.c:2089\n    __sys_connect+0xde/0x110 net/socket.c:2108\n    __do_sys_connect net/socket.c:2114 [inline]\n    __se_sys_connect net/socket.c:2111 [inline]\n    __x64_sys_connect+0x1c/0x30 net/socket.c:2111\n    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94\n    entry_SYSCALL_64_after_hwframe+0x77/0x7f","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4d10edfd1475b69dbd4c47f34b61a3772ece83ca","https://git.kernel.org/stable/c/5cd158a88eef34e7b100cd9b963873d3b4e41b35","https://git.kernel.org/stable/c/d4ce79e6dce2a4a49eebceea7b4caf5dc0f0ef3d"],"published_time":"2026-02-04T17:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23060","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec\n\nauthencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than\nthe minimum expected length, crypto_authenc_esn_decrypt() can advance past\nthe end of the destination scatterlist and trigger a NULL pointer dereference\nin scatterwalk_map_and_copy(), leading to a kernel panic (DoS).\n\nAdd a minimum AAD length check to fail fast on invalid inputs.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/161bdc90fce25bd9890adc67fa1c8563a7acbf40","https://git.kernel.org/stable/c/2397e9264676be7794f8f7f1e9763d90bd3c7335","https://git.kernel.org/stable/c/767e8349f7e929b7dd95c08f0b4cb353459b365e","https://git.kernel.org/stable/c/9532ff0d0e90ff78a214299f594ab9bac81defe4","https://git.kernel.org/stable/c/b0a9609283a5c852addb513dafa655c61eebc1ef","https://git.kernel.org/stable/c/df22c9a65e9a9daa368a72fed596af9d7d5876bb","https://git.kernel.org/stable/c/fee86edf5803f1d1f19e3b4f2dacac241bddfa48"],"published_time":"2026-02-04T17:16:16","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23061","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncan: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak\n\nFix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb:\ngs_usb_receive_bulk_callback(): fix URB memory leak\").\n\nIn kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the\nURBs for USB-in transfers are allocated, added to the dev->rx_submitted\nanchor and submitted. In the complete callback\nkvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In\nkvaser_usb_remove_interfaces() the URBs are freed by calling\nusb_kill_anchored_urbs(&dev->rx_submitted).\n\nHowever, this does not take into account that the USB framework unanchors\nthe URB before the complete function is called. This means that once an\nin-URB has been completed, it is no longer anchored and is ultimately not\nreleased in usb_kill_anchored_urbs().\n\nFix the memory leak by anchoring the URB in the\nkvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/248e8e1a125fa875158df521b30f2cc7e27eeeaa","https://git.kernel.org/stable/c/3b1a593eab941c3f32417896cc7df564191f2482","https://git.kernel.org/stable/c/40a3334ffda479c63e416e61ff086485e24401f7","https://git.kernel.org/stable/c/7c308f7530bffafa994e0aa8dc651a312f4b9ff4","https://git.kernel.org/stable/c/94a7fc42e21c7d9d1c49778cd1db52de5df52a01","https://git.kernel.org/stable/c/c1b39fa24c140bc616f51fef4175c1743e2bb132","https://git.kernel.org/stable/c/d9d824582f2ec76459ffab449e9b05c7bc49645c"],"published_time":"2026-02-04T17:16:16","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23062","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro\n\nThe GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs\nattributes:\n\n1. Off-by-one error: The loop condition used '<=' instead of '<',\n   causing access beyond array bounds. Since array indices are 0-based\n   and go from 0 to instances_count-1, the loop should use '<'.\n\n2. Missing NULL check: The code dereferenced attr_name_kobj->name\n   without checking if attr_name_kobj was NULL, causing a null pointer\n   dereference in min_length_show() and other attribute show functions.\n\nThe panic occurred when fwupd tried to read BIOS configuration attributes:\n\n  Oops: general protection fault [#1] SMP KASAN NOPTI\n  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n  RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg]\n\nAdd a NULL check for attr_name_kobj before dereferencing and corrects\nthe loop boundary to match the pattern used elsewhere in the driver.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/193922a23d7294085a47d7719fdb7d66ad0a236f","https://git.kernel.org/stable/c/25150715e0b049b99df664daf05dab12f41c3e13","https://git.kernel.org/stable/c/eb5ff1025c92117d5d1cc728bcfa294abe484da1","https://git.kernel.org/stable/c/eba49c1dee9c5e514ca18e52c545bba524e8a045"],"published_time":"2026-02-04T17:16:16","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23063","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nuacce: ensure safe queue release with state management\n\nDirectly calling `put_queue` carries risks since it cannot\nguarantee that resources of `uacce_queue` have been fully released\nbeforehand. So adding a `stop_queue` operation for the\nUACCE_CMD_PUT_Q command and leaving the `put_queue` operation to\nthe final resource release ensures safety.\n\nQueue states are defined as follows:\n- UACCE_Q_ZOMBIE: Initial state\n- UACCE_Q_INIT: After opening `uacce`\n- UACCE_Q_STARTED: After `start` is issued via `ioctl`\n\nWhen executing `poweroff -f` in virt while accelerator are still\nworking, `uacce_fops_release` and `uacce_remove` may execute\nconcurrently. This can cause `uacce_put_queue` within\n`uacce_fops_release` to access a NULL `ops` pointer. Therefore, add\nstate checks to prevent accessing freed pointers.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03156,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/26c08dabe5475d99a13f353d8dd70e518de45663","https://git.kernel.org/stable/c/336fb41a186e7c0415ae94fec9e23d1f04b87483","https://git.kernel.org/stable/c/43f233eb6e7b9d88536881a9bc43726d0e34800d","https://git.kernel.org/stable/c/47634d70073890c9c37e39ab4ff93d4b585b028a","https://git.kernel.org/stable/c/8b57bf1d3b1db692f34bce694a03e41be79f6016","https://git.kernel.org/stable/c/92e4f11e29b98ef424ff72d6371acac03e5d973c","https://git.kernel.org/stable/c/b457abeb5d962db88aaf60e249402fd3073dbfab"],"published_time":"2026-02-04T17:16:16","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33081","summary":"IBM Concert 1.0.0 through 2.1.0 stores potentially sensitive information in log files that could be read by a local user.","cvss":3.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.3,"epss":4e-05,"ranking_epss":0.00146,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7257565"],"published_time":"2026-02-03T23:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-1861","summary":"Heap buffer overflow in libvpx in Google Chrome prior to 144.0.7559.132 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.0003,"ranking_epss":0.08521,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/478942410"],"published_time":"2026-02-03T21:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-1862","summary":"Type Confusion in V8 in Google Chrome prior to 144.0.7559.132 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00054,"ranking_epss":0.16991,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/479726070","https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-1862"],"published_time":"2026-02-03T21:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36253","summary":"IBM Concert 1.0.0 through 2.1.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.","cvss":5.9,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.9,"epss":0.0001,"ranking_epss":0.01099,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7257565"],"published_time":"2026-02-02T23:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23017","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix error handling in the init_task on load\n\nIf the init_task fails during a driver load, we end up without vports and\nnetdevs, effectively failing the entire process. In that state a\nsubsequent reset will result in a crash as the service task attempts to\naccess uninitialized resources. Following trace is from an error in the\ninit_task where the CREATE_VPORT (op 501) is rejected by the FW:\n\n[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated\n[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)\n[40958.148190] idpf 0000:83:00.0: HW reset detected\n[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8\n...\n[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf]\n[40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]\n...\n[40958.177932] Call Trace:\n[40958.178491]  <TASK>\n[40958.179040]  process_one_work+0x226/0x6d0\n[40958.179609]  worker_thread+0x19e/0x340\n[40958.180158]  ? __pfx_worker_thread+0x10/0x10\n[40958.180702]  kthread+0x10f/0x250\n[40958.181238]  ? __pfx_kthread+0x10/0x10\n[40958.181774]  ret_from_fork+0x251/0x2b0\n[40958.182307]  ? __pfx_kthread+0x10/0x10\n[40958.182834]  ret_from_fork_asm+0x1a/0x30\n[40958.183370]  </TASK>\n\nFix the error handling in the init_task to make sure the service and\nmailbox tasks are disabled if the error happens during load. These are\nstarted in idpf_vc_core_init(), which spawns the init_task and has no way\nof knowing if it failed. If the error happens on reset, following\nsuccessful driver load, the tasks can still run, as that will allow the\nnetdevs to attempt recovery through another reset. Stop the PTP callbacks\neither way as those will be restarted by the call to idpf_vc_core_init()\nduring a successful reset.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4d792219fe6f891b5b557a607ac8a0a14eda6e38","https://git.kernel.org/stable/c/a514c374edcd33581cdcccf8faa7cc606a600319"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23018","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: release path before initializing extent tree in btrfs_read_locked_inode()\n\nIn btrfs_read_locked_inode() we are calling btrfs_init_file_extent_tree()\nwhile holding a path with a read locked leaf from a subvolume tree, and\nbtrfs_init_file_extent_tree() may do a GFP_KERNEL allocation, which can\ntrigger reclaim.\n\nThis can create a circular lock dependency which lockdep warns about with\nthe following splat:\n\n   [6.1433] ======================================================\n   [6.1574] WARNING: possible circular locking dependency detected\n   [6.1583] 6.18.0+ #4 Tainted: G     U\n   [6.1591] ------------------------------------------------------\n   [6.1599] kswapd0/117 is trying to acquire lock:\n   [6.1606] ffff8d9b6333c5b8 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x39/0x2f0\n   [6.1625]\n            but task is already holding lock:\n   [6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60\n   [6.1646]\n            which lock already depends on the new lock.\n\n   [6.1657]\n            the existing dependency chain (in reverse order) is:\n   [6.1667]\n            -> #2 (fs_reclaim){+.+.}-{0:0}:\n   [6.1677]        fs_reclaim_acquire+0x9d/0xd0\n   [6.1685]        __kmalloc_cache_noprof+0x59/0x750\n   [6.1694]        btrfs_init_file_extent_tree+0x90/0x100\n   [6.1702]        btrfs_read_locked_inode+0xc3/0x6b0\n   [6.1710]        btrfs_iget+0xbb/0xf0\n   [6.1716]        btrfs_lookup_dentry+0x3c5/0x8e0\n   [6.1724]        btrfs_lookup+0x12/0x30\n   [6.1731]        lookup_open.isra.0+0x1aa/0x6a0\n   [6.1739]        path_openat+0x5f7/0xc60\n   [6.1746]        do_filp_open+0xd6/0x180\n   [6.1753]        do_sys_openat2+0x8b/0xe0\n   [6.1760]        __x64_sys_openat+0x54/0xa0\n   [6.1768]        do_syscall_64+0x97/0x3e0\n   [6.1776]        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   [6.1784]\n            -> #1 (btrfs-tree-00){++++}-{3:3}:\n   [6.1794]        lock_release+0x127/0x2a0\n   [6.1801]        up_read+0x1b/0x30\n   [6.1808]        btrfs_search_slot+0x8e0/0xff0\n   [6.1817]        btrfs_lookup_inode+0x52/0xd0\n   [6.1825]        __btrfs_update_delayed_inode+0x73/0x520\n   [6.1833]        btrfs_commit_inode_delayed_inode+0x11a/0x120\n   [6.1842]        btrfs_log_inode+0x608/0x1aa0\n   [6.1849]        btrfs_log_inode_parent+0x249/0xf80\n   [6.1857]        btrfs_log_dentry_safe+0x3e/0x60\n   [6.1865]        btrfs_sync_file+0x431/0x690\n   [6.1872]        do_fsync+0x39/0x80\n   [6.1879]        __x64_sys_fsync+0x13/0x20\n   [6.1887]        do_syscall_64+0x97/0x3e0\n   [6.1894]        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   [6.1903]\n            -> #0 (&delayed_node->mutex){+.+.}-{3:3}:\n   [6.1913]        __lock_acquire+0x15e9/0x2820\n   [6.1920]        lock_acquire+0xc9/0x2d0\n   [6.1927]        __mutex_lock+0xcc/0x10a0\n   [6.1934]        __btrfs_release_delayed_node.part.0+0x39/0x2f0\n   [6.1944]        btrfs_evict_inode+0x20b/0x4b0\n   [6.1952]        evict+0x15a/0x2f0\n   [6.1958]        prune_icache_sb+0x91/0xd0\n   [6.1966]        super_cache_scan+0x150/0x1d0\n   [6.1974]        do_shrink_slab+0x155/0x6f0\n   [6.1981]        shrink_slab+0x48e/0x890\n   [6.1988]        shrink_one+0x11a/0x1f0\n   [6.1995]        shrink_node+0xbfd/0x1320\n   [6.1002]        balance_pgdat+0x67f/0xc60\n   [6.1321]        kswapd+0x1dc/0x3e0\n   [6.1643]        kthread+0xff/0x240\n   [6.1965]        ret_from_fork+0x223/0x280\n   [6.1287]        ret_from_fork_asm+0x1a/0x30\n   [6.1616]\n            other info that might help us debug this:\n\n   [6.1561] Chain exists of:\n              &delayed_node->mutex --> btrfs-tree-00 --> fs_reclaim\n\n   [6.1503]  Possible unsafe locking scenario:\n\n   [6.1110]        CPU0                    CPU1\n   [6.1411]        ----                    ----\n   [6.1707]   lock(fs_reclaim);\n   [6.1998]                                lock(btrfs-tree-00);\n   [6.1291]                                lock(fs_reclaim);\n   [6.1581]   lock(&del\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/8731f2c50b0b1d2b58ed5b9671ef2c4bdc2f8347","https://git.kernel.org/stable/c/92a5590851144f034adc51fee55e6878ccac716e"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23019","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: marvell: prestera: fix NULL dereference on devlink_alloc() failure\n\ndevlink_alloc() may return NULL on allocation failure, but\nprestera_devlink_alloc() unconditionally calls devlink_priv() on\nthe returned pointer.\n\nThis leads to a NULL pointer dereference if devlink allocation fails.\nAdd a check for a NULL devlink pointer and return NULL early to avoid\nthe crash.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/325aea74be7e192b5c947c782da23b0d19a5fda2","https://git.kernel.org/stable/c/326a4b7e61d01db3507f71c8bb5e85362f607064","https://git.kernel.org/stable/c/3950054c9512add0cc79ab7e72b6d2f9f675e25b","https://git.kernel.org/stable/c/8a4333b2818f0d853b43e139936c20659366e4a0","https://git.kernel.org/stable/c/94e070cd50790317fba7787ae6006934b7edcb6f","https://git.kernel.org/stable/c/a428e0da1248c353557970848994f35fd3f005e2"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23020","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: 3com: 3c59x: fix possible null dereference in vortex_probe1()\n\npdev can be null and free_ring: can be called in 1297 with a null\npdev.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/053ac9e37eee435e999277c0f1ef890dad6064bf","https://git.kernel.org/stable/c/28b2a805609699be7b90020ae7dccfb234be1ceb","https://git.kernel.org/stable/c/2f05f7737e16d9a40038cc1c38a96a3f7964898b","https://git.kernel.org/stable/c/606872c8e8bf96066730f6a2317502c5633c37f1","https://git.kernel.org/stable/c/6cff14b831dbdb32675b4c7904dcc3eeeaf47e9d","https://git.kernel.org/stable/c/a4e305ed60f7c41bbf9aabc16dd75267194e0de3","https://git.kernel.org/stable/c/d82796a57cc0dac1dbef19d913c8f02a8cc7b1a7"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23021","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: pegasus: fix memory leak in update_eth_regs_async()\n\nWhen asynchronously writing to the device registers and if usb_submit_urb()\nfail, the code fail to release allocated to this point resources.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/471dfb97599eec74e0476046b3ef8e7037f27b34","https://git.kernel.org/stable/c/5397ea6d21c35a17707e201a60761bdee00bcc4e","https://git.kernel.org/stable/c/93f18eaa190374e0f2d253e3b1a65cee19a7abe6","https://git.kernel.org/stable/c/a40af9a2904a1ab8ce61866ebe2a894ef30754ba","https://git.kernel.org/stable/c/ac5d92d2826dec51e5d4c6854865bc5817277452","https://git.kernel.org/stable/c/afa27621a28af317523e0836dad430bec551eb54","https://git.kernel.org/stable/c/ce6eef731aba23a988decea1df3b08cf978f7b01"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23022","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix memory leak in idpf_vc_core_deinit()\n\nMake sure to free hw->lan_regs. Reported by kmemleak during reset:\n\nunreferenced object 0xff1b913d02a936c0 (size 96):\n  comm \"kworker/u258:14\", pid 2174, jiffies 4294958305\n  hex dump (first 32 bytes):\n    00 00 00 c0 a8 ba 2d ff 00 00 00 00 00 00 00 00  ......-.........\n    00 00 40 08 00 00 00 00 00 00 25 b3 a8 ba 2d ff  ..@.......%...-.\n  backtrace (crc 36063c4f):\n    __kmalloc_noprof+0x48f/0x890\n    idpf_vc_core_init+0x6ce/0x9b0 [idpf]\n    idpf_vc_event_task+0x1fb/0x350 [idpf]\n    process_one_work+0x226/0x6d0\n    worker_thread+0x19e/0x340\n    kthread+0x10f/0x250\n    ret_from_fork+0x251/0x2b0\n    ret_from_fork_asm+0x1a/0x30","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/23391db8a00c23854915b8b72ec1aa10080aa540","https://git.kernel.org/stable/c/e111cbc4adf9f9974eed040aeece7e17460f6bff"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23023","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix memory leak in idpf_vport_rel()\n\nFree vport->rx_ptype_lkup in idpf_vport_rel() to avoid leaking memory\nduring a reset. Reported by kmemleak:\n\nunreferenced object 0xff450acac838a000 (size 4096):\n  comm \"kworker/u258:5\", pid 7732, jiffies 4296830044\n  hex dump (first 32 bytes):\n    00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00  ................\n  backtrace (crc 3da81902):\n    __kmalloc_cache_noprof+0x469/0x7a0\n    idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf]\n    idpf_init_task+0x1ec/0x8d0 [idpf]\n    process_one_work+0x226/0x6d0\n    worker_thread+0x19e/0x340\n    kthread+0x10f/0x250\n    ret_from_fork+0x251/0x2b0\n    ret_from_fork_asm+0x1a/0x30","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/a4212d6732e3f674c6cc7d0b642f276d827e8f94","https://git.kernel.org/stable/c/ec602a2a4071eb956d656ba968c58fee09f0622d","https://git.kernel.org/stable/c/f6242b354605faff263ca45882b148200915a3f6"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23024","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix memory leak of flow steer list on rmmod\n\nThe flow steering list maintains entries that are added and removed as\nethtool creates and deletes flow steering rules. Module removal with active\nentries causes memory leak as the list is not properly cleaned up.\n\nPrevent this by iterating through the remaining entries in the list and\nfreeing the associated memory during module removal. Add a spinlock\n(flow_steer_list_lock) to protect the list access from multiple threads.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1aedff70a5e97628eaaf17b169774cb6a45a1dc5","https://git.kernel.org/stable/c/f9841bd28b600526ca4f6713b0ca49bf7bb98452"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23025","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: prevent pcp corruption with SMP=n\n\nThe kernel test robot has reported:\n\n BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28\n  lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0\n CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT  8cc09ef94dcec767faa911515ce9e609c45db470\n Call Trace:\n  <IRQ>\n  __dump_stack (lib/dump_stack.c:95)\n  dump_stack_lvl (lib/dump_stack.c:123)\n  dump_stack (lib/dump_stack.c:130)\n  spin_dump (kernel/locking/spinlock_debug.c:71)\n  do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?)\n  _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138)\n  __free_frozen_pages (mm/page_alloc.c:2973)\n  ___free_pages (mm/page_alloc.c:5295)\n  __free_pages (mm/page_alloc.c:5334)\n  tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290)\n  ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289)\n  ? rcu_core (kernel/rcu/tree.c:?)\n  rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861)\n  rcu_core_si (kernel/rcu/tree.c:2879)\n  handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623)\n  __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725)\n  irq_exit_rcu (kernel/softirq.c:741)\n  sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052)\n  </IRQ>\n  <TASK>\n RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194)\n  free_pcppages_bulk (mm/page_alloc.c:1494)\n  drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632)\n  __drain_all_pages (mm/page_alloc.c:2731)\n  drain_all_pages (mm/page_alloc.c:2747)\n  kcompactd (mm/compaction.c:3115)\n  kthread (kernel/kthread.c:465)\n  ? __cfi_kcompactd (mm/compaction.c:3166)\n  ? __cfi_kthread (kernel/kthread.c:412)\n  ret_from_fork (arch/x86/kernel/process.c:164)\n  ? __cfi_kthread (kernel/kthread.c:412)\n  ret_from_fork_asm (arch/x86/entry/entry_64.S:255)\n  </TASK>\n\nMatthew has analyzed the report and identified that in drain_page_zone()\nwe are in a section protected by spin_lock(&pcp->lock) and then get an\ninterrupt that attempts spin_trylock() on the same lock.  The code is\ndesigned to work this way without disabling IRQs and occasionally fail the\ntrylock with a fallback.  However, the SMP=n spinlock implementation\nassumes spin_trylock() will always succeed, and thus it's normally a\nno-op.  Here the enabled lock debugging catches the problem, but otherwise\nit could cause a corruption of the pcp structure.\n\nThe problem has been introduced by commit 574907741599 (\"mm/page_alloc:\nleave IRQs enabled for per-cpu page allocations\").  The pcp locking scheme\nrecognizes the need for disabling IRQs to prevent nesting spin_trylock()\nsections on SMP=n, but the need to prevent the nesting in spin_lock() has\nnot been recognized.  Fix it by introducing local wrappers that change the\nspin_lock() to spin_lock_iqsave() with SMP=n and use them in all places\nthat do spin_lock(&pcp->lock).\n\n[vbabka@suse.cz: add pcp_ prefix to the spin_lock_irqsave wrappers, per Steven]","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":9e-05,"ranking_epss":0.00932,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/038a102535eb49e10e93eafac54352fcc5d78847","https://git.kernel.org/stable/c/3098f8f7c7b0686c74827aec42a2c45e69801ff8","https://git.kernel.org/stable/c/4a04ff9cd816e7346fcc8126f00ed80481f6569d","https://git.kernel.org/stable/c/68688fc4eab007834b4c2d740214423ba2a335a8","https://git.kernel.org/stable/c/df63d31e9ae02e2f6cd96147779e4ed7cd0e75f6"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23026","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()\n\nFix a memory leak in gpi_peripheral_config() where the original memory\npointed to by gchan->config could be lost if krealloc() fails.\n\nThe issue occurs when:\n1. gchan->config points to previously allocated memory\n2. krealloc() fails and returns NULL\n3. The function directly assigns NULL to gchan->config, losing the\n   reference to the original memory\n4. The original memory becomes unreachable and cannot be freed\n\nFix this by using a temporary variable to hold the krealloc() result\nand only updating gchan->config when the allocation succeeds.\n\nFound via static analysis and code review.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00536,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/01b1d781394fc9b83015e3a3cd46b17bda842bd8","https://git.kernel.org/stable/c/3f747004bbd641131d9396d87b5d2d3d1e182728","https://git.kernel.org/stable/c/4532f18e4ab36def1f55cd936d0fc002b2ce34c2","https://git.kernel.org/stable/c/55a67ba5ac4cebfd54cc8305d4d57a0f1dfe6a85","https://git.kernel.org/stable/c/694ab1f6f16cb69f7c5ef2452b22ba7b00a3c7c7","https://git.kernel.org/stable/c/6bf4ef078fd11910988889a6c0b3698d2e0c89af"],"published_time":"2026-01-31T12:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71188","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: lpc18xx-dmamux: fix device leak on route allocation\n\nMake sure to drop the reference taken when looking up the DMA mux\nplatform device during route allocation.\n\nNote that holding a reference to a device does not prevent its driver\ndata from going away so there is no point in keeping the reference.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00536,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1e47d80f6720f0224efd19bcf081d39637569c10","https://git.kernel.org/stable/c/3d396ebfb3049a2b5fac51d2c967db5114b685e8","https://git.kernel.org/stable/c/499ddae78c4baa9b94df76b2d2eb6b150d15377f","https://git.kernel.org/stable/c/992eb8055a6e5dbb808672d20d68e60d5a89b12b","https://git.kernel.org/stable/c/9fba97baa520c9446df51a64708daf27c5a7ed32","https://git.kernel.org/stable/c/adef147a8d8c3d767abf88ad2c381ffab2993086","https://git.kernel.org/stable/c/d4d63059dee7e7cae0c4d9a532ed558bc90efb55"],"published_time":"2026-01-31T12:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71189","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: dw: dmamux: fix OF node leak on route allocation failure\n\nMake sure to drop the reference taken to the DMA master OF node also on\nlate route allocation failures.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.0053,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6b87288581a0fcbe54b39da5c10e1aee2df8776e","https://git.kernel.org/stable/c/8f7a391211381ed2f6802032c78c7820d166bc49","https://git.kernel.org/stable/c/db7c79c1bbfb1b0184e78a17ac2bd0f2bc3134d1","https://git.kernel.org/stable/c/eabe40f8a53c29f531e92778ea243e379f4f7978","https://git.kernel.org/stable/c/ec25e60f9f95464aa11411db31d0906b3fb7b9f2"],"published_time":"2026-01-31T12:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71190","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: bcm-sba-raid: fix device leak on probe\n\nMake sure to drop the reference taken when looking up the mailbox device\nduring probe on probe failures and on driver unbind.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00536,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2ed1a9de1f2d727ccae5bc9cc7c63ee3519c0c8b","https://git.kernel.org/stable/c/4316e4c4fd2c09f68a262365f21847cafa8fe9dd","https://git.kernel.org/stable/c/4730f12a192d7314119b3d8331611ab151b87bdf","https://git.kernel.org/stable/c/7c3a46ebf15a9796b763a54272407fdbf945bed8","https://git.kernel.org/stable/c/bc98e68adfef3b25c06ff08f0808bb59f787420c","https://git.kernel.org/stable/c/c80ca7bdff158401440741bdcf9175bd8608580b","https://git.kernel.org/stable/c/db6f1d6d31711e73e6a214c73e6a8fb4cda0483d"],"published_time":"2026-01-31T12:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71191","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: at_hdmac: fix device leak on of_dma_xlate()\n\nMake sure to drop the reference taken when looking up the DMA platform\ndevice during of_dma_xlate() when releasing channel resources.\n\nNote that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing\nput_device() call in at_dma_xlate()\") fixed the leak in a couple of\nerror paths but the reference is still leaking on successful allocation.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00536,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/48b2d7f530b83cb149dbf0e48f95ccadb2d90da9","https://git.kernel.org/stable/c/49d964cde422dc66fea514b7ab24aa729df7081d","https://git.kernel.org/stable/c/4c67b4f45c8540ee4e62e24ca4608c6a9a81ee0f","https://git.kernel.org/stable/c/6a86cf2c09e149d5718a5b7090545f7566da9334","https://git.kernel.org/stable/c/987c71671367f42460689b78244d7b894c50999a","https://git.kernel.org/stable/c/b9074b2d7a230b6e28caa23165e9d8bc0677d333","https://git.kernel.org/stable/c/f3c23b7e941349505c3d40de2cc0acd93d9ac057"],"published_time":"2026-01-31T12:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23015","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: mpsse: fix reference leak in gpio_mpsse_probe() error paths\n\nThe reference obtained by calling usb_get_dev() is not released in the\ngpio_mpsse_probe() error paths. Fix that by using device managed helper\nfunctions. Also remove the usb_put_dev() call in the disconnect function\nsince now it will be released automatically.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1e876e5a0875e71e34148c9feb2eedd3bf6b2b43","https://git.kernel.org/stable/c/7ea26e6dcabc270433b6ded2a1aee85b215d1b28"],"published_time":"2026-01-31T12:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23016","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: drop fraglist conntrack references\n\nJakub added a warning in nf_conntrack_cleanup_net_list() to make debugging\nleaked skbs/conntrack references more obvious.\n\nsyzbot reports this as triggering, and I can also reproduce this via\nip_defrag.sh selftest:\n\n conntrack cleanup blocked for 60s\n WARNING: net/netfilter/nf_conntrack_core.c:2512\n [..]\n\nconntrack clenups gets stuck because there are skbs with still hold nf_conn\nreferences via their frag_list.\n\n   net.core.skb_defer_max=0 makes the hang disappear.\n\nEric Dumazet points out that skb_release_head_state() doesn't follow the\nfraglist.\n\nip_defrag.sh can only reproduce this problem since\ncommit 6471658dc66c (\"udp: use skb_attempt_defer_free()\"), but AFAICS this\nproblem could happen with TCP as well if pmtu discovery is off.\n\nThe relevant problem path for udp is:\n1. netns emits fragmented packets\n2. nf_defrag_v6_hook reassembles them (in output hook)\n3. reassembled skb is tracked (skb owns nf_conn reference)\n4. ip6_output refragments\n5. refragmented packets also own nf_conn reference (ip6_fragment\n   calls ip6_copy_metadata())\n6. on input path, nf_defrag_v6_hook skips defragmentation: the\n   fragments already have skb->nf_conn attached\n7. skbs are reassembled via ipv6_frag_rcv()\n8. skb_consume_udp -> skb_attempt_defer_free() -> skb ends up\n   in pcpu freelist, but still has nf_conn reference.\n\nPossible solutions:\n 1 let defrag engine drop nf_conn entry, OR\n 2 export kick_defer_list_purge() and call it from the conntrack\n   netns exit callback, OR\n 3 add skb_has_frag_list() check to skb_attempt_defer_free()\n\n2 & 3 also solve ip_defrag.sh hang but share same drawback:\n\nSuch reassembled skbs, queued to socket, can prevent conntrack module\nremoval until userspace has consumed the packet. While both tcp and udp\nstack do call nf_reset_ct() before placing skb on socket queue, that\nfunction doesn't iterate frag_list skbs.\n\nTherefore drop nf_conn entries when they are placed in defrag queue.\nKeep the nf_conn entry of the first (offset 0) skb so that reassembled\nskb retains nf_conn entry for sake of TX path.\n\nNote that fixes tag is incorrect; it points to the commit introducing the\n'ip_defrag.sh reproducible problem': no need to backport this patch to\nevery stable kernel.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/088ca99dbb039c444c3ff987c5412a73f4f0cbf8","https://git.kernel.org/stable/c/2ef02ac38d3c17f34a00c4b267d961a8d4b45d1a"],"published_time":"2026-01-31T12:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71181","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrust_binder: remove spin_lock() in rust_shrink_free_page()\n\nWhen forward-porting Rust Binder to 6.18, I neglected to take commit\nfb56fdf8b9a2 (\"mm/list_lru: split the lock to per-cgroup scope\") into\naccount, and apparently I did not end up running the shrinker callback\nwhen I sanity tested the driver before submission. This leads to crashes\nlike the following:\n\n\t============================================\n\tWARNING: possible recursive locking detected\n\t6.18.0-mainline-maybe-dirty #1 Tainted: G          IO\n\t--------------------------------------------\n\tkswapd0/68 is trying to acquire lock:\n\tffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230\n\n\tbut task is already holding lock:\n\tffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20\n\n\tother info that might help us debug this:\n\t Possible unsafe locking scenario:\n\n\t       CPU0\n\t       ----\n\t  lock(&l->lock);\n\t  lock(&l->lock);\n\n\t *** DEADLOCK ***\n\n\t May be due to missing lock nesting notation\n\n\t3 locks held by kswapd0/68:\n\t #0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160\n\t #1: ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20\n\t #2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230\n\nTo fix this, remove the spin_lock() call from rust_shrink_free_page().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03072,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/30a98c97f7874031f2e1de19c777ce011143cba4","https://git.kernel.org/stable/c/361e0ff456a8daf9753c18030533256e4133ce7a"],"published_time":"2026-01-31T12:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71182","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: make j1939_session_activate() fail if device is no longer registered\n\nsyzbot is still reporting\n\n  unregister_netdevice: waiting for vcan0 to become free. Usage count = 2\n\neven after commit 93a27b5891b8 (\"can: j1939: add missing calls in\nNETDEV_UNREGISTER notification handler\") was added. A debug printk() patch\nfound that j1939_session_activate() can succeed even after\nj1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER)\nhas completed.\n\nSince j1939_cancel_active_session() is processed with the session list lock\nheld, checking ndev->reg_state in j1939_session_activate() with the session\nlist lock held can reliably close the race window.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00536,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/46ca9dc978923c5e1247a9e9519240ba7ace413c","https://git.kernel.org/stable/c/5d5602236f5db19e8b337a2cd87a90ace5ea776d","https://git.kernel.org/stable/c/78d87b72cebe2a993fd5b017e9f14fb6278f2eae","https://git.kernel.org/stable/c/79dd3f1d9dd310c2af89b09c71f34d93973b200f","https://git.kernel.org/stable/c/ba6f0d1832eeb5eb3a6dc5cb30e0f720b3cb3536","https://git.kernel.org/stable/c/c3a4316e3c746af415c0fd6c6d489ad13f53714d","https://git.kernel.org/stable/c/ebb0dfd718dd31c8d3600612ca4b7207ec3d923a"],"published_time":"2026-01-31T12:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71183","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: always detect conflicting inodes when logging inode refs\n\nAfter rename exchanging (either with the rename exchange operation or\nregular renames in multiple non-atomic steps) two inodes and at least\none of them is a directory, we can end up with a log tree that contains\nonly of the inodes and after a power failure that can result in an attempt\nto delete the other inode when it should not because it was not deleted\nbefore the power failure. In some case that delete attempt fails when\nthe target inode is a directory that contains a subvolume inside it, since\nthe log replay code is not prepared to deal with directory entries that\npoint to root items (only inode items).\n\n1) We have directories \"dir1\" (inode A) and \"dir2\" (inode B) under the\n   same parent directory;\n\n2) We have a file (inode C) under directory \"dir1\" (inode A);\n\n3) We have a subvolume inside directory \"dir2\" (inode B);\n\n4) All these inodes were persisted in a past transaction and we are\n   currently at transaction N;\n\n5) We rename the file (inode C), so at btrfs_log_new_name() we update\n   inode C's last_unlink_trans to N;\n\n6) We get a rename exchange for \"dir1\" (inode A) and \"dir2\" (inode B),\n   so after the exchange \"dir1\" is inode B and \"dir2\" is inode A.\n   During the rename exchange we call btrfs_log_new_name() for inodes\n   A and B, but because they are directories, we don't update their\n   last_unlink_trans to N;\n\n7) An fsync against the file (inode C) is done, and because its inode\n   has a last_unlink_trans with a value of N we log its parent directory\n   (inode A) (through btrfs_log_all_parents(), called from\n   btrfs_log_inode_parent()).\n\n8) So we end up with inode B not logged, which now has the old name\n   of inode A. At copy_inode_items_to_log(), when logging inode A, we\n   did not check if we had any conflicting inode to log because inode\n   A has a generation lower than the current transaction (created in\n   a past transaction);\n\n9) After a power failure, when replaying the log tree, since we find that\n   inode A has a new name that conflicts with the name of inode B in the\n   fs tree, we attempt to delete inode B... this is wrong since that\n   directory was never deleted before the power failure, and because there\n   is a subvolume inside that directory, attempting to delete it will fail\n   since replay_dir_deletes() and btrfs_unlink_inode() are not prepared\n   to deal with dir items that point to roots instead of inodes.\n\n   When that happens the mount fails and we get a stack trace like the\n   following:\n\n   [87.2314] BTRFS info (device dm-0): start tree-log replay\n   [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259\n   [87.2332] ------------[ cut here ]------------\n   [87.2338] BTRFS: Transaction aborted (error -2)\n   [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs]\n   [87.2368] Modules linked in: btrfs loop dm_thin_pool (...)\n   [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G        W           6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full)\n   [87.2489] Tainted: [W]=WARN\n   [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\n   [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs]\n   [87.2538] Code: c0 89 04 24 (...)\n   [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286\n   [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000\n   [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff\n   [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840\n   [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0\n   [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10\n   [87.2618] FS:  00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000\n   [87.\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":9e-05,"ranking_epss":0.00905,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0c2413c69129f6ce60157f7b53d9ba880260400b","https://git.kernel.org/stable/c/7ba0b6461bc4edb3005ea6e00cdae189bcf908a5","https://git.kernel.org/stable/c/a63998cd6687c14b160dccb0bbcf281b2eb0dab3","https://git.kernel.org/stable/c/c7f0207db68d5a1b4af23acbef1a8e8ddc431ebb","https://git.kernel.org/stable/c/d52af58dd463821c5c516aebb031a58934f696ea"],"published_time":"2026-01-31T12:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71184","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix NULL dereference on root when tracing inode eviction\n\nWhen evicting an inode the first thing we do is to setup tracing for it,\nwhich implies fetching the root's id. But in btrfs_evict_inode() the\nroot might be NULL, as implied in the next check that we do in\nbtrfs_evict_inode().\n\nHence, we either should set the ->root_objectid to 0 in case the root is\nNULL, or we move tracing setup after checking that the root is not\nNULL. Setting the rootid to 0 at least gives us the possibility to trace\nthis call even in the case when the root is NULL, so that's the solution\ntaken here.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02993,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/582ba48e4a4c06fef6bdcf4e57b7b9af660bbd0c","https://git.kernel.org/stable/c/64d8abd8c5305795a2b35fc96039d99d34f5e762","https://git.kernel.org/stable/c/99e057f3d3ef24b99a7b1d84e01dd1bd890098da","https://git.kernel.org/stable/c/f157dd661339fc6f5f2b574fe2429c43bd309534"],"published_time":"2026-01-31T12:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71185","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: dma-crossbar: fix device leak on am335x route allocation\n\nMake sure to drop the reference taken when looking up the crossbar\nplatform device during am335x route allocation.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00536,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1befa553f1ecc045dc9ff56107ff50162f63f3c0","https://git.kernel.org/stable/c/30352277d8e09c972436f883a5efd1f1b763ac14","https://git.kernel.org/stable/c/43725bd47d984937c429919ae291896d982d1f17","https://git.kernel.org/stable/c/4fc17b1c6d2e04ad13fd6c21cfbac68043ec03f9","https://git.kernel.org/stable/c/6fdf168f57e331e148a1177a9b590a845c21b315","https://git.kernel.org/stable/c/c933aa74d9f8d35e6cda322c38c4a907d37a9a2b","https://git.kernel.org/stable/c/f810132e825588fbad3cba940458c58bb7ec4d84"],"published_time":"2026-01-31T12:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71186","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: stm32: dmamux: fix device leak on route allocation\n\nMake sure to drop the reference taken when looking up the DMA mux\nplatform device during route allocation.\n\nNote that holding a reference to a device does not prevent its driver\ndata from going away so there is no point in keeping the reference.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00536,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1a179ac01ff3993ab97e33cc77c316ed7415cda1","https://git.kernel.org/stable/c/1dda2a32303df0091896b01a9d09070d61fa344c","https://git.kernel.org/stable/c/2fb10259d4efb4367787b5ae9c94192e8a91c648","https://git.kernel.org/stable/c/3b42020e6790a5e19b36c187ed5b488a5716f97f","https://git.kernel.org/stable/c/3ef52d31cce8ba816739085a61efe07b63c6cf27","https://git.kernel.org/stable/c/6393da54dcb3488c080a183c4182ddec71ba8d7f","https://git.kernel.org/stable/c/dd6e4943889fb354efa3f700e42739da9bddb6ef"],"published_time":"2026-01-31T12:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71187","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: sh: rz-dmac: fix device leak on probe failure\n\nMake sure to drop the reference taken when looking up the ICU device\nduring probe also on probe failures (e.g. probe deferral).","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":8e-05,"ranking_epss":0.00673,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/926d1666420c227eab50962a8622c1b8444720e8","https://git.kernel.org/stable/c/9fb490323997dcb6f749cd2660a17a39854600cd"],"published_time":"2026-01-31T12:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71180","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncounter: interrupt-cnt: Drop IRQF_NO_THREAD flag\n\nAn IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as\nCONFIG_PROVE_RAW_LOCK_NESTING warns:\n=============================\n[ BUG: Invalid wait context ]\n6.18.0-rc1+git... #1\n-----------------------------\nsome-user-space-process/1251 is trying to lock:\n(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]\nother info that might help us debug this:\ncontext-{2:2}\nno locks held by some-user-space-process/....\nstack backtrace:\nCPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT\nCall trace:\n show_stack (C)\n dump_stack_lvl\n dump_stack\n __lock_acquire\n lock_acquire\n _raw_spin_lock_irqsave\n counter_push_event [counter]\n interrupt_cnt_isr [interrupt_cnt]\n __handle_irq_event_percpu\n handle_irq_event\n handle_simple_irq\n handle_irq_desc\n generic_handle_domain_irq\n gpio_irq_handler\n handle_irq_desc\n generic_handle_domain_irq\n gic_handle_irq\n call_on_irq_stack\n do_interrupt_handler\n el0_interrupt\n __el0_irq_handler_common\n el0t_64_irq_handler\n el0t_64_irq\n\n... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an\nalternative to switching to raw_spinlock_t, because the latter would limit\nall potential nested locks to raw_spinlock_t only.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03212,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1c5a3175aecf82cd86dfcbef2a23e8b26d8d8e7c","https://git.kernel.org/stable/c/23f9485510c338476b9735d516c1d4aacb810d46","https://git.kernel.org/stable/c/425886b1f8304621b3f16632b274357067d5f13f","https://git.kernel.org/stable/c/49a66829dd3653695e60d7cae13521d131362fcd","https://git.kernel.org/stable/c/51d2e5d6491447258cb39ff1deb93df15d3c23cb","https://git.kernel.org/stable/c/ef668c9a2261ec9287faba6e6ef05a98b391aa2b"],"published_time":"2026-01-31T12:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-24687","summary":"Umbraco Forms is a form builder that integrates with the Umbraco content management system. It's possible for an authenticated backoffice-user to enumerate and traverse paths/files on the systems filesystem and read their contents, on Mac/Linux Umbraco installations using Forms. As Umbraco Cloud runs in a Windows environment, Cloud users aren't affected. This issue affects versions 16 and 17 of Umbraco Forms and is patched in 16.4.1 and 17.1.1. If upgrading is not immediately possible, users can mitigate this vulnerability by configuring a WAF or reverse proxy to block requests containing path traversal sequences (`../`, `..\\`) in the `fileName` parameter of the export endpoint, restricting network access to the Umbraco backoffice to trusted IP ranges, and/or blocking the `/umbraco/forms/api/v1/export` endpoint entirely if the export feature is not required. However, upgrading to the patched version is strongly recommended.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.0002,"ranking_epss":0.05265,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/umbraco/Umbraco.Forms.Issues/security/advisories/GHSA-hm5p-82g6-m3xh"],"published_time":"2026-01-29T20:16:10","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23014","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Ensure swevent hrtimer is properly destroyed\n\nWith the change to hrtimer_try_to_cancel() in\nperf_swevent_cancel_hrtimer() it appears possible for the hrtimer to\nstill be active by the time the event gets freed.\n\nMake sure the event does a full hrtimer_cancel() on the free path by\ninstalling a perf_event::destroy handler.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03908,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/deee9dfb111ab00f9dfd46c0c7e36656b80f5235","https://git.kernel.org/stable/c/ff5860f5088e9076ebcccf05a6ca709d5935cfa9"],"published_time":"2026-01-28T15:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23012","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/core: remove call_control in inactive contexts\n\nIf damon_call() is executed against a DAMON context that is not running,\nthe function returns error while keeping the damon_call_control object\nlinked to the context's call_controls list.  Let's suppose the object is\ndeallocated after the damon_call(), and yet another damon_call() is\nexecuted against the same context.  The function tries to add the new\ndamon_call_control object to the call_controls list, which still has the\npointer to the previous damon_call_control object, which is deallocated. \nAs a result, use-after-free happens.\n\nThis can actually be triggered using the DAMON sysfs interface.  It is not\neasily exploitable since it requires the sysfs write permission and making\na definitely weird file writes, though.  Please refer to the report for\nmore details about the issue reproduction steps.\n\nFix the issue by making two changes.  Firstly, move the final\nkdamond_call() for cancelling all existing damon_call() requests from\nterminating DAMON context to be done before the ctx->kdamond reset.  This\nmakes any code that sees NULL ctx->kdamond can safely assume the context\nmay not access damon_call() requests anymore.  Secondly, let damon_call()\nto cleanup the damon_call_control objects that were added to the\nalready-terminated DAMON context, before returning the error.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00019,"ranking_epss":0.05102,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/23b061f421eef03647b512f3df48861706c87db3","https://git.kernel.org/stable/c/f9132fbc2e83baf2c45a77043672a63a675c9394"],"published_time":"2026-01-25T15:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23013","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollback\n\noctep_vf_request_irqs() requests MSI-X queue IRQs with dev_id set to\nioq_vector. If request_irq() fails part-way, the rollback loop calls\nfree_irq() with dev_id set to 'oct', which does not match the original\ndev_id and may leave the irqaction registered.\n\nThis can keep IRQ handlers alive while ioq_vector is later freed during\nunwind/teardown, leading to a use-after-free or crash when an interrupt\nfires.\n\nFix the error path to free IRQs with the same ioq_vector dev_id used\nduring request_irq().","cvss":7.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.0,"epss":0.00017,"ranking_epss":0.04296,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/aa05a8371ae4a452df623f7202c72409d3c50e40","https://git.kernel.org/stable/c/aa4c066229b05fc3d3c5f42693d25b1828533b6e","https://git.kernel.org/stable/c/f93fc5d12d69012788f82151bee55fce937e1432"],"published_time":"2026-01-25T15:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23002","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlib/buildid: use __kernel_read() for sleepable context\n\nPrevent a \"BUG: unable to handle kernel NULL pointer dereference in\nfilemap_read_folio\".\n\nFor the sleepable context, convert freader to use __kernel_read() instead\nof direct page cache access via read_cache_folio().  This simplifies the\nfaultable code path by using the standard kernel file reading interface\nwhich handles all the complexity of reading file data.\n\nAt the moment we are not changing the code for non-sleepable context which\nuses filemap_get_folio() and only succeeds if the target folios are\nalready in memory and up-to-date.  The reason is to keep the patch simple\nand easier to backport to stable kernels.\n\nSyzbot repro does not crash the kernel anymore and the selftests run\nsuccessfully.\n\nIn the follow up we will make __kernel_read() with IOCB_NOWAIT work for\nnon-sleepable contexts.  In addition, I would like to replace the\nsecretmem check with a more generic approach and will add fstest for the\nbuildid code.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/568aeb3476c770a3863c755dd2a199c212434286","https://git.kernel.org/stable/c/777a8560fd29738350c5094d4166fe5499452409","https://git.kernel.org/stable/c/b11dfb7708f212b96c7973a474014c071aa02e05"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23003","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()\n\nBlamed commit did not take care of VLAN encapsulations\nas spotted by syzbot [1].\n\nUse skb_vlan_inet_prepare() instead of pskb_inet_may_pull().\n\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321\n  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n  IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321\n  ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729\n  __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860\n  ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903\n gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1\n  ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438\n  ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n  ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500\n  ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590\n  dst_input include/net/dst.h:474 [inline]\n  ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n  ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311\n  __netif_receive_skb_one_core net/core/dev.c:6139 [inline]\n  __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252\n  netif_receive_skb_internal net/core/dev.c:6338 [inline]\n  netif_receive_skb+0x57/0x630 net/core/dev.c:6397\n  tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485\n  tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953\n  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999\n  new_sync_write fs/read_write.c:593 [inline]\n  vfs_write+0xbe2/0x15d0 fs/read_write.c:686\n  ksys_write fs/read_write.c:738 [inline]\n  __do_sys_write fs/read_write.c:749 [inline]\n  __se_sys_write fs/read_write.c:746 [inline]\n  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746\n  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:4960 [inline]\n  slab_alloc_node mm/slub.c:5263 [inline]\n  kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315\n  kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586\n  __alloc_skb+0x805/0x1040 net/core/skbuff.c:690\n  alloc_skb include/linux/skbuff.h:1383 [inline]\n  alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712\n  sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995\n  tun_alloc_skb drivers/net/tun.c:1461 [inline]\n  tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794\n  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999\n  new_sync_write fs/read_write.c:593 [inline]\n  vfs_write+0xbe2/0x15d0 fs/read_write.c:686\n  ksys_write fs/read_write.c:738 [inline]\n  __do_sys_write fs/read_write.c:749 [inline]\n  __se_sys_write fs/read_write.c:746 [inline]\n  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746\n  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00011,"ranking_epss":0.01197,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2f03dafea0a8096a2eb60f551218b360e5bab9a3","https://git.kernel.org/stable/c/64c71d60a21a9ed0a802483dcd422b5b24eb1abe","https://git.kernel.org/stable/c/81c734dae203757fb3c9eee6f9896386940776bd","https://git.kernel.org/stable/c/9e1c8c2a33d0a7b1f637b5d0602fe56ed10166af","https://git.kernel.org/stable/c/b9f915340f25cae1562f18e1eb52deafca328414","https://git.kernel.org/stable/c/df5ffde9669314500809bc498ae73d6d3d9519ac","https://git.kernel.org/stable/c/f9c5c5b791d3850570796f9e067629474e613796"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23004","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()\n\nsyzbot was able to crash the kernel in rt6_uncached_list_flush_dev()\nin an interesting way [1]\n\nCrash happens in list_del_init()/INIT_LIST_HEAD() while writing\nlist->prev, while the prior write on list->next went well.\n\nstatic inline void INIT_LIST_HEAD(struct list_head *list)\n{\n\tWRITE_ONCE(list->next, list); // This went well\n\tWRITE_ONCE(list->prev, list); // Crash, @list has been freed.\n}\n\nIssue here is that rt6_uncached_list_del() did not attempt to lock\nul->lock, as list_empty(&rt->dst.rt_uncached) returned\ntrue because the WRITE_ONCE(list->next, list) happened on the other CPU.\n\nWe might use list_del_init_careful() and list_empty_careful(),\nor make sure rt6_uncached_list_del() always grabs the spinlock\nwhenever rt->dst.rt_uncached_list has been set.\n\nA similar fix is neeed for IPv4.\n\n[1]\n\n BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline]\n BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline]\n BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]\n BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020\nWrite of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450\n\nCPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G             L      syzkaller #0 PREEMPT_{RT,(full)}\nTainted: [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nWorkqueue: netns cleanup_net\nCall Trace:\n <TASK>\n  dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n  print_address_description mm/kasan/report.c:378 [inline]\n  print_report+0xca/0x240 mm/kasan/report.c:482\n  kasan_report+0x118/0x150 mm/kasan/report.c:595\n  INIT_LIST_HEAD include/linux/list.h:46 [inline]\n  list_del_init include/linux/list.h:296 [inline]\n  rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]\n  rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020\n  addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853\n addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1\n  notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85\n  call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]\n  call_netdevice_notifiers net/core/dev.c:2282 [inline]\n  netif_close_many+0x29c/0x410 net/core/dev.c:1785\n  unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353\n  ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]\n  ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248\n  cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696\n  process_one_work kernel/workqueue.c:3257 [inline]\n  process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n  kthread+0x711/0x8a0 kernel/kthread.c:463\n  ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n </TASK>\n\nAllocated by task 803:\n  kasan_save_stack mm/kasan/common.c:57 [inline]\n  kasan_save_track+0x3e/0x80 mm/kasan/common.c:78\n  unpoison_slab_object mm/kasan/common.c:340 [inline]\n  __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366\n  kasan_slab_alloc include/linux/kasan.h:253 [inline]\n  slab_post_alloc_hook mm/slub.c:4953 [inline]\n  slab_alloc_node mm/slub.c:5263 [inline]\n  kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270\n  dst_alloc+0x105/0x170 net/core/dst.c:89\n  ip6_dst_alloc net/ipv6/route.c:342 [inline]\n  icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333\n  mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844\n  mld_send_cr net/ipv6/mcast.c:2154 [inline]\n  mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693\n  process_one_work kernel/workqueue.c:3257 [inline]\n  process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n  kthread+0x711/0x8a0 kernel/kthread.c:463\n  ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr\n---truncated---","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00013,"ranking_epss":0.02284,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/722de945216144af7cd4d39bdeb936108d2595a7","https://git.kernel.org/stable/c/815db2363e51f0ef416947492d4dac5b7a520f56","https://git.kernel.org/stable/c/9a6f0c4d5796ab89b5a28a890ce542344d58bd69","https://git.kernel.org/stable/c/f24a52948c95e02facbca2b3b6eb5a225e27eb01"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23005","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1\n\nWhen loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in\nresponse to a guest WRMSR, clear XFD-disabled features in the saved (or to\nbe restored) XSTATE_BV to ensure KVM doesn't attempt to load state for\nfeatures that are disabled via the guest's XFD.  Because the kernel\nexecutes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1\nwill cause XRSTOR to #NM and panic the kernel.\n\nE.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:\n\n  ------------[ cut here ]------------\n  WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848\n  Modules linked in: kvm_intel kvm irqbypass\n  CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:exc_device_not_available+0x101/0x110\n  Call Trace:\n   <TASK>\n   asm_exc_device_not_available+0x1a/0x20\n  RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n   switch_fpu_return+0x4a/0xb0\n   kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]\n   kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n   __x64_sys_ioctl+0x8f/0xd0\n   do_syscall_64+0x62/0x940\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n\nThis can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,\nand a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's\ncall to fpu_update_guest_xfd().\n\nand if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:\n\n  ------------[ cut here ]------------\n  WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867\n  Modules linked in: kvm_intel kvm irqbypass\n  CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:exc_device_not_available+0x101/0x110\n  Call Trace:\n   <TASK>\n   asm_exc_device_not_available+0x1a/0x20\n  RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n   fpu_swap_kvm_fpstate+0x6b/0x120\n   kvm_load_guest_fpu+0x30/0x80 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]\n   kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n   __x64_sys_ioctl+0x8f/0xd0\n   do_syscall_64+0x62/0x940\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n\nThe new behavior is consistent with the AMX architecture.  Per Intel's SDM,\nXSAVE saves XSTATE_BV as '0' for components that are disabled via XFD\n(and non-compacted XSAVE saves the initial configuration of the state\ncomponent):\n\n  If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,\n  the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;\n  instead, it operates as if XINUSE[i] = 0 (and the state component was\n  in its initial state): it saves bit i of XSTATE_BV field of the XSAVE\n  header as 0; in addition, XSAVE saves the initial configuration of the\n  state component (the other instructions do not save state component i).\n\nAlternatively, KVM could always do XRSTOR with XFD=0, e.g. by using\na constant XFD based on the set of enabled features when XSAVEing for\na struct fpu_guest.  However, having XSTATE_BV[i]=1 for XFD-disabled\nfeatures can only happen in the above interrupt case, or in similar\nscenarios involving preemption on preemptible kernels, because\nfpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the\noutgoing FPU state with the current XFD; and that is (on all but the\nfirst WRMSR to XFD) the guest XFD.\n\nTherefore, XFD can only go out of sync with XSTATE_BV in the above\ninterrupt case, or in similar scenarios involving preemption on\npreemptible kernels, and it we can consider it (de facto) part of KVM\nABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.\n\n[Move clea\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00011,"ranking_epss":0.01188,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1e2848bda819af569dfe7ab186223855e092a2cb","https://git.kernel.org/stable/c/b45f721775947a84996deb5c661602254ce25ce6","https://git.kernel.org/stable/c/b5995c01ba53d84182ecb9492fc4d91cfe8a362d","https://git.kernel.org/stable/c/eea6f395ca502c4528314c8112da9b5d65f685eb","https://git.kernel.org/stable/c/f577508cc8a0adb8b4ebe9480bba7683b6149930"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23006","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: tlv320adcx140: fix null pointer\n\nThe \"snd_soc_component\" in \"adcx140_priv\" was only used once but never\nset. It was only used for reaching \"dev\" which is already present in\n\"adcx140_priv\".","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":8e-05,"ranking_epss":0.00728,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/53bd838ed5950cb18927e4b2e8ee841b7cb10929","https://git.kernel.org/stable/c/61757f5191daab863d25f03680e912b5449a1eed","https://git.kernel.org/stable/c/659939d08e5f7bc17b941c53e8c9c0a6c6113b21","https://git.kernel.org/stable/c/954260a32c21d5072d8e7253c0a8b1627927cb02","https://git.kernel.org/stable/c/be7664c81d3129fc313ef62ff275fd3d33cfecd4"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23007","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nblock: zero non-PI portion of auto integrity buffer\n\nThe auto-generated integrity buffer for writes needs to be fully\ninitialized before being passed to the underlying block device,\notherwise the uninitialized memory can be read back by userspace or\nanyone with physical access to the storage device. If protection\ninformation is generated, that portion of the integrity buffer is\nalready initialized. The integrity data is also zeroed if PI generation\nis disabled via sysfs or the PI tuple size is 0. However, this misses\nthe case where PI is generated and the PI tuple size is nonzero, but the\nmetadata size is larger than the PI tuple. In this case, the remainder\n(\"opaque\") of the metadata is left uninitialized.\nGeneralize the BLK_INTEGRITY_CSUM_NONE check to cover any case when the\nmetadata is larger than just the PI tuple.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/ca22c566b89164f6e670af56ecc45f47ef3df819","https://git.kernel.org/stable/c/d6072557b90e0c557df319a56f4a9dc482706d2c"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23008","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix KMS with 3D on HW version 10\n\nHW version 10 does not have GB Surfaces so there is no backing buffer for\nsurface backed FBs. This would result in a nullptr dereference and crash\nthe driver causing a black screen.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/a91bdd21d5efb3072beefbec13762b7722200c49","https://git.kernel.org/stable/c/d9186faeae6efb7d0841a5e8eb213ff4c7966614"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23009","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nxhci: sideband: don't dereference freed ring when removing sideband endpoint\n\nxhci_sideband_remove_endpoint() incorrecly assumes that the endpoint is\nrunning and has a valid transfer ring.\n\nLianqin reported a crash during suspend/wake-up stress testing, and\nfound the cause to be dereferencing a non-existing transfer ring\n'ep->ring' during xhci_sideband_remove_endpoint().\n\nThe endpoint and its ring may be in unknown state if this function\nis called after xHCI was reinitialized in resume (lost power), or if\ndevice is being re-enumerated, disconnected or endpoint already dropped.\n\nFix this by both removing unnecessary ring access, and by checking\nep->ring exists before dereferencing it. Also make sure endpoint is\nrunning before attempting to stop it.\n\nRemove the xhci_initialize_ring_info() call during sideband endpoint\nremoval as is it only initializes ring structure enqueue, dequeue and\ncycle state values to their starting values without changing actual\nhardware enqueue, dequeue and cycle state. Leaving them out of sync\nis worse than leaving it as it is. The endpoint will get freed in after\nthis in most usecases.\n\nIf the (audio) class driver want's to reuse the endpoint after offload\nthen it is up to the class driver to ensure endpoint is properly set up.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/34f6634dba87ef72b3c3a3a524be663adef7ab42","https://git.kernel.org/stable/c/dd83dc1249737b837ac5d57c81f2b0977c613d9f"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23010","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix use-after-free in inet6_addr_del().\n\nsyzbot reported use-after-free of inet6_ifaddr in\ninet6_addr_del(). [0]\n\nThe cited commit accidentally moved ipv6_del_addr() for\nmngtmpaddr before reading its ifp->flags for temporary\naddresses in inet6_addr_del().\n\nLet's move ipv6_del_addr() down to fix the UAF.\n\n[0]:\nBUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117\nRead of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593\n\nCPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117\n addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181\n inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582\n sock_do_ioctl+0x118/0x280 net/socket.c:1254\n sock_ioctl+0x227/0x6b0 net/socket.c:1375\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f164cf8f749\nCode: 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\nRSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749\nRDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003\nRBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288\n </TASK>\n\nAllocated by task 9593:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:56\n kasan_save_track+0x14/0x30 mm/kasan/common.c:77\n poison_kmalloc_redzone mm/kasan/common.c:397 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414\n kmalloc_noprof include/linux/slab.h:957 [inline]\n kzalloc_noprof include/linux/slab.h:1094 [inline]\n ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120\n inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050\n addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160\n inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580\n sock_do_ioctl+0x118/0x280 net/socket.c:1254\n sock_ioctl+0x227/0x6b0 net/socket.c:1375\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 6099:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:56\n kasan_save_track+0x14/0x30 mm/kasan/common.c:77\n kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584\n poison_slab_object mm/kasan/common.c:252 [inline]\n __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284\n kasan_slab_free include/linux/kasan.h:234 [inline]\n slab_free_hook mm/slub.c:2540 [inline]\n slab_free_freelist_hook mm/slub.c:2569 [inline]\n slab_free_bulk mm/slub.c:6696 [inline]\n kmem_cache_free_bulk mm/slub.c:7383 [inline]\n kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362\n kfree_bulk include/linux/slab.h:830 [inline]\n kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523\n kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline]\n kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801\n process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257\n process_scheduled_works kernel/workqu\n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":9e-05,"ranking_epss":0.00926,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2684610a9c9c53f262fd864fa5c407e79f304804","https://git.kernel.org/stable/c/6e89d60b4f03014f7d412ce64b17a840840d490e","https://git.kernel.org/stable/c/8b6dcb565e419846bd521e31d5e1f98e4d0e1179","https://git.kernel.org/stable/c/9356b69d03d0f50cce91cebdabd33dda023fbd64","https://git.kernel.org/stable/c/ddf96c393a33aef4887e2e406c76c2f8cda1419c"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23011","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: ip_gre: make ipgre_header() robust\n\nAnalog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\")\n\nOver the years, syzbot found many ways to crash the kernel\nin ipgre_header() [1].\n\nThis involves team or bonding drivers ability to dynamically\nchange their dev->needed_headroom and/or dev->hard_header_len\n\nIn this particular crash mld_newpack() allocated an skb\nwith a too small reserve/headroom, and by the time mld_sendpack()\nwas called, syzbot managed to attach an ipgre device.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0\n kernel BUG at net/core/skbuff.c:213 !\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nWorkqueue: mld mld_ifc_work\n RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213\nCall Trace:\n <TASK>\n  skb_under_panic net/core/skbuff.c:223 [inline]\n  skb_push+0xc3/0xe0 net/core/skbuff.c:2641\n  ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897\n  dev_hard_header include/linux/netdevice.h:3436 [inline]\n  neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618\n  NF_HOOK_COND include/linux/netfilter.h:307 [inline]\n  ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247\n  NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318\n  mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855\n  mld_send_cr net/ipv6/mcast.c:2154 [inline]\n  mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693\n  process_one_work kernel/workqueue.c:3257 [inline]\n  process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n  kthread+0x711/0x8a0 kernel/kthread.c:463\n  ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00011,"ranking_epss":0.01197,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/06fe0801396a36cab865b34f666de1d65bc5ce8e","https://git.kernel.org/stable/c/2ecf0aa7cc262472a9599cc51ba02ada0897a17a","https://git.kernel.org/stable/c/554201ed0a8f4d32e719f42caeaeb2735a9ed6ca","https://git.kernel.org/stable/c/8d5b6b2d79c1c22a5b0db1187a6439dff375a022","https://git.kernel.org/stable/c/aa57bfea4674e6da8104fa3a37760a6f5f255dad","https://git.kernel.org/stable/c/e67c577d89894811ce4dcd1a9ed29d8b63476667","https://git.kernel.org/stable/c/eeb9a521de40c6fadccc12fa5205e5a1b364d5a8"],"published_time":"2026-01-25T15:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71163","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: fix device leaks on compat bind and unbind\n\nMake sure to drop the reference taken when looking up the idxd device as\npart of the compat bind and unbind sysfs interface.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":8e-05,"ranking_epss":0.00732,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0c97ff108f825a70c3bb29d65ddf0a013d231bb9","https://git.kernel.org/stable/c/799900f01792cf8b525a44764f065f83fcafd468","https://git.kernel.org/stable/c/a7226fd61def74b60dd8e47ec84cabafc39d575b","https://git.kernel.org/stable/c/b2d077180a56e3b7c97b7517d0465b584adc693b","https://git.kernel.org/stable/c/b7bd948f89271c92d9ca9b2b682bfba56896e959","https://git.kernel.org/stable/c/c81ea0222eaaafdd77348e27d1e84a1b8cfc0c99"],"published_time":"2026-01-25T15:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22996","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails, mlx5e_priv in mlx5e_dev devlink private is used to\nreference the netdev and mdev associated with that struct. Instead,\nstore netdev directly into mlx5e_dev and get mdev from the containing\nmlx5_adev aux device structure.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==> oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000520\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_remove+0x68/0x130\nRSP: 0018:ffffc900034838f0 EFLAGS: 00010246\nRAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\nRBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10\nR10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0\nR13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400\nFS:  00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0\nCall Trace:\n <TASK>\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/123eda2e5b1638e298e3a66bb1e64a8da92de5e1","https://git.kernel.org/stable/c/a3d4f87d41f5140f1cf5c02fce5cdad2637f6244","https://git.kernel.org/stable/c/dcb2ad755a16cb0ecd2dc98234d71a6e216ae7fe"],"published_time":"2026-01-25T15:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22997","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts\n\nSince j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is\ncalled only when the timer is enabled, we need to call\nj1939_session_deactivate_activate_next() if we cancelled the timer.\nOtherwise, refcount for j1939_session leaks, which will later appear as\n\n| unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.\n\nproblem.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":8e-05,"ranking_epss":0.00732,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1809c82aa073a11b7d335ae932d81ce51a588a4a","https://git.kernel.org/stable/c/6121b7564c725b632ffe4764abe85aa239d37703","https://git.kernel.org/stable/c/809a437e27a3bf3c1c6c8c157773635552116f2b","https://git.kernel.org/stable/c/a73e7d7e346dae1c22dc3e95b02ca464b12daf2c","https://git.kernel.org/stable/c/adabf01c19561e42899da9de56a6a1da0e6b8a5b","https://git.kernel.org/stable/c/b1d67607e97d489c0cfbbf55f48a76b00710b0e4","https://git.kernel.org/stable/c/cb2a610867bc379988bae0bb4b8bbc59c0decf1a"],"published_time":"2026-01-25T15:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22998","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\")\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command's data structures (cmd->req.sg and cmd->iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT → both pointers NULL\n2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL\n3. H2C_DATA PDU for uninitialized command slot → both pointers NULL\n\nThe fix validates both cmd->req.sg and cmd->iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd->req.sg allocated, cmd->iov NULL\n- WRITE commands: both allocated","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00046,"ranking_epss":0.14215,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/32b63acd78f577b332d976aa06b56e70d054cbba","https://git.kernel.org/stable/c/374b095e265fa27465f34780e0eb162ff1bef913","https://git.kernel.org/stable/c/3def5243150716be86599c2a1767c29c68838b6d","https://git.kernel.org/stable/c/76abc83a9d25593c2b7613c549413079c14a4686","https://git.kernel.org/stable/c/7d75570002929d20e40110d6b03e46202c9d1bc7","https://git.kernel.org/stable/c/baabe43a0edefac8cd7b981ff87f967f6034dafe","https://git.kernel.org/stable/c/fdecd3b6aac10d5a18d0dc500fe57f8648b66cd4"],"published_time":"2026-01-25T15:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22999","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: do not free existing class in qfq_change_class()\n\nFixes qfq_change_class() error case.\n\ncl->qdisc and cl should only be freed if a new class and qdisc\nwere allocated, or we risk various UAF.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00011,"ranking_epss":0.01197,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0a234660dc70ce45d771cbc76b20d925b73ec160","https://git.kernel.org/stable/c/2a64fb9b47afffeb5dbab5fd3a518e1436dcc90e","https://git.kernel.org/stable/c/362e269bb03f7076ba9990e518aeddb898232e50","https://git.kernel.org/stable/c/3879cffd9d07aa0377c4b8835c4f64b4fb24ac78","https://git.kernel.org/stable/c/cff6cd703f41d8071995956142729e4bba160363","https://git.kernel.org/stable/c/e9d8f11652fa08c647bf7bba7dd8163241a332cd","https://git.kernel.org/stable/c/f06f7635499bc806cbe2bbc8805c7cef8b1edddf"],"published_time":"2026-01-25T15:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23000","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash on profile change rollback failure\n\nmlx5e_netdev_change_profile can fail to attach a new profile and can\nfail to rollback to old profile, in such case, we could end up with a\ndangling netdev with a fully reset netdev_priv. A retry to change\nprofile, e.g. another attempt to call mlx5e_netdev_change_profile via\nswitchdev mode change, will crash trying to access the now NULL\npriv->mdev.\n\nThis fix allows mlx5e_netdev_change_profile() to handle previous\nfailures and an empty priv, by not assuming priv is valid.\n\nPass netdev and mdev to all flows requiring\nmlx5e_netdev_change_profile() and avoid passing priv.\nIn mlx5e_netdev_change_profile() check if current priv is valid, and if\nnot, just attach the new profile without trying to access the old one.\n\nThis fixes the following oops, when enabling switchdev mode for the 2nd\ntime after first time failure:\n\n ## Enabling switchdev mode first time:\n\nmlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload\nworkqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n                                                                         ^^^^^^^^\nmlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\n\n ## retry: Enabling switchdev mode 2nd time:\n\nmlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload\nBUG: kernel NULL pointer dereference, address: 0000000000000038\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_detach_netdev+0x3c/0x90\nCode: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07\nRSP: 0018:ffffc90000673890 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000\nRDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000\nR10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000\nR13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000\nFS:  00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0\nCall Trace:\n <TASK>\n mlx5e_netdev_change_profile+0x45/0xb0\n mlx5e_vport_rep_load+0x27b/0x2d0\n mlx5_esw_offloads_rep_load+0x72/0xf0\n esw_offloads_enable+0x5d0/0x970\n mlx5_eswitch_enable_locked+0x349/0x430\n ? is_mp_supported+0x57/0xb0\n mlx5_devlink_eswitch_mode_set+0x26b/0x430\n devlink_nl_eswitch_set_doit+0x6f/0xf0\n genl_family_rcv_msg_doit+0xe8/0x140\n genl_rcv_msg+0x18b/0x290\n ? __pfx_devlink_nl_pre_doit+0x10/0x10\n ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10\n ? __pfx_devlink_nl_post_doit+0x10/0x10\n ? __pfx_genl_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x52/0x100\n genl_rcv+0x28/0x40\n netlink_unicast+0x282/0x3e0\n ? __alloc_skb+0xd6/0x190\n netlink_sendmsg+0x1f7/0x430\n __sys_sendto+0x213/0x220\n ? __sys_recvmsg+0x6a/0xd0\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fdfb8495047","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4dadc4077e3f77d6d31e199a925fc7a705e7adeb","https://git.kernel.org/stable/c/dad52950b409d6923880d65a4cddb383286e17d2","https://git.kernel.org/stable/c/e05b8084a20f6bd5827d338c928e5e0fcbafa496"],"published_time":"2026-01-25T15:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-23001","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix possible UAF in macvlan_forward_source()\n\nAdd RCU protection on (struct macvlan_source_entry)->vlan.\n\nWhenever macvlan_hash_del_source() is called, we must clear\nentry->vlan pointer before RCU grace period starts.\n\nThis allows macvlan_forward_source() to skip over\nentries queued for freeing.\n\nNote that macvlan_dev are already RCU protected, as they\nare embedded in a standard netdev (netdev_priv(ndev)).\n\nhttps: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00011,"ranking_epss":0.01244,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/15f6faf36e162532bec5cc05eb3fc622108bf2ed","https://git.kernel.org/stable/c/232afc74a6dde0fe1830988e5827921f5ec9bb3f","https://git.kernel.org/stable/c/484919832e2db6ce1e8add92c469e5d459a516b5","https://git.kernel.org/stable/c/6dbead9c7677186f22b7981dd085a0feec1f038e","https://git.kernel.org/stable/c/7470a7a63dc162f07c26dbf960e41ee1e248d80e","https://git.kernel.org/stable/c/8133e85b8a3ec9f10d861e0002ec6037256e987e","https://git.kernel.org/stable/c/8518712a2ca952d6da2238c6f0a16b4ae5ea3f13"],"published_time":"2026-01-25T15:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71162","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: tegra-adma: Fix use-after-free\n\nA use-after-free bug exists in the Tegra ADMA driver when audio streams\nare terminated, particularly during XRUN conditions. The issue occurs\nwhen the DMA buffer is freed by tegra_adma_terminate_all() before the\nvchan completion tasklet finishes accessing it.\n\nThe race condition follows this sequence:\n\n  1. DMA transfer completes, triggering an interrupt that schedules the\n     completion tasklet (tasklet has not executed yet)\n  2. Audio playback stops, calling tegra_adma_terminate_all() which\n     frees the DMA buffer memory via kfree()\n  3. The scheduled tasklet finally executes, calling vchan_complete()\n     which attempts to access the already-freed memory\n\nSince tasklets can execute at any time after being scheduled, there is\nno guarantee that the buffer will remain valid when vchan_complete()\nruns.\n\nFix this by properly synchronizing the virtual channel completion:\n - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the\n   descriptors as terminated instead of freeing the descriptor.\n - Add the callback tegra_adma_synchronize() that calls\n   vchan_synchronize() which kills any pending tasklets and frees any\n   terminated descriptors.\n\nCrash logs:\n[  337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0\n[  337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0\n\n[  337.427562] Call trace:\n[  337.427564]  dump_backtrace+0x0/0x320\n[  337.427571]  show_stack+0x20/0x30\n[  337.427575]  dump_stack_lvl+0x68/0x84\n[  337.427584]  print_address_description.constprop.0+0x74/0x2b8\n[  337.427590]  kasan_report+0x1f4/0x210\n[  337.427598]  __asan_load8+0xa0/0xd0\n[  337.427603]  vchan_complete+0x124/0x3b0\n[  337.427609]  tasklet_action_common.constprop.0+0x190/0x1d0\n[  337.427617]  tasklet_action+0x30/0x40\n[  337.427623]  __do_softirq+0x1a0/0x5c4\n[  337.427628]  irq_exit+0x110/0x140\n[  337.427633]  handle_domain_irq+0xa4/0xe0\n[  337.427640]  gic_handle_irq+0x64/0x160\n[  337.427644]  call_on_irq_stack+0x20/0x4c\n[  337.427649]  do_interrupt_handler+0x7c/0x90\n[  337.427654]  el1_interrupt+0x30/0x80\n[  337.427659]  el1h_64_irq_handler+0x18/0x30\n[  337.427663]  el1h_64_irq+0x7c/0x80\n[  337.427667]  cpuidle_enter_state+0xe4/0x540\n[  337.427674]  cpuidle_enter+0x54/0x80\n[  337.427679]  do_idle+0x2e0/0x380\n[  337.427685]  cpu_startup_entry+0x2c/0x70\n[  337.427690]  rest_init+0x114/0x130\n[  337.427695]  arch_call_rest_init+0x18/0x24\n[  337.427702]  start_kernel+0x380/0x3b4\n[  337.427706]  __primary_switched+0xc0/0xc8","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":9e-05,"ranking_epss":0.00889,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2efd07a7c36949e6fa36a69183df24d368bf9e96","https://git.kernel.org/stable/c/59cb421b0902fbef2b9512ae8ba198a20f26b41f","https://git.kernel.org/stable/c/5f8d1d66a952d0396671e1f21ff8127a4d14fb4e","https://git.kernel.org/stable/c/76992310f80776b4d1f7f8915f59b92883a3e44c","https://git.kernel.org/stable/c/ae3eed72de682ddbba507ed2d6b848c21a6b721e","https://git.kernel.org/stable/c/be655c3736b3546f39bc8116ffbf2a3b6cac96c4","https://git.kernel.org/stable/c/cb2c9c4bb1322cc3c9984ad17db8cdd2663879ca"],"published_time":"2026-01-25T15:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22990","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: replace overzealous BUG_ON in osdmap_apply_incremental()\n\nIf the osdmap is (maliciously) corrupted such that the incremental\nosdmap epoch is different from what is expected, there is no need to\nBUG.  Instead, just declare the incremental osdmap to be invalid.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":8e-05,"ranking_epss":0.00732,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4b106fbb1c7b841cd402abd83eb2447164c799ea","https://git.kernel.org/stable/c/6348d70af847b79805374fe628d3809a63fd7df3","https://git.kernel.org/stable/c/6afd2a4213524bc742b709599a3663aeaf77193c","https://git.kernel.org/stable/c/6c6cec3db3b418c4fdf815731bc39e46dff75e1b","https://git.kernel.org/stable/c/9aa0b0c14cefece078286d78b97d4c09685e372d","https://git.kernel.org/stable/c/d3613770e2677683e65d062da5e31f48c409abe9","https://git.kernel.org/stable/c/e00c3f71b5cf75681dbd74ee3f982a99cb690c2b"],"published_time":"2026-01-23T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22991","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: make free_choose_arg_map() resilient to partial allocation\n\nfree_choose_arg_map() may dereference a NULL pointer if its caller fails\nafter a partial allocation.\n\nFor example, in decode_choose_args(), if allocation of arg_map->args\nfails, execution jumps to the fail label and free_choose_arg_map() is\ncalled. Since arg_map->size is updated to a non-zero value before memory\nallocation, free_choose_arg_map() will iterate over arg_map->args and\ndereference a NULL pointer.\n\nTo prevent this potential NULL pointer dereference and make\nfree_choose_arg_map() more resilient, add checks for pointers before\niterating.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":8e-05,"ranking_epss":0.00754,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/8081faaf089db5280c3be820948469f7c58ef8dd","https://git.kernel.org/stable/c/851241d3f78a5505224dc21c03d8692f530256b4","https://git.kernel.org/stable/c/9b3730dabcf3764bfe3ff07caf55e641a0b45234","https://git.kernel.org/stable/c/c4c2152a858c0ce4d2bff6ca8c1d5b0ef9f2cbdf","https://git.kernel.org/stable/c/e3fe30e57649c551757a02e1cad073c47e1e075e","https://git.kernel.org/stable/c/ec1850f663da64842614c86b20fe734be070c2ba","https://git.kernel.org/stable/c/f21c3fdb96833aac2f533506899fe38c19cf49d5"],"published_time":"2026-01-23T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22992","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: return the handler error from mon_handle_auth_done()\n\nCurrently any error from ceph_auth_handle_reply_done() is propagated\nvia finish_auth() but isn't returned from mon_handle_auth_done().  This\nresults in higher layers learning that (despite the monitor considering\nus to be successfully authenticated) something went wrong in the\nauthentication phase and reacting accordingly, but msgr2 still trying\nto proceed with establishing the session in the background.  In the\ncase of secure mode this can trigger a WARN in setup_crypto() and later\nlead to a NULL pointer dereference inside of prepare_auth_signature().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00026,"ranking_epss":0.07251,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/33908769248b38a5e77cf9292817bb28e641992d","https://git.kernel.org/stable/c/77229551f2cf72f3e35636db68e6a825b912cf16","https://git.kernel.org/stable/c/9e0101e57534ef0e7578dd09608a6106736b82e5","https://git.kernel.org/stable/c/d2c4a5f6996683f287f3851ef5412797042de7f1","https://git.kernel.org/stable/c/e097cd858196b1914309e7e3d79b4fa79383754d","https://git.kernel.org/stable/c/e84b48d31b5008932c0a0902982809fbaa1d3b70"],"published_time":"2026-01-23T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22993","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: Fix RSS LUT NULL ptr issue after soft reset\n\nDuring soft reset, the RSS LUT is freed and not restored unless the\ninterface is up. If an ethtool command that accesses the rss lut is\nattempted immediately after reset, it will result in NULL ptr\ndereference. Also, there is no need to reset the rss lut if the soft reset\ndoes not involve queue count change.\n\nAfter soft reset, set the RSS LUT to default values based on the updated\nqueue count only if the reset was a result of a queue count change and\nthe LUT was not configured by the user. In all other cases, don't touch\nthe LUT.\n\nSteps to reproduce:\n\n** Bring the interface down (if up)\nifconfig eth1 down\n\n** update the queue count (eg., 27->20)\nethtool -L eth1 combined 20\n\n** display the RSS LUT\nethtool -x eth1\n\n[82375.558338] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[82375.558373] #PF: supervisor read access in kernel mode\n[82375.558391] #PF: error_code(0x0000) - not-present page\n[82375.558408] PGD 0 P4D 0\n[82375.558421] Oops: Oops: 0000 [#1] SMP NOPTI\n<snip>\n[82375.558516] RIP: 0010:idpf_get_rxfh+0x108/0x150 [idpf]\n[82375.558786] Call Trace:\n[82375.558793]  <TASK>\n[82375.558804]  rss_prepare.isra.0+0x187/0x2a0\n[82375.558827]  rss_prepare_data+0x3a/0x50\n[82375.558845]  ethnl_default_doit+0x13d/0x3e0\n[82375.558863]  genl_family_rcv_msg_doit+0x11f/0x180\n[82375.558886]  genl_rcv_msg+0x1ad/0x2b0\n[82375.558902]  ? __pfx_ethnl_default_doit+0x10/0x10\n[82375.558920]  ? __pfx_genl_rcv_msg+0x10/0x10\n[82375.558937]  netlink_rcv_skb+0x58/0x100\n[82375.558957]  genl_rcv+0x2c/0x50\n[82375.558971]  netlink_unicast+0x289/0x3e0\n[82375.558988]  netlink_sendmsg+0x215/0x440\n[82375.559005]  __sys_sendto+0x234/0x240\n[82375.559555]  __x64_sys_sendto+0x28/0x30\n[82375.560068]  x64_sys_call+0x1909/0x1da0\n[82375.560576]  do_syscall_64+0x7a/0xfa0\n[82375.561076]  ? clear_bhb_loop+0x60/0xb0\n[82375.561567]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n<snip>","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/a09380354d2f14759b9dd45de1bc2f6bf49e651b","https://git.kernel.org/stable/c/ab92fa4dd81beaaed4e93a851f7a37c9b2d9776f","https://git.kernel.org/stable/c/ebecca5b093895da801b3eba1a55b4ec4027d196"],"published_time":"2026-01-23T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22994","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix reference count leak in bpf_prog_test_run_xdp()\n\nsyzbot is reporting\n\n  unregister_netdevice: waiting for sit0 to become free. Usage count = 2\n\nproblem. A debug printk() patch found that a refcount is obtained at\nxdp_convert_md_to_buff() from bpf_prog_test_run_xdp().\n\nAccording to commit ec94670fcb3b (\"bpf: Support specifying ingress via\nxdp_md context in BPF_PROG_TEST_RUN\"), the refcount obtained by\nxdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md().\n\nTherefore, we can consider that the error handling path introduced by\ncommit 1c1949982524 (\"bpf: introduce frags support to\nbpf_prog_test_run_xdp()\") forgot to call xdp_convert_buff_to_md().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/368569bc546d3368ee9980ba79fc42fdff9a3365","https://git.kernel.org/stable/c/737be05a765761d7d7c9f7fe92274bd8e6f6951e","https://git.kernel.org/stable/c/98676ee71fd4eafeb8be63c7f3f1905d40e03101","https://git.kernel.org/stable/c/ec69daabe45256f98ac86c651b8ad1b2574489a7","https://git.kernel.org/stable/c/fb9ef40cccdbacce36029b305d0ef1e12e4fea38"],"published_time":"2026-01-23T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22995","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nublk: fix use-after-free in ublk_partition_scan_work\n\nA race condition exists between the async partition scan work and device\nteardown that can lead to a use-after-free of ub->ub_disk:\n\n1. ublk_ctrl_start_dev() schedules partition_scan_work after add_disk()\n2. ublk_stop_dev() calls ublk_stop_dev_unlocked() which does:\n   - del_gendisk(ub->ub_disk)\n   - ublk_detach_disk() sets ub->ub_disk = NULL\n   - put_disk() which may free the disk\n3. The worker ublk_partition_scan_work() then dereferences ub->ub_disk\n   leading to UAF\n\nFix this by using ublk_get_disk()/ublk_put_disk() in the worker to hold\na reference to the disk during the partition scan. The spinlock in\nublk_get_disk() synchronizes with ublk_detach_disk() ensuring the worker\neither gets a valid reference or sees NULL and exits early.\n\nAlso change flush_work() to cancel_work_sync() to avoid running the\npartition scan work unnecessarily when the disk is already detached.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00019,"ranking_epss":0.05102,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/72e28774e9644c2bdbb4920842fbf77103a15a85","https://git.kernel.org/stable/c/f0d385f6689f37a2828c686fb279121df006b4cb"],"published_time":"2026-01-23T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22980","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: provide locking for v4_end_grace\n\nWriting to v4_end_grace can race with server shutdown and result in\nmemory being accessed after it was freed - reclaim_str_hashtbl in\nparticularly.\n\nWe cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is\nheld while client_tracking_op->init() is called and that can wait for\nan upcall to nfsdcltrack which can write to v4_end_grace, resulting in a\ndeadlock.\n\nnfsd4_end_grace() is also called by the landromat work queue and this\ndoesn't require locking as server shutdown will stop the work and wait\nfor it before freeing anything that nfsd4_end_grace() might access.\n\nHowever, we must be sure that writing to v4_end_grace doesn't restart\nthe work item after shutdown has already waited for it.  For this we\nadd a new flag protected with nn->client_lock.  It is set only while it\nis safe to make client tracking calls, and v4_end_grace only schedules\nwork while the flag is set with the spinlock held.\n\nSo this patch adds a nfsd_net field \"client_tracking_active\" which is\nset as described.  Another field \"grace_end_forced\", is set when\nv4_end_grace is written.  After this is set, and providing\nclient_tracking_active is set, the laundromat is scheduled.\nThis \"grace_end_forced\" field bypasses other checks for whether the\ngrace period has finished.\n\nThis resolves a race which can result in use-after-free.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04481,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/06600719d0f7a723811c45e4d51f5b742f345309","https://git.kernel.org/stable/c/2857bd59feb63fcf40fe4baf55401baea6b4feb4","https://git.kernel.org/stable/c/34eb22836e0cdba093baac66599d68c4cd245a9d","https://git.kernel.org/stable/c/53f07d095e7e680c5e4569a55a019f2c0348cdc6","https://git.kernel.org/stable/c/ba4811c8b433bfa681729ca42cc62b6034f223b0","https://git.kernel.org/stable/c/ca97360860eb02e3ae4ba42c19b439a0fcecbf06","https://git.kernel.org/stable/c/e8bfa2401d4c51eca6e48e9b33c798828ca9df61"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22981","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: detach and close netdevs while handling a reset\n\nProtect the reset path from callbacks by setting the netdevs to detached\nstate and close any netdevs in UP state until the reset handling has\ncompleted. During a reset, the driver will de-allocate resources for the\nvport, and there is no guarantee that those will recover, which is why the\nexisting vport_ctrl_lock does not provide sufficient protection.\n\nidpf_detach_and_close() is called right before reset handling. If the\nreset handling succeeds, the netdevs state is recovered via call to\nidpf_attach_and_open(). If the reset handling fails the netdevs remain\ndown. The detach/down calls are protected with RTNL lock to avoid racing\nwith callbacks. On the recovery side the attach can be done without\nholding the RTNL lock as there are no callbacks expected at that point,\ndue to detach/close always being done first in that flow.\n\nThe previous logic restoring the netdevs state based on the\nIDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence\nthe removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is\nstill being used to restore the state of the netdevs following the reset,\nbut has no use outside of the reset handling flow.\n\nidpf_init_hard_reset() is converted to void, since it was used as such and\nthere is no error handling being done based on its return value.\n\nBefore this change, invoking hard and soft resets simultaneously will\ncause the driver to lose the vport state:\nip -br a\n<inf>\tUP\necho 1 > /sys/class/net/ens801f0/device/reset& \\\nethtool -L ens801f0 combined 8\nip -br a\n<inf>\tDOWN\nip link set <inf> up\nip -br a\n<inf>\tDOWN\n\nAlso in case of a failure in the reset path, the netdev is left\nexposed to external callbacks, while vport resources are not\ninitialized, leading to a crash on subsequent ifup/down:\n[408471.398966] idpf 0000:83:00.0: HW reset detected\n[408471.411744] idpf 0000:83:00.0: Device HW Reset initiated\n[408472.277901] idpf 0000:83:00.0: The driver was unable to contact the device's firmware. Check that the FW is running. Driver state= 0x2\n[408508.125551] BUG: kernel NULL pointer dereference, address: 0000000000000078\n[408508.126112] #PF: supervisor read access in kernel mode\n[408508.126687] #PF: error_code(0x0000) - not-present page\n[408508.127256] PGD 2aae2f067 P4D 0\n[408508.127824] Oops: Oops: 0000 [#1] SMP NOPTI\n...\n[408508.130871] RIP: 0010:idpf_stop+0x39/0x70 [idpf]\n...\n[408508.139193] Call Trace:\n[408508.139637]  <TASK>\n[408508.140077]  __dev_close_many+0xbb/0x260\n[408508.140533]  __dev_change_flags+0x1cf/0x280\n[408508.140987]  netif_change_flags+0x26/0x70\n[408508.141434]  dev_change_flags+0x3d/0xb0\n[408508.141878]  devinet_ioctl+0x460/0x890\n[408508.142321]  inet_ioctl+0x18e/0x1d0\n[408508.142762]  ? _copy_to_user+0x22/0x70\n[408508.143207]  sock_do_ioctl+0x3d/0xe0\n[408508.143652]  sock_ioctl+0x10e/0x330\n[408508.144091]  ? find_held_lock+0x2b/0x80\n[408508.144537]  __x64_sys_ioctl+0x96/0xe0\n[408508.144979]  do_syscall_64+0x79/0x3d0\n[408508.145415]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[408508.145860] RIP: 0033:0x7f3e0bb4caff","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2e281e1155fc476c571c0bd2ffbfe28ab829a5c3","https://git.kernel.org/stable/c/9ad3d0836d8bc1a0f0b4bf56efc56312a9e64b97","https://git.kernel.org/stable/c/ac122f5fb050903b3d262001562c452be95eaf70"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22982","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mscc: ocelot: Fix crash when adding interface under a lag\n\nCommit 15faa1f67ab4 (\"lan966x: Fix crash when adding interface under a lag\")\nfixed a similar issue in the lan966x driver caused by a NULL pointer dereference.\nThe ocelot_set_aggr_pgids() function in the ocelot driver has similar logic\nand is susceptible to the same crash.\n\nThis issue specifically affects the ocelot_vsc7514.c frontend, which leaves\nunused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected as\nit uses the DSA framework which registers all ports.\n\nFix this by checking if the port pointer is valid before accessing it.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04343,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03fb1708b7d1e76aecebf767ad059c319845039f","https://git.kernel.org/stable/c/2985712dc76dfa670eb7fd607c09d4d48e5f5c6e","https://git.kernel.org/stable/c/34f3ff52cb9fa7dbf04f5c734fcc4cb6ed5d1a95","https://git.kernel.org/stable/c/8767f238b0e6c3d0b295ac6dce9fbe6a99bd1b9d","https://git.kernel.org/stable/c/b17818307446c5a8d925a39a792261dbfa930041","https://git.kernel.org/stable/c/f490af47bbee02441e356a1e0b86e3b3dd5120ff"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22983","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: do not write to msg_get_inq in callee\n\nNULL pointer dereference fix.\n\nmsg_get_inq is an input field from caller to callee. Don't set it in\nthe callee, as the caller may not clear it on struct reuse.\n\nThis is a kernel-internal variant of msghdr only, and the only user\ndoes reinitialize the field. So this is not critical for that reason.\nBut it is more robust to avoid the write, and slightly simpler code.\nAnd it fixes a bug, see below.\n\nCallers set msg_get_inq to request the input queue length to be\nreturned in msg_inq. This is equivalent to but independent from the\nSO_INQ request to return that same info as a cmsg (tp->recvmsg_inq).\nTo reduce branching in the hot path the second also sets the msg_inq.\nThat is WAI.\n\nThis is a fix to commit 4d1442979e4a (\"af_unix: don't post cmsg for\nSO_INQ unless explicitly asked for\"), which fixed the inverse.\n\nAlso avoid NULL pointer dereference in unix_stream_read_generic if\nstate->msg is NULL and msg->msg_get_inq is written. A NULL state->msg\ncan happen when splicing as of commit 2b514574f7e8 (\"net: af_unix:\nimplement splice for stream af_unix sockets\").\n\nAlso collapse two branches using a bitwise or.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7d11e047eda5f98514ae62507065ac961981c025","https://git.kernel.org/stable/c/ffa2be496ef65055b28b39c6bd9a7d66943ee89a"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22984","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: prevent potential out-of-bounds reads in handle_auth_done()\n\nPerform an explicit bounds check on payload_len to avoid a possible\nout-of-bounds access in the callout.\n\n[ idryomov: changelog ]","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":9e-05,"ranking_epss":0.00889,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/194cfe2af4d2a1de599d39dad636b47c2f6c2c96","https://git.kernel.org/stable/c/2802ef3380fa8c4a08cda51ec1f085b1a712e9e2","https://git.kernel.org/stable/c/2d653bb63d598ae4b096dd678744bdcc34ee89e8","https://git.kernel.org/stable/c/79fe3511db416d2f2edcfd93569807cb02736e5e","https://git.kernel.org/stable/c/818156caffbf55cb4d368f9c3cac64e458fb49c9","https://git.kernel.org/stable/c/ef208ea331ef688729f64089b895ed1b49e842e3"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22985","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: Fix RSS LUT NULL pointer crash on early ethtool operations\n\nThe RSS LUT is not initialized until the interface comes up, causing\nthe following NULL pointer crash when ethtool operations like rxhash on/off\nare performed before the interface is brought up for the first time.\n\nMove RSS LUT initialization from ndo_open to vport creation to ensure LUT\nis always available. This enables RSS configuration via ethtool before\nbringing the interface up. Simplify LUT management by maintaining all\nchanges in the driver's soft copy and programming zeros to the indirection\ntable when rxhash is disabled. Defer HW programming until the interface\ncomes up if it is down during rxhash and LUT configuration changes.\n\nSteps to reproduce:\n** Load idpf driver; interfaces will be created\n\tmodprobe idpf\n** Before bringing the interfaces up, turn rxhash off\n\tethtool -K eth2 rxhash off\n\n[89408.371875] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[89408.371908] #PF: supervisor read access in kernel mode\n[89408.371924] #PF: error_code(0x0000) - not-present page\n[89408.371940] PGD 0 P4D 0\n[89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI\n<snip>\n[89408.372052] RIP: 0010:memcpy_orig+0x16/0x130\n[89408.372310] Call Trace:\n[89408.372317]  <TASK>\n[89408.372326]  ? idpf_set_features+0xfc/0x180 [idpf]\n[89408.372363]  __netdev_update_features+0x295/0xde0\n[89408.372384]  ethnl_set_features+0x15e/0x460\n[89408.372406]  genl_family_rcv_msg_doit+0x11f/0x180\n[89408.372429]  genl_rcv_msg+0x1ad/0x2b0\n[89408.372446]  ? __pfx_ethnl_set_features+0x10/0x10\n[89408.372465]  ? __pfx_genl_rcv_msg+0x10/0x10\n[89408.372482]  netlink_rcv_skb+0x58/0x100\n[89408.372502]  genl_rcv+0x2c/0x50\n[89408.372516]  netlink_unicast+0x289/0x3e0\n[89408.372533]  netlink_sendmsg+0x215/0x440\n[89408.372551]  __sys_sendto+0x234/0x240\n[89408.372571]  __x64_sys_sendto+0x28/0x30\n[89408.372585]  x64_sys_call+0x1909/0x1da0\n[89408.372604]  do_syscall_64+0x7a/0xfa0\n[89408.373140]  ? clear_bhb_loop+0x60/0xb0\n[89408.373647]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[89408.378887]  </TASK>\n<snip>","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/83f38f210b85676f40ba8586b5a8edae19b56995","https://git.kernel.org/stable/c/b29a5a7dd1f4293ee49c469938c25bf85a5aa802","https://git.kernel.org/stable/c/df2790b5228fbd3ed415b70a231cffdad0431618"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22986","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: fix race condition for gdev->srcu\n\nIf two drivers were calling gpiochip_add_data_with_key(), one may be\ntraversing the srcu-protected list in gpio_name_to_desc(), meanwhile\nother has just added its gdev in gpiodev_add_to_list_unlocked().\nThis creates a non-mutexed and non-protected timeframe, when one\ninstance is dereferencing and using &gdev->srcu, before the other\nhas initialized it, resulting in crash:\n\n[    4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000\n[    4.943396] Mem abort info:\n[    4.943400]   ESR = 0x0000000096000005\n[    4.943403]   EC = 0x25: DABT (current EL), IL = 32 bits\n[    4.943407]   SET = 0, FnV = 0\n[    4.943410]   EA = 0, S1PTW = 0\n[    4.943413]   FSC = 0x05: level 1 translation fault\n[    4.943416] Data abort info:\n[    4.943418]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n[    4.946220]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[    4.955261]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[    4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000\n[    4.961449] [ffff800272bcc000] pgd=0000000000000000\n[    4.969203] , p4d=1000000039739003\n[    4.979730] , pud=0000000000000000\n[    4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 for node \"reset\"\n[    4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP\n...\n[    5.121359] pc : __srcu_read_lock+0x44/0x98\n[    5.131091] lr : gpio_name_to_desc+0x60/0x1a0\n[    5.153671] sp : ffff8000833bb430\n[    5.298440]\n[    5.298443] Call trace:\n[    5.298445]  __srcu_read_lock+0x44/0x98\n[    5.309484]  gpio_name_to_desc+0x60/0x1a0\n[    5.320692]  gpiochip_add_data_with_key+0x488/0xf00\n    5.946419] ---[ end trace 0000000000000000 ]---\n\nMove initialization code for gdev fields before it is added to\ngpio_devices, with adjacent initialization code.\nAdjust goto statements  to reflect modified order of operations\n\n[Bartosz: fixed a build issue, removed stray newline]","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00015,"ranking_epss":0.03022,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/a7ac22d53d0990152b108c3f4fe30df45fcb0181","https://git.kernel.org/stable/c/fb674c8f1a5d8dd3113a7326030f963fa2d79c02"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22987","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_api: avoid dereferencing ERR_PTR in tcf_idrinfo_destroy\n\nsyzbot reported a crash in tc_act_in_hw() during netns teardown where\ntcf_idrinfo_destroy() passed an ERR_PTR(-EBUSY) value as a tc_action\npointer, leading to an invalid dereference.\n\nGuard against ERR_PTR entries when iterating the action IDR so teardown\ndoes not call tc_act_in_hw() on an error pointer.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/67550a1130b647bb0d093c9c0a810c69aa6a30a8","https://git.kernel.org/stable/c/adb25a46dc0a43173f5ea5f5f58fc8ba28970c7c"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22988","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\narp: do not assume dev_hard_header() does not change skb->head\n\narp_create() is the only dev_hard_header() caller\nmaking assumption about skb->head being unchanged.\n\nA recent commit broke this assumption.\n\nInitialize @arp pointer after dev_hard_header() call.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04343,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/029935507d0af6553c45380fbf6feecf756fd226","https://git.kernel.org/stable/c/393525dee5c39acff8d6705275d7fcaabcfb7f0a","https://git.kernel.org/stable/c/70bddc16491ef4681f3569b3a2c80309a3edcdd1","https://git.kernel.org/stable/c/949647e7771a4a01963fe953a96d81fba7acecf3","https://git.kernel.org/stable/c/c92510f5e3f82ba11c95991824a41e59a9c5ed81","https://git.kernel.org/stable/c/dd6ccec088adff4bdf33e2b2dd102df20a7128fa","https://git.kernel.org/stable/c/e432dbff342b95fe44645f9a90fcf333c80f4b5e"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22989","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: check that server is running in unlock_filesystem\n\nIf we are trying to unlock the filesystem via an administrative\ninterface and nfsd isn't running, it crashes the server. This\nhappens currently because nfsd4_revoke_states() access state\nstructures (eg., conf_id_hashtbl) that has been freed as a part\nof the server shutdown.\n\n[   59.465072] Call trace:\n[   59.465308]  nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)\n[   59.465830]  write_unlock_fs+0x258/0x440 [nfsd]\n[   59.466278]  nfsctl_transaction_write+0xb0/0x120 [nfsd]\n[   59.466780]  vfs_write+0x1f0/0x938\n[   59.467088]  ksys_write+0xfc/0x1f8\n[   59.467395]  __arm64_sys_write+0x74/0xb8\n[   59.467746]  invoke_syscall.constprop.0+0xdc/0x1e8\n[   59.468177]  do_el0_svc+0x154/0x1d8\n[   59.468489]  el0_svc+0x40/0xe0\n[   59.468767]  el0t_64_sync_handler+0xa0/0xe8\n[   59.469138]  el0t_64_sync+0x1ac/0x1b0\n\nEnsure this can't happen by taking the nfsd_mutex and checking that\nthe server is still up, and then holding the mutex across the call to\nnfsd4_revoke_states().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/d0424066fcd294977f310964bed6f2a487fa4515","https://git.kernel.org/stable/c/d95499900fe52f3d461ed26b7a30bebea8f12914","https://git.kernel.org/stable/c/e06c9f6c0f554148d4921c2a15bd054260a054ac"],"published_time":"2026-01-23T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71161","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndm-verity: disable recursive forward error correction\n\nThere are two problems with the recursive correction:\n\n1. It may cause denial-of-service. In fec_read_bufs, there is a loop that\nhas 253 iterations. For each iteration, we may call verity_hash_for_block\nrecursively. There is a limit of 4 nested recursions - that means that\nthere may be at most 253^4 (4 billion) iterations. Red Hat QE team\nactually created an image that pushes dm-verity to this limit - and this\nimage just makes the udev-worker process get stuck in the 'D' state.\n\n2. It doesn't work. In fec_read_bufs we store data into the variable\n\"fio->bufs\", but fio bufs is shared between recursive invocations, if\n\"verity_hash_for_block\" invoked correction recursively, it would\noverwrite partially filled fio->bufs.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":8e-05,"ranking_epss":0.00728,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/232948cf600fba69aff36b25d85ef91a73a35756","https://git.kernel.org/stable/c/4220cb37406915c926c0e4a3dbab77cd9cceeb1e","https://git.kernel.org/stable/c/897d9006e75f46f8bd7df78faa424327ae6a4bcf","https://git.kernel.org/stable/c/d9f3e47d3fae0c101d9094bc956ed24e7a0ee801","https://git.kernel.org/stable/c/e227d2b229c7529bd98d348efc55262ccf24ab35"],"published_time":"2026-01-23T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22978","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: avoid kernel-infoleak from struct iw_point\n\nstruct iw_point has a 32bit hole on 64bit arches.\n\nstruct iw_point {\n  void __user   *pointer;       /* Pointer to the data  (in user space) */\n  __u16         length;         /* number of fields or size in bytes */\n  __u16         flags;          /* Optional params */\n};\n\nMake sure to zero the structure to avoid disclosing 32bits of kernel data\nto user space.","cvss":3.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.3,"epss":0.00018,"ranking_epss":0.04552,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/024f71a57d563fbe162e528c8bf2d27e9cac7c7b","https://git.kernel.org/stable/c/21cbf883d073abbfe09e3924466aa5e0449e7261","https://git.kernel.org/stable/c/442ceac0393185e9982323f6682a52a53e8462b1","https://git.kernel.org/stable/c/a3827e310b5a73535646ef4a552d53b3c8bf74f6","https://git.kernel.org/stable/c/d21ec867d84c9f3a9845d7d8c90c9ce35dbe48f8","https://git.kernel.org/stable/c/d943b5f592767b107ba8c12a902f17431350378c","https://git.kernel.org/stable/c/e3c35177103ead4658b8a62f41e3080d45885464"],"published_time":"2026-01-23T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22979","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix memory leak in skb_segment_list for GRO packets\n\nWhen skb_segment_list() is called during packet forwarding, it handles\npackets that were aggregated by the GRO engine.\n\nHistorically, the segmentation logic in skb_segment_list assumes that\nindividual segments are split from a parent SKB and may need to carry\ntheir own socket memory accounting. Accordingly, the code transfers\ntruesize from the parent to the newly created segments.\n\nPrior to commit ed4cccef64c1 (\"gro: fix ownership transfer\"), this\ntruesize subtraction in skb_segment_list() was valid because fragments\nstill carry a reference to the original socket.\n\nHowever, commit ed4cccef64c1 (\"gro: fix ownership transfer\") changed\nthis behavior by ensuring that fraglist entries are explicitly\norphaned (skb->sk = NULL) to prevent illegal orphaning later in the\nstack. This change meant that the entire socket memory charge remained\nwith the head SKB, but the corresponding accounting logic in\nskb_segment_list() was never updated.\n\nAs a result, the current code unconditionally adds each fragment's\ntruesize to delta_truesize and subtracts it from the parent SKB. Since\nthe fragments are no longer charged to the socket, this subtraction\nresults in an effective under-count of memory when the head is freed.\nThis causes sk_wmem_alloc to remain non-zero, preventing socket\ndestruction and leading to a persistent memory leak.\n\nThe leak can be observed via KMEMLEAK when tearing down the networking\nenvironment:\n\nunreferenced object 0xffff8881e6eb9100 (size 2048):\n  comm \"ping\", pid 6720, jiffies 4295492526\n  backtrace:\n    kmem_cache_alloc_noprof+0x5c6/0x800\n    sk_prot_alloc+0x5b/0x220\n    sk_alloc+0x35/0xa00\n    inet6_create.part.0+0x303/0x10d0\n    __sock_create+0x248/0x640\n    __sys_socket+0x11b/0x1d0\n\nSince skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST\npackets constructed by GRO, the truesize adjustment is removed.\n\nThe call to skb_release_head_state() must be preserved. As documented in\ncommit cf673ed0e057 (\"net: fix fraglist segmentation reference count\nleak\"), it is still required to correctly drop references to SKB\nextensions that may be overwritten during __copy_skb_header().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0b27828ebd1ed3107d7929c3737adbe862e99e74","https://git.kernel.org/stable/c/238e03d0466239410b72294b79494e43d4fabe77","https://git.kernel.org/stable/c/3264881431e308b9c72cb8a0159d57a56d67dd79","https://git.kernel.org/stable/c/88bea149db2057112af3aaf63534b24fab5858ab","https://git.kernel.org/stable/c/c114a32a2e70b82d447f409f7ffcfa3058f9d5bd"],"published_time":"2026-01-23T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71158","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: mpsse: ensure worker is torn down\n\nWhen an IRQ worker is running, unplugging the device would cause a\ncrash. The sealevel hardware this driver was written for was not\nhotpluggable, so I never realized it.\n\nThis change uses a spinlock to protect a list of workers, which\nit tears down on disconnect.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":9e-05,"ranking_epss":0.00841,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/179ef1127d7a4f09f0e741fa9f30b8a8e7886271","https://git.kernel.org/stable/c/472d900c8bcac301ae0e40fdca7db799bd989ff5"],"published_time":"2026-01-23T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71159","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix use-after-free warning in btrfs_get_or_create_delayed_node()\n\nPreviously, btrfs_get_or_create_delayed_node() set the delayed_node's\nrefcount before acquiring the root->delayed_nodes lock.\nCommit e8513c012de7 (\"btrfs: implement ref_tracker for delayed_nodes\")\nmoved refcount_set inside the critical section, which means there is\nno longer a memory barrier between setting the refcount and setting\nbtrfs_inode->delayed_node.\n\nWithout that barrier, the stores to node->refs and\nbtrfs_inode->delayed_node may become visible out of order. Another\nthread can then read btrfs_inode->delayed_node and attempt to\nincrement a refcount that hasn't been set yet, leading to a\nrefcounting bug and a use-after-free warning.\n\nThe fix is to move refcount_set back to where it was to take\nadvantage of the implicit memory barrier provided by lock\nacquisition.\n\nBecause the allocations now happen outside of the lock's critical\nsection, they can use GFP_NOFS instead of GFP_ATOMIC.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00019,"ranking_epss":0.05102,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/83f59076a1ae6f5c6845d6f7ed3a1a373d883684","https://git.kernel.org/stable/c/c8385851a5435f4006281828d428e5d0b0bbf8af"],"published_time":"2026-01-23T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71160","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: avoid chain re-validation if possible\n\nHamza Mahfooz reports cpu soft lock-ups in\nnft_chain_validate():\n\n watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]\n[..]\n RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]\n[..]\n  nft_immediate_validate+0x36/0x50 [nf_tables]\n  nft_chain_validate+0xc9/0x110 [nf_tables]\n  nft_immediate_validate+0x36/0x50 [nf_tables]\n  nft_chain_validate+0xc9/0x110 [nf_tables]\n  nft_immediate_validate+0x36/0x50 [nf_tables]\n  nft_chain_validate+0xc9/0x110 [nf_tables]\n  nft_immediate_validate+0x36/0x50 [nf_tables]\n  nft_chain_validate+0xc9/0x110 [nf_tables]\n  nft_immediate_validate+0x36/0x50 [nf_tables]\n  nft_chain_validate+0xc9/0x110 [nf_tables]\n  nft_immediate_validate+0x36/0x50 [nf_tables]\n  nft_chain_validate+0xc9/0x110 [nf_tables]\n  nft_table_validate+0x6b/0xb0 [nf_tables]\n  nf_tables_validate+0x8b/0xa0 [nf_tables]\n  nf_tables_commit+0x1df/0x1eb0 [nf_tables]\n[..]\n\nCurrently nf_tables will traverse the entire table (chain graph), starting\nfrom the entry points (base chains), exploring all possible paths\n(chain jumps).  But there are cases where we could avoid revalidation.\n\nConsider:\n1  input -> j2 -> j3\n2  input -> j2 -> j3\n3  input -> j1 -> j2 -> j3\n\nThen the second rule does not need to revalidate j2, and, by extension j3,\nbecause this was already checked during validation of the first rule.\nWe need to validate it only for rule 3.\n\nThis is needed because chain loop detection also ensures we do not exceed\nthe jump stack: Just because we know that j2 is cycle free, its last jump\nmight now exceed the allowed stack size.  We also need to update all\nreachable chains with the new largest observed call depth.\n\nCare has to be taken to revalidate even if the chain depth won't be an\nissue: chain validation also ensures that expressions are not called from\ninvalid base chains.  For example, the masquerade expression can only be\ncalled from NAT postrouting base chains.\n\nTherefore we also need to keep record of the base chain context (type,\nhooknum) and revalidate if the chain becomes reachable from a different\nhook location.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0001,"ranking_epss":0.01148,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/09d6074995c186e449979fe6c1b0f1a69cf9bd3b","https://git.kernel.org/stable/c/14fa3d1927f1382f86e3f70a51f26005c8e3cff6","https://git.kernel.org/stable/c/53de1e6cde8f9b791d9cf61aa0e7b02cf5bbe8b1","https://git.kernel.org/stable/c/8e1a1bc4f5a42747c08130b8242ebebd1210b32f"],"published_time":"2026-01-23T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71152","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn't make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n   the elevated refcount on the conduit's kobject. Nominally, the OF and\n   non-OF paths should result in objects having identical reference\n   counts taken, and it is already suspicious that\n   dsa_dev_to_net_device() has a put_device() call which is missing in\n   dsa_port_parse_of(), but we can actually even verify that an issue\n   exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n   \"before\" and \"after\" applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n   it can get unregistered at any time, and DSA remains with a long-lived,\n   but in this case stale, cpu_dp->conduit pointer. Holding the net\n   device's underlying kobject isn't actually of much help, it just\n   prevents it from being freed (but we never need that kobject\n   directly). What helps us to prevent the net device from being\n   unregistered is the parallel netdev reference mechanism (dev_hold()\n   and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn't know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n   ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not\n   make user port errors fatal\"), and the cpu_dp->conduit pointers\n   remain valid.  I haven't audited all call paths to see whether they\n   will actually use the conduit in lack of any user port, but if they\n   do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n   associated to, and we can get into a situation where we've moved all\n   user ports away from a conduit, thus no longer hold any reference to\n   it via the net device tracker. But we shouldn't let it go nonetheless\n   - see the next change in relation to dsa_tree_find_first_conduit()\n   and LAG conduits which disappear.\n   We have to be prepared to return to the physical conduit, so the CPU\n   port must explicitly keep another reference to it. This is also to\n   say: the user ports and their CPU ports may not always keep a\n   reference to the same conduit net device, and both are needed.\n\nAs for the conduit's kobject for the /sys/class/net/ entry, we don't\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I'll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/06e219f6a706c367c93051f408ac61417643d2f9","https://git.kernel.org/stable/c/0e766b77ba5093583dfe609fae0aa1545c46dbbd","https://git.kernel.org/stable/c/b358fc6ff3b35a29f7f677da1c67af67d0d560cb","https://git.kernel.org/stable/c/ec2b34acb1894cfc10ed22d8277ca4f11e9f4b23"],"published_time":"2026-01-23T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71153","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix memory leak in get_file_all_info()\n\nIn get_file_all_info(), if vfs_getattr() fails, the function returns\nimmediately without freeing the allocated filename, leading to a memory\nleak.\n\nFix this by freeing the filename before returning in this error case.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04182,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0c56693b06a68476ba113db6347e7897475f9e4c","https://git.kernel.org/stable/c/5012b4c812230ae066902a00442708c999111183","https://git.kernel.org/stable/c/676907004256e0226c7ed3691db9f431404ca258","https://git.kernel.org/stable/c/d026f47db68638521df8543535ef863814fb01b1"],"published_time":"2026-01-23T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71154","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: fix memory leak on usb_submit_urb() failure\n\nIn async_set_registers(), when usb_submit_urb() fails, the allocated\n  async_req structure and URB are not freed, causing a memory leak.\n\n  The completion callback async_set_reg_cb() is responsible for freeing\n  these allocations, but it is only called after the URB is successfully\n  submitted and completes (successfully or with error). If submission\n  fails, the callback never runs and the memory is leaked.\n\n  Fix this by freeing both the URB and the request structure in the error\n  path when usb_submit_urb() fails.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/12cab1191d9890097171156d06bfa8d31f1e39c8","https://git.kernel.org/stable/c/151403e903840c9cf06754097b6732c14f26c532","https://git.kernel.org/stable/c/2f966186b99550e3c665dbfb87b8314e30acea02","https://git.kernel.org/stable/c/4bd4ea3eb326608ffc296db12c105f92dc2f2190","https://git.kernel.org/stable/c/6492ad6439ff1a479fc94dc6052df3628faed8b6","https://git.kernel.org/stable/c/a4e2442d3c48355a84463342f397134f149936d7","https://git.kernel.org/stable/c/db2244c580540306d60ce783ed340190720cd429"],"published_time":"2026-01-23T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71155","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: Fix gmap_helper_zap_one_page() again\n\nA few checks were missing in gmap_helper_zap_one_page(), which can lead\nto memory corruption in the guest under specific circumstances.\n\nAdd the missing checks.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00023,"ranking_epss":0.06055,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2af2abbcbf8573100288e8f8aea2dab8a2a0ceb7","https://git.kernel.org/stable/c/2f393c228cc519ddf19b8c6c05bf15723241aa96"],"published_time":"2026-01-23T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71156","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngve: defer interrupt enabling until NAPI registration\n\nCurrently, interrupts are automatically enabled immediately upon\nrequest. This allows interrupt to fire before the associated NAPI\ncontext is fully initialized and cause failures like below:\n\n[    0.946369] Call Trace:\n[    0.946369]  <IRQ>\n[    0.946369]  __napi_poll+0x2a/0x1e0\n[    0.946369]  net_rx_action+0x2f9/0x3f0\n[    0.946369]  handle_softirqs+0xd6/0x2c0\n[    0.946369]  ? handle_edge_irq+0xc1/0x1b0\n[    0.946369]  __irq_exit_rcu+0xc3/0xe0\n[    0.946369]  common_interrupt+0x81/0xa0\n[    0.946369]  </IRQ>\n[    0.946369]  <TASK>\n[    0.946369]  asm_common_interrupt+0x22/0x40\n[    0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10\n\nUse the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent auto\nenablement and explicitly enable the interrupt in NAPI initialization\npath (and disable it during NAPI teardown).\n\nThis ensures that interrupt lifecycle is strictly coupled with\nreadiness of NAPI context.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.04296,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3d970eda003441f66551a91fda16478ac0711617","https://git.kernel.org/stable/c/48f9277680925e1a8623d6b2c50aadb7af824ace","https://git.kernel.org/stable/c/f5b7f49bd2377916ad57cbd1210c61196daff013"],"published_time":"2026-01-23T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71157","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: always drop device refcount in ib_del_sub_device_and_put()\n\nSince nldev_deldev() (introduced by commit 060c642b2ab8 (\"RDMA/nldev: Add\nsupport to add/delete a sub IB device through netlink\") grabs a reference\nusing ib_device_get_by_index() before calling ib_del_sub_device_and_put(),\nwe need to drop that reference before returning -EOPNOTSUPP error.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.04296,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/20436f2742a92b7afeb2504eb559a98d2196b001","https://git.kernel.org/stable/c/fa3c411d21ebc26ffd175c7256c37cefa35020aa","https://git.kernel.org/stable/c/fe8d456080423b9ed410469fbd1e2098d3acce2b"],"published_time":"2026-01-23T15:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71146","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conncount: fix leaked ct in error paths\n\nThere are some situations where ct might be leaked as error paths are\nskipping the refcounted check and return immediately. In order to solve\nit make sure that the check is always called.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04343,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/08fa37f4c8c59c294e9c18fea2d083ee94074e5a","https://git.kernel.org/stable/c/0b88be7211d21a0d68bb1e56dc805944e3654d6f","https://git.kernel.org/stable/c/2e2a720766886190a6d35c116794693aabd332b6","https://git.kernel.org/stable/c/325eb61bb30790ea27782203a17b007ce1754a67","https://git.kernel.org/stable/c/4bd2b89f4028f250dd1c1625eb3da1979b04a5e8","https://git.kernel.org/stable/c/e1ac8dce3a893641bef224ad057932f142b8a36f","https://git.kernel.org/stable/c/f381a33f34dda9e4023e38ba68c943bca83245e9"],"published_time":"2026-01-23T15:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71147","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Fix a memory leak in tpm2_load_cmd\n\n'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode'\nbut it is not freed in the failure paths. Address this by wrapping the blob\ninto with a cleanup helper.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04343,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/19166de9737218b77122c41a5730ac87025e089f","https://git.kernel.org/stable/c/3fd7df4636d8fd5e3592371967a5941204368936","https://git.kernel.org/stable/c/62cd5d480b9762ce70d720a81fa5b373052ae05f","https://git.kernel.org/stable/c/9b015f2918b95bdde2ca9cefa10ef02b138aae1e","https://git.kernel.org/stable/c/9e7c63c69f57b1db1a8a1542359a6167ff8fcef1","https://git.kernel.org/stable/c/af0689cafb127a8d1af78cc8b72585c9b2a19ecd"],"published_time":"2026-01-23T15:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71148","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/handshake: restore destructor on submit failure\n\nhandshake_req_submit() replaces sk->sk_destruct but never restores it when\nsubmission fails before the request is hashed. handshake_sk_destruct() then\nreturns early and the original destructor never runs, leaking the socket.\nRestore sk_destruct on the error path.","cvss":3.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.3,"epss":0.00018,"ranking_epss":0.04361,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6af2a01d65f89e73c1cbb9267f8880d83a88cee4","https://git.kernel.org/stable/c/7b82a1d6ae869533d8bdb0282a3a78faed8e63dd","https://git.kernel.org/stable/c/b225325be7b247c7268e65eea6090db1fc786d1f","https://git.kernel.org/stable/c/cd8cf2be3717137554744233fda051ffc09d1d44"],"published_time":"2026-01-23T15:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71149","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/poll: correctly handle io_poll_add() return value on update\n\nWhen the core of io_uring was updated to handle completions\nconsistently and with fixed return codes, the POLL_REMOVE opcode\nwith updates got slightly broken. If a POLL_ADD is pending and\nthen POLL_REMOVE is used to update the events of that request, if that\nupdate causes the POLL_ADD to now trigger, then that completion is lost\nand a CQE is never posted.\n\nAdditionally, ensure that if an update does cause an existing POLL_ADD\nto complete, that the completion value isn't always overwritten with\n-ECANCELED. For that case, whatever io_poll_add() set the value to\nshould just be retained.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0126560370ed5217958b85657b590ad25e8b9c00","https://git.kernel.org/stable/c/13a8f7b88c2d40c6b33f6216190478dda95d385f","https://git.kernel.org/stable/c/84230ad2d2afbf0c44c32967e525c0ad92e26b4e","https://git.kernel.org/stable/c/8b777ab48441b153502772ecfc78c107d4353f29","https://git.kernel.org/stable/c/c1669c03bfbc2a9b5ebff4428eecebe734c646fe"],"published_time":"2026-01-23T15:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71150","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix refcount leak when invalid session is found on session lookup\n\nWhen a session is found but its state is not SMB2_SESSION_VALID, It\nindicates that no valid session was found, but it is missing to decrement\nthe reference count acquired by the session lookup, which results in\na reference count leak. This patch fixes the issue by explicitly calling\nksmbd_user_session_put to release the reference to the session.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/02e06785e85b4bd86ef3d23b7c8d87acc76773d5","https://git.kernel.org/stable/c/0fb87b28cafae71e9c8248432cc3a6a1fd759efc","https://git.kernel.org/stable/c/8cabcb4dd3dc85dd83a37d26efcc59a66a4074d7","https://git.kernel.org/stable/c/cafb57f7bdd57abba87725eb4e82bbdca4959644","https://git.kernel.org/stable/c/e54fb2a4772545701766cba08aab20de5eace8cd"],"published_time":"2026-01-23T15:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71151","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix memory and information leak in smb3_reconfigure()\n\nIn smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the\nfunction returns immediately without freeing and erasing the newly\nallocated new_password and new_password2. This causes both a memory leak\nand a potential information leak.\n\nFix this by calling kfree_sensitive() on both password buffers before\nreturning in this error case.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04678,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5679cc90bb5415801fa29041da0319d9e15d295d","https://git.kernel.org/stable/c/bb82aaee16907dc4d0b9b0ca7953ceb3edc328c6","https://git.kernel.org/stable/c/bc390b2737205163e48cc1655f6a0c8cd55b02fc","https://git.kernel.org/stable/c/cb6d5aa9c0f10074f1ad056c3e2278ad2cc7ec8d"],"published_time":"2026-01-23T15:16:05","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71145","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nusb: phy: isp1301: fix non-OF device reference imbalance\n\nA recent change fixing a device reference leak in a UDC driver\nintroduced a potential use-after-free in the non-OF case as the\nisp1301_get_client() helper only increases the reference count for the\nreturned I2C device in the OF case.\n\nIncrement the reference count also for non-OF so that the caller can\ndecrement it unconditionally.\n\nNote that this is inherently racy just as using the returned I2C device\nis since nothing is preventing the PHY driver from being unbound while\nin use.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":9e-05,"ranking_epss":0.00889,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03bbdaa4da8c6ea0c8431a5011db188a07822c8a","https://git.kernel.org/stable/c/43e58abad6c08c5f0943594126ef4cd6559aac0b","https://git.kernel.org/stable/c/5d3df03f70547d4e3fc10ed4381c052eff51b157","https://git.kernel.org/stable/c/7501ecfe3e5202490c2d13dc7e181203601fcd69","https://git.kernel.org/stable/c/75c5d9bce072abbbc09b701a49869ac23c34a906","https://git.kernel.org/stable/c/b4b64fda4d30a83a7f00e92a0c8a1d47699609f3"],"published_time":"2026-01-23T14:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22977","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sock: fix hardened usercopy panic in sock_recv_errqueue\n\nskbuff_fclone_cache was created without defining a usercopy region,\n[1] unlike skbuff_head_cache which properly whitelists the cb[] field.\n[2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is\nenabled and the kernel attempts to copy sk_buff.cb data to userspace\nvia sock_recv_errqueue() -> put_cmsg().\n\nThe crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone()\n   (from skbuff_fclone_cache) [1]\n2. The skb is cloned via skb_clone() using the pre-allocated fclone\n[3] 3. The cloned skb is queued to sk_error_queue for timestamp\nreporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)\n5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb\n[4] 6. __check_heap_object() fails because skbuff_fclone_cache has no\n   usercopy whitelist [5]\n\nWhen cloned skbs allocated from skbuff_fclone_cache are used in the\nsocket error queue, accessing the sock_exterr_skb structure in skb->cb\nvia put_cmsg() triggers a usercopy hardening violation:\n\n[    5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)!\n[    5.382796] kernel BUG at mm/usercopy.c:102!\n[    5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n[    5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7\n[    5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[    5.384903] RIP: 0010:usercopy_abort+0x6c/0x80\n[    5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490\n[    5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246\n[    5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74\n[    5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0\n[    5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74\n[    5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001\n[    5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00\n[    5.384903] FS:  0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000\n[    5.384903] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0\n[    5.384903] PKRU: 55555554\n[    5.384903] Call Trace:\n[    5.384903]  <TASK>\n[    5.384903]  __check_heap_object+0x9a/0xd0\n[    5.384903]  __check_object_size+0x46c/0x690\n[    5.384903]  put_cmsg+0x129/0x5e0\n[    5.384903]  sock_recv_errqueue+0x22f/0x380\n[    5.384903]  tls_sw_recvmsg+0x7ed/0x1960\n[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    5.384903]  ? schedule+0x6d/0x270\n[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    5.384903]  ? mutex_unlock+0x81/0xd0\n[    5.384903]  ? __pfx_mutex_unlock+0x10/0x10\n[    5.384903]  ? __pfx_tls_sw_recvmsg+0x10/0x10\n[    5.384903]  ? _raw_spin_lock_irqsave+0x8f/0xf0\n[    5.384903]  ? _raw_read_unlock_irqrestore+0x20/0x40\n[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5\n\nThe crash offset 296 corresponds to skb2->cb within skbuff_fclones:\n  - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 -\n  offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 =\n  272 + 24 (inside sock_exterr_skb.ee)\n\nThis patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.\n\n[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885\n[2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104\n[3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566\n[4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491\n[5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04343,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/005671c60fcf1dbdb8bddf12a62568fd5e4ec391","https://git.kernel.org/stable/c/2a71a1a8d0ed718b1c7a9ac61f07e5755c47ae20","https://git.kernel.org/stable/c/582a5e922a9652fcbb7d0165c95d5b20aa37575d","https://git.kernel.org/stable/c/88dd6be7ebb3153b662c2cebcb06e032a92857f5","https://git.kernel.org/stable/c/8c6901aa29626e35045130bac09b75f791acca85","https://git.kernel.org/stable/c/c655d2167bf014d4c61b4faeca59b60ff9b9f6b1","https://git.kernel.org/stable/c/e00b169eaac5f7cdbf710c354c8fa76d02009115"],"published_time":"2026-01-21T14:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-22976","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset\n\n`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the class\nitself is active.\n\nTwo qfq_class objects may point to the same leaf_qdisc. This happens\nwhen:\n\n1. one QFQ qdisc is attached to the dev as the root qdisc, and\n\n2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()\n/ qdisc_put()) and is pending to be destroyed, as in function\ntc_new_tfilter.\n\nWhen packets are enqueued through the root QFQ qdisc, the shared\nleaf_qdisc->q.qlen increases. At the same time, the second QFQ\nqdisc triggers qdisc_put and qdisc_destroy: the qdisc enters\nqfq_reset() with its own q->q.qlen == 0, but its class's leaf\nqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivate\nan inactive aggregate and trigger a null-deref in qfq_deactivate_agg:\n\n[    0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[    0.903571] #PF: supervisor write access in kernel mode\n[    0.903860] #PF: error_code(0x0002) - not-present page\n[    0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0\n[    0.904502] Oops: Oops: 0002 [#1] SMP NOPTI\n[    0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE\n[    0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n[    0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))\n[    0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0\n\nCode starting with the faulting instruction\n===========================================\n   0:\t0f 84 4d 01 00 00    \tje     0x153\n   6:\t48 89 70 18          \tmov    %rsi,0x18(%rax)\n   a:\t8b 4b 10             \tmov    0x10(%rbx),%ecx\n   d:\t48 c7 c2 ff ff ff ff \tmov    $0xffffffffffffffff,%rdx\n  14:\t48 8b 78 08          \tmov    0x8(%rax),%rdi\n  18:\t48 d3 e2             \tshl    %cl,%rdx\n  1b:\t48 21 f2             \tand    %rsi,%rdx\n  1e:\t48 2b 13             \tsub    (%rbx),%rdx\n  21:\t48 8b 30             \tmov    (%rax),%rsi\n  24:\t48 d3 ea             \tshr    %cl,%rdx\n  27:\t8b 4b 18             \tmov    0x18(%rbx),%ecx\n\t...\n[    0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246\n[    0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000\n[    0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[    0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000\n[    0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000\n[    0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880\n[    0.909179] FS:  000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000\n[    0.909572] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0\n[    0.910247] PKRU: 55555554\n[    0.910391] Call Trace:\n[    0.910527]  <TASK>\n[    0.910638]  qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)\n[    0.910826]  qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)\n[    0.911040]  __qdisc_destroy (net/sched/sch_generic.c:1076)\n[    0.911236]  tc_new_tfilter (net/sched/cls_api.c:2447)\n[    0.911447]  rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\n[    0.911663]  ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)\n[    0.911894]  netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n[    0.912100]  netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n[    0.912296]  ? __alloc_skb (net/core/skbuff.c:706)\n[    0.912484]  netlink_sendmsg (net/netlink/af\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04343,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0809c4bc06c9c961222df29f2eccfd449304056f","https://git.kernel.org/stable/c/11bf9134613f6c71fc0ff36c5d8d33856f6ae3bb","https://git.kernel.org/stable/c/43497313d0da3e12b5cfcd97aa17bf48ee663f95","https://git.kernel.org/stable/c/51ffd447bc37bf1a5776b85523f51d2bc69977f6","https://git.kernel.org/stable/c/6116a83ec167d3ab1390cded854d237481f41b63","https://git.kernel.org/stable/c/c1d73b1480235731e35c81df70b08f4714a7d095","https://git.kernel.org/stable/c/cdb24200b043438a144df501f1ebbd926bb1a2c7"],"published_time":"2026-01-21T07:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33230","summary":"NVIDIA Nsight Systems for Linux contains a vulnerability in the .run installer, where an attacker could cause an OS command injection by supplying a malicious string to the installation path. A successful exploit of this vulnerability might lead to escalation of privileges, code execution, data tampering, denial of service, and information disclosure.","cvss":7.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.3,"epss":0.00023,"ranking_epss":0.06115,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://nvd.nist.gov/vuln/detail/CVE-2025-33230","https://nvidia.custhelp.com/app/answers/detail/a_id/5755","https://www.cve.org/CVERecord?id=CVE-2025-33230"],"published_time":"2026-01-20T18:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0906","summary":"Incorrect security UI  in Google Chrome on Android prior to 144.0.7559.59 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page. (Chromium security severity: Low)","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00126,"ranking_epss":0.32103,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/467448811"],"published_time":"2026-01-20T05:16:16","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0907","summary":"Incorrect security UI in Split View in Google Chrome prior to 144.0.7559.59 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00126,"ranking_epss":0.32103,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/444653104"],"published_time":"2026-01-20T05:16:16","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0908","summary":"Use after free in ANGLE in Google Chrome prior to 144.0.7559.59 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Low)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00047,"ranking_epss":0.14756,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/452209503"],"published_time":"2026-01-20T05:16:16","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0901","summary":"Inappropriate implementation in Blink in Google Chrome on Android prior to 144.0.7559.59 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: High)","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00038,"ranking_epss":0.11596,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/40057499"],"published_time":"2026-01-20T05:16:15","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0902","summary":"Inappropriate implementation in V8 in Google Chrome prior to 144.0.7559.59 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00105,"ranking_epss":0.28759,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/469143679"],"published_time":"2026-01-20T05:16:15","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0903","summary":"Inappropriate implementation in Downloads in Google Chrome on Windows prior to 144.0.7559.59 allowed a remote attacker to bypass dangerous file type protections via a malicious file. (Chromium security severity: Medium)","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00038,"ranking_epss":0.1164,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/444803530"],"published_time":"2026-01-20T05:16:15","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0904","summary":"Incorrect security UI in Digital Credentials in Google Chrome prior to 144.0.7559.59 allowed a remote attacker to perform domain spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00038,"ranking_epss":0.11596,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/452209495"],"published_time":"2026-01-20T05:16:15","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0905","summary":"Insufficient policy enforcement in Network in Google Chrome prior to 144.0.7559.59 allowed an attack who obtained a network log file to potentially obtain potentially sensitive information via a network log file. (Chromium security severity: Medium)","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00032,"ranking_epss":0.09385,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/465466773"],"published_time":"2026-01-20T05:16:15","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0900","summary":"Inappropriate implementation in V8 in Google Chrome prior to 144.0.7559.59 allowed a remote attacker to potentially exploit object corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00035,"ranking_epss":0.10293,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/465730465"],"published_time":"2026-01-20T05:16:14","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2026-0899","summary":"Out of bounds memory access in V8 in Google Chrome prior to 144.0.7559.59 allowed a remote attacker to potentially exploit object corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00035,"ranking_epss":0.10293,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2026/01/stable-channel-update-for-desktop_13.html","https://issues.chromium.org/issues/458914193"],"published_time":"2026-01-20T05:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33206","summary":"NVIDIA NSIGHT Graphics for Linux contains a vulnerability where an attacker could cause command injection. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and denial of service.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00025,"ranking_epss":0.06697,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://nvd.nist.gov/vuln/detail/CVE-2025-33206","https://nvidia.custhelp.com/app/answers/detail/a_id/5738","https://www.cve.org/CVERecord?id=CVE-2025-33206"],"published_time":"2026-01-14T19:16:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71142","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncpuset: fix warning when disabling remote partition\n\nA warning was triggered as follows:\n\nWARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110\nRIP: 0010:remote_partition_disable+0xf7/0x110\nRSP: 0018:ffffc90001947d88 EFLAGS: 00000206\nRAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40\nRDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000\nRBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8\nR13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n update_prstate+0x2d3/0x580\n cpuset_partition_write+0x94/0xf0\n kernfs_fop_write_iter+0x147/0x200\n vfs_write+0x35d/0x500\n ksys_write+0x66/0xe0\n do_syscall_64+0x6b/0x390\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f55c8cd4887\n\nReproduction steps (on a 16-CPU machine):\n\n        # cd /sys/fs/cgroup/\n        # mkdir A1\n        # echo +cpuset > A1/cgroup.subtree_control\n        # echo \"0-14\" > A1/cpuset.cpus.exclusive\n        # mkdir A1/A2\n        # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive\n        # echo \"root\" > A1/A2/cpuset.cpus.partition\n        # echo 0 > /sys/devices/system/cpu/cpu15/online\n        # echo member > A1/A2/cpuset.cpus.partition\n\nWhen CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs\nremain available for the top_cpuset, forcing partitions to share CPUs with\nthe top_cpuset. In this scenario, disabling the remote partition triggers\na warning stating that effective_xcpus is not a subset of\nsubpartitions_cpus. Partitions should be invalidated in this case to\ninform users that the partition is now invalid(cpus are shared with\ntop_cpuset).\n\nTo fix this issue:\n1. Only emit the warning only if subpartitions_cpus is not empty and the\n   effective_xcpus is not a subset of subpartitions_cpus.\n2. During the CPU hotplug process, invalidate partitions if\n   subpartitions_cpus is empty.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5d8b9d38a7676be7bb5e7d57f92156a98dab39fb","https://git.kernel.org/stable/c/aa7d3a56a20f07978d9f401e13637a6479b13bd0"],"published_time":"2026-01-14T15:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71143","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nclk: samsung: exynos-clkout: Assign .num before accessing .hws\n\nCommit f316cdff8d67 (\"clk: Annotate struct clk_hw_onecell_data with\n__counted_by\") annotated the hws member of 'struct clk_hw_onecell_data'\nwith __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS)\nabout the number of elements in .hws[], so that it can warn when .hws[]\nis accessed out of bounds. As noted in that change, the __counted_by\nmember must be initialized with the number of elements before the first\narray access happens, otherwise there will be a warning from each access\nprior to the initialization because the number of elements is zero. This\noccurs in exynos_clkout_probe() due to .num being assigned after .hws[]\nhas been accessed:\n\n  UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18\n  index 0 is out of range for type 'clk_hw *[*]'\n\nMove the .num initialization to before the first access of .hws[],\nclearing up the warning.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/a317f63255ebc3dac378c79c5bff4f8d0561c290","https://git.kernel.org/stable/c/cf33f0b7df13685234ccea7be7bfe316b60db4db","https://git.kernel.org/stable/c/eb1f3a6ab3efee2b52361879cdc2dc6b11f499c0","https://git.kernel.org/stable/c/fbf57f5e453dadadb3d29b2d1dbe067e3dc4e236"],"published_time":"2026-01-14T15:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71144","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: ensure context reset on disconnect()\n\nAfter the blamed commit below, if the MPC subflow is already in TCP_CLOSE\nstatus or has fallback to TCP at mptcp_disconnect() time,\nmptcp_do_fastclose() skips setting the `send_fastclose flag` and the later\n__mptcp_close_ssk() does not reset anymore the related subflow context.\n\nAny later connection will be created with both the `request_mptcp` flag\nand the msk-level fallback status off (it is unconditionally cleared at\nMPTCP disconnect time), leading to a warning in subflow_data_ready():\n\n  WARNING: CPU: 26 PID: 8996 at net/mptcp/subflow.c:1519 subflow_data_ready (net/mptcp/subflow.c:1519 (discriminator 13))\n  Modules linked in:\n  CPU: 26 UID: 0 PID: 8996 Comm: syz.22.39 Not tainted 6.18.0-rc7-05427-g11fc074f6c36 #1 PREEMPT(voluntary)\n  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n  RIP: 0010:subflow_data_ready (net/mptcp/subflow.c:1519 (discriminator 13))\n  Code: 90 0f 0b 90 90 e9 04 fe ff ff e8 b7 1e f5 fe 89 ee bf 07 00 00 00 e8 db 19 f5 fe 83 fd 07 0f 84 35 ff ff ff e8 9d 1e f5 fe 90 <0f> 0b 90 e9 27 ff ff ff e8 8f 1e f5 fe 4c 89 e7 48 89 de e8 14 09\n  RSP: 0018:ffffc9002646fb30 EFLAGS: 00010293\n  RAX: 0000000000000000 RBX: ffff88813b218000 RCX: ffffffff825c8435\n  RDX: ffff8881300b3580 RSI: ffffffff825c8443 RDI: 0000000000000005\n  RBP: 000000000000000b R08: ffffffff825c8435 R09: 000000000000000b\n  R10: 0000000000000005 R11: 0000000000000007 R12: ffff888131ac0000\n  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n  FS:  00007f88330af6c0(0000) GS:ffff888a93dd2000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f88330aefe8 CR3: 000000010ff59000 CR4: 0000000000350ef0\n  Call Trace:\n   <TASK>\n   tcp_data_ready (net/ipv4/tcp_input.c:5356)\n   tcp_data_queue (net/ipv4/tcp_input.c:5445)\n   tcp_rcv_state_process (net/ipv4/tcp_input.c:7165)\n   tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1955)\n   __release_sock (include/net/sock.h:1158 (discriminator 6) net/core/sock.c:3180 (discriminator 6))\n   release_sock (net/core/sock.c:3737)\n   mptcp_sendmsg (net/mptcp/protocol.c:1763 net/mptcp/protocol.c:1857)\n   inet_sendmsg (net/ipv4/af_inet.c:853 (discriminator 7))\n   __sys_sendto (net/socket.c:727 (discriminator 15) net/socket.c:742 (discriminator 15) net/socket.c:2244 (discriminator 15))\n   __x64_sys_sendto (net/socket.c:2247)\n   do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n  RIP: 0033:0x7f883326702d\n\nAddress the issue setting an explicit `fastclosing` flag at fastclose\ntime, and checking such flag after mptcp_do_fastclose().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.06957,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1c7c3a9314d8a7fc0e9a508606466a967c8e774a","https://git.kernel.org/stable/c/226fff52e7ed9fc8cd63327133739b3d92537ffd","https://git.kernel.org/stable/c/5c7c7135468f3fc6379cde9777a2c18bfe92d82f","https://git.kernel.org/stable/c/86730ac255b0497a272704de9a1df559f5d6602e","https://git.kernel.org/stable/c/f1a77dfc3b045c3dd5f6e64189b9f52b90399f07"],"published_time":"2026-01-14T15:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71133","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: avoid invalid read in irdma_net_event\n\nirdma_net_event() should not dereference anything from \"neigh\" (alias\n\"ptr\") until it has checked that the event is NETEVENT_NEIGH_UPDATE.\nOther events come with different structures pointed to by \"ptr\" and they\nmay be smaller than struct neighbour.\n\nMove the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.\n\nThe bug is mostly harmless, but it triggers KASAN on debug kernels:\n\n BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma]\n Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554\n\n CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1\n Hardware name: [...]\n Workqueue: events rt6_probe_deferred\n Call Trace:\n  <IRQ>\n  dump_stack_lvl+0x60/0xb0\n  print_address_description.constprop.0+0x2c/0x3f0\n  print_report+0xb4/0x270\n  kasan_report+0x92/0xc0\n  irdma_net_event+0x32e/0x3b0 [irdma]\n  notifier_call_chain+0x9e/0x180\n  atomic_notifier_call_chain+0x5c/0x110\n  rt6_do_redirect+0xb91/0x1080\n  tcp_v6_err+0xe9b/0x13e0\n  icmpv6_notify+0x2b2/0x630\n  ndisc_redirect_rcv+0x328/0x530\n  icmpv6_rcv+0xc16/0x1360\n  ip6_protocol_deliver_rcu+0xb84/0x12e0\n  ip6_input_finish+0x117/0x240\n  ip6_input+0xc4/0x370\n  ipv6_rcv+0x420/0x7d0\n  __netif_receive_skb_one_core+0x118/0x1b0\n  process_backlog+0xd1/0x5d0\n  __napi_poll.constprop.0+0xa3/0x440\n  net_rx_action+0x78a/0xba0\n  handle_softirqs+0x2d4/0x9c0\n  do_softirq+0xad/0xe0\n  </IRQ>","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/305c02e541befe4a44ffde30ed374970f41aeb6c","https://git.kernel.org/stable/c/6f05611728e9d0ab024832a4f1abb74a5f5d0bb0","https://git.kernel.org/stable/c/bf197c7c79ef6458d1ee84dd7db251b51784885f","https://git.kernel.org/stable/c/d9b9affd103f51b42322da4ed5ac025b560bc354","https://git.kernel.org/stable/c/db93ae6fa66f1c61ae63400191195e3ee58021da","https://git.kernel.org/stable/c/fc23d05f0b3fb4d80657e7afebae2cae686b31c8"],"published_time":"2026-01-14T15:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71134","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: change all pageblocks migrate type on coalescing\n\nWhen a page is freed it coalesces with a buddy into a higher order page\nwhile possible.  When the buddy page migrate type differs, it is expected\nto be updated to match the one of the page being freed.\n\nHowever, only the first pageblock of the buddy page is updated, while the\nrest of the pageblocks are left unchanged.\n\nThat causes warnings in later expand() and other code paths (like below),\nsince an inconsistency between migration type of the list containing the\npage and the page-owned pageblocks migration types is introduced.\n\n[  308.986589] ------------[ cut here ]------------\n[  308.987227] page type is 0, passed migratetype is 1 (nr=256)\n[  308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270\n[  308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E)\n[  308.987439] Unloaded tainted modules: hmac_s390(E):2\n[  308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G            E       6.18.0-gcc-bpf-debug #431 PREEMPT\n[  308.987657] Tainted: [E]=UNSIGNED_MODULE\n[  308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0)\n[  308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270)\n[  308.987676]            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3\n[  308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88\n[  308.987688]            0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300\n[  308.987692]            0000000000000008 0000034998d57290 000002be00000100 0000023e00000008\n[  308.987696]            0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0\n[  308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4\n                          00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60\n                         #00000349976fa5fc: af000000\t\tmc\t0,0\n                         >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498\n                          00000349976fa604: b9040026\t\tlgr\t%r2,%r6\n                          00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906\n                          00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0\n                          00000349976fa614: af000000\t\tmc\t0,0\n[  308.987734] Call Trace:\n[  308.987738]  [<00000349976fa600>] expand+0x240/0x270\n[  308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270)\n[  308.987749]  [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940\n[  308.987754]  [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0\n[  308.987759]  [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40\n[  308.987763]  [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0\n[  308.987768]  [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400\n[  308.987774]  [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220\n[  308.987781]  [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0\n[  308.987786]  [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0\n[  308.987791]  [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240\n[  308.987799]  [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210\n[  308.987804]  [<00000349976cb0\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7838a4eb8a1d23160bd3f588ea7f2b8f7c00c55b","https://git.kernel.org/stable/c/914769048818021556c940b9163e8056be9507dd","https://git.kernel.org/stable/c/a794d65b132107a085d165caba33aae1101316a5"],"published_time":"2026-01-14T15:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71135","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt()\n\nThe variable mddev->private is first assigned to conf and then checked:\n\n  conf = mddev->private;\n  if (!conf) ...\n\nIf conf is NULL, then mddev->private is also NULL. In this case,\nnull-pointer dereferences can occur when calling raid5_quiesce():\n\n  raid5_quiesce(mddev, true);\n  raid5_quiesce(mddev, false);\n\nsince mddev->private is assigned to conf again in raid5_quiesce(), and conf\nis dereferenced in several places, for example:\n\n  conf->quiesce = 0;\n  wake_up(&conf->wait_for_quiescent);\n\nTo fix this issue, the function should unlock mddev and return before\ninvoking raid5_quiesce() when conf is NULL, following the existing pattern\nin raid5_change_consistency_policy().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/20597b7229aea8b5bc45cd92097640257c7fc33b","https://git.kernel.org/stable/c/7ad6ef91d8745d04aff9cce7bdbc6320d8e05fe9","https://git.kernel.org/stable/c/e5abb6af905de6b2fead8a0b3f32ab0b81468a01"],"published_time":"2026-01-14T15:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71136","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()\n\nIt's possible for cp_read() and hdmi_read() to return -EIO. Those\nvalues are further used as indexes for accessing arrays.\n\nFix that by checking return values where it's needed.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/60dde0960e3ead8a9569f6c494d90d0232ac0983","https://git.kernel.org/stable/c/8163419e3e05d71dcfa8fb49c8fdf8d76908fe51","https://git.kernel.org/stable/c/a73881ae085db5702d8b13e2fc9f78d51c723d3f","https://git.kernel.org/stable/c/b693d48a6ed0cd09171103ad418e4a693203d6e4","https://git.kernel.org/stable/c/d6a22a4a96e4dfe6897cb3532d2b3016d87706f0","https://git.kernel.org/stable/c/f81ee181cb036d046340c213091b69d9a8701a76","https://git.kernel.org/stable/c/f913b9a2ccd6114b206b9e91dae5e3dc13a415a0"],"published_time":"2026-01-14T15:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71137","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: fix \"UBSAN: shift-out-of-bounds error\"\n\nThis patch ensures that the RX ring size (rx_pending) is not\nset below the permitted length. This avoids UBSAN\nshift-out-of-bounds errors when users passes small or zero\nring sizes via ethtool -G.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/442848e457f5a9f71a4e7e14d24d73dae278ebe3","https://git.kernel.org/stable/c/4cc4cfe4d23c883120b6f3d41145edbaa281f2ab","https://git.kernel.org/stable/c/5d8dfa3abb9a845302e021cf9c92d941abbc011a","https://git.kernel.org/stable/c/658caf3b8aad65f8b8e102670ca4f68c7030f655","https://git.kernel.org/stable/c/85f4b0c650d9f9db10bda8d3acfa1af83bf78cf7","https://git.kernel.org/stable/c/aa743b0d98448282b2cb37356db8db2a48524624","https://git.kernel.org/stable/c/b23a2e15589466a027c9baa3fb5813c9f6a6c6dc"],"published_time":"2026-01-14T15:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71138","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dpu: Add missing NULL pointer check for pingpong interface\n\nIt is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a\nsingle place the check is missing.\nAlso use convenient locals instead of phys_enc->* where available.\n\nPatchwork: https://patchwork.freedesktop.org/patch/693860/","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04182,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/35ea3282136a630a3fd92b76f5a3a02651145ef1","https://git.kernel.org/stable/c/471baae774a30a04cf066907b60eaf3732928cb7","https://git.kernel.org/stable/c/678d1c86566dfbb247ba25482d37fddde6140cc9","https://git.kernel.org/stable/c/88733a0b64872357e5ecd82b7488121503cb9cc6"],"published_time":"2026-01-14T15:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71139","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nkernel/kexec: fix IMA when allocation happens in CMA area\n\n*** Bug description ***\n\nWhen I tested kexec with the latest kernel, I ran into the following warning:\n\n[   40.712410] ------------[ cut here ]------------\n[   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198\n[...]\n[   40.816047] Call trace:\n[   40.818498]  kimage_map_segment+0x144/0x198 (P)\n[   40.823221]  ima_kexec_post_load+0x58/0xc0\n[   40.827246]  __do_sys_kexec_file_load+0x29c/0x368\n[...]\n[   40.855423] ---[ end trace 0000000000000000 ]---\n\n*** How to reproduce ***\n\nThis bug is only triggered when the kexec target address is allocated in\nthe CMA area. If no CMA area is reserved in the kernel, use the \"cma=\"\noption in the kernel command line to reserve one.\n\n*** Root cause ***\nThe commit 07d24902977e (\"kexec: enable CMA based contiguous\nallocation\") allocates the kexec target address directly on the CMA area\nto avoid copying during the jump. In this case, there is no IND_SOURCE\nfor the kexec segment.  But the current implementation of\nkimage_map_segment() assumes that IND_SOURCE pages exist and map them\ninto a contiguous virtual address by vmap().\n\n*** Solution ***\nIf IMA segment is allocated in the CMA area, use its page_address()\ndirectly.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/a3785ae5d334bb71d47a593d54c686a03fb9d136","https://git.kernel.org/stable/c/a843e4155c83211c55b1b6cc17eab27a6a2c5b6f"],"published_time":"2026-01-14T15:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71141","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/tilcdc: Fix removal actions in case of failed probe\n\nThe drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers\nshould only be called when the device has been successfully registered.\nCurrently, these functions are called unconditionally in tilcdc_fini(),\nwhich causes warnings during probe deferral scenarios.\n\n[    7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68\n...\n[    8.005820]  drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108\n[    8.005858]  drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8\n[    8.005885]  drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144\n[    8.005911]  drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc]\n[    8.005957]  tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]\n\nFix this by rewriting the failed probe cleanup path using the standard\ngoto error handling pattern, which ensures that cleanup functions are\nonly called on successfully initialized resources. Additionally, remove\nthe now-unnecessary is_registered flag.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/21e52dc7762908c3d499cfb493d1b8281fc1d3ab","https://git.kernel.org/stable/c/71be8825e83c90c1e020feb77b29e6a99629e642","https://git.kernel.org/stable/c/a585c7ef9cabda58088916baedc6573e9a5cd2a7"],"published_time":"2026-01-14T15:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71123","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix string copying in parse_apply_sb_mount_options()\n\nstrscpy_pad() can't be used to copy a non-NUL-term string into a NUL-term\nstring of possibly bigger size.  Commit 0efc5990bca5 (\"string.h: Introduce\nmemtostr() and memtostr_pad()\") provides additional information in that\nregard.  So if this happens, the following warning is observed:\n\nstrnlen: detected buffer overflow: 65 byte read of buffer size 64\nWARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032\nModules linked in:\nCPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032\nCall Trace:\n <TASK>\n __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039\n strnlen include/linux/fortify-string.h:235 [inline]\n sized_strscpy include/linux/fortify-string.h:309 [inline]\n parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline]\n __ext4_fill_super fs/ext4/super.c:5261 [inline]\n ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706\n get_tree_bdev_flags+0x387/0x620 fs/super.c:1636\n vfs_get_tree+0x93/0x380 fs/super.c:1814\n do_new_mount fs/namespace.c:3553 [inline]\n path_mount+0x6ae/0x1f70 fs/namespace.c:3880\n do_mount fs/namespace.c:3893 [inline]\n __do_sys_mount fs/namespace.c:4103 [inline]\n __se_sys_mount fs/namespace.c:4080 [inline]\n __x64_sys_mount+0x280/0x300 fs/namespace.c:4080\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nSince userspace is expected to provide s_mount_opts field to be at most 63\ncharacters long with the ending byte being NUL-term, use a 64-byte buffer\nwhich matches the size of s_mount_opts, so that strscpy_pad() does its job\nproperly.  Return with error if the user still managed to provide a\nnon-NUL-term string here.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/52ac96c4a2dd7bc47666000440b0602d9742e820","https://git.kernel.org/stable/c/5bbacbbf1ca4419861dca3c6b82707c10e9c021c","https://git.kernel.org/stable/c/6e37143560e37869d51b7d9e0ac61fc48895f8a0","https://git.kernel.org/stable/c/902ca2356f1e3ec5355c5808ad5d3f9d0095b0cc","https://git.kernel.org/stable/c/db9ee13fab0267eccf6544ee35b16c9522db9aac","https://git.kernel.org/stable/c/ee5a977b4e771cc181f39d504426dbd31ed701cc"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71124","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/a6xx: move preempt_prepare_postamble after error check\n\nMove the call to preempt_prepare_postamble() after verifying that\npreempt_postamble_ptr is valid. If preempt_postamble_ptr is NULL,\ndereferencing it in preempt_prepare_postamble() would lead to a crash.\n\nThis change avoids calling the preparation function when the\npostamble allocation has failed, preventing potential NULL pointer\ndereference and ensuring proper error handling.\n\nPatchwork: https://patchwork.freedesktop.org/patch/687659/","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2c46497eb148ec61909f4101b8443f3c4c2daaec","https://git.kernel.org/stable/c/ef3b04091fd8bc737dc45312375df8625b8318e2"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71125","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not register unsupported perf events\n\nSynthetic events currently do not have a function to register perf events.\nThis leads to calling the tracepoint register functions with a NULL\nfunction pointer which triggers:\n\n ------------[ cut here ]------------\n WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:tracepoint_add_func+0x357/0x370\n Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f\n RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246\n RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000\n RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8\n RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780\n R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a\n R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78\n FS:  00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0\n Call Trace:\n  <TASK>\n  tracepoint_probe_register+0x5d/0x90\n  synth_event_reg+0x3c/0x60\n  perf_trace_event_init+0x204/0x340\n  perf_trace_init+0x85/0xd0\n  perf_tp_event_init+0x2e/0x50\n  perf_try_init_event+0x6f/0x230\n  ? perf_event_alloc+0x4bb/0xdc0\n  perf_event_alloc+0x65a/0xdc0\n  __se_sys_perf_event_open+0x290/0x9f0\n  do_syscall_64+0x93/0x7b0\n  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  ? trace_hardirqs_off+0x53/0xc0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInstead, have the code return -ENODEV, which doesn't warn and has perf\nerror out with:\n\n # perf record -e synthetic:futex_wait\nError:\nThe sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).\n\"dmesg | grep -i perf\" may provide additional information.\n\nIdeally perf should support synthetic events, but for now just fix the\nwarning. The support can come later.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3437c775bf209c674ad66304213b6b3c3b1b3f69","https://git.kernel.org/stable/c/65b1971147ec12f0b1cee0811c859a3d7d9b04ce","https://git.kernel.org/stable/c/6819bc6285c0ff835f67cfae7efebc03541782f6","https://git.kernel.org/stable/c/6d15f08e6d8d4b4fb02d90805ea97f3e2c1d6fbc","https://git.kernel.org/stable/c/6df47e5bb9b62d72f186f826ab643ea1856877c7","https://git.kernel.org/stable/c/ef7f38df890f5dcd2ae62f8dbde191d72f3bebae","https://git.kernel.org/stable/c/f7305697b60d79bc69c0a6e280fc931b4e8862dd"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71126","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: avoid deadlock on fallback while reinjecting\n\nJakub reported an MPTCP deadlock at fallback time:\n\n WARNING: possible recursive locking detected\n 6.18.0-rc7-virtme #1 Not tainted\n --------------------------------------------\n mptcp_connect/20858 is trying to acquire lock:\n ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280\n\n but task is already holding lock:\n ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0\n\n other info that might help us debug this:\n  Possible unsafe locking scenario:\n\n        CPU0\n        ----\n   lock(&msk->fallback_lock);\n   lock(&msk->fallback_lock);\n\n  *** DEADLOCK ***\n\n  May be due to missing lock nesting notation\n\n 3 locks held by mptcp_connect/20858:\n  #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0\n  #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0\n  #2: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0\n\n stack backtrace:\n CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full)\n Hardware name: Bochs, BIOS Bochs 01/01/2011\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x6f/0xa0\n  print_deadlock_bug.cold+0xc0/0xcd\n  validate_chain+0x2ff/0x5f0\n  __lock_acquire+0x34c/0x740\n  lock_acquire.part.0+0xbc/0x260\n  _raw_spin_lock_bh+0x38/0x50\n  __mptcp_try_fallback+0xd8/0x280\n  mptcp_sendmsg_frag+0x16c2/0x3050\n  __mptcp_retrans+0x421/0xaa0\n  mptcp_release_cb+0x5aa/0xa70\n  release_sock+0xab/0x1d0\n  mptcp_sendmsg+0xd5b/0x1bc0\n  sock_write_iter+0x281/0x4d0\n  new_sync_write+0x3c5/0x6f0\n  vfs_write+0x65e/0xbb0\n  ksys_write+0x17e/0x200\n  do_syscall_64+0xbb/0xfd0\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7fa5627cbc5e\n Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa\n RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\n RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e\n RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005\n RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920\n R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9c\n\nThe packet scheduler could attempt a reinjection after receiving an\nMP_FAIL and before the infinite map has been transmitted, causing a\ndeadlock since MPTCP needs to do the reinjection atomically from WRT\nfallback.\n\nAddress the issue explicitly avoiding the reinjection in the critical\nscenario. Note that this is the only fallback critical section that\ncould potentially send packets and hit the double-lock.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02392,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0107442e82c0f8d6010e07e6030741c59c520d6e","https://git.kernel.org/stable/c/0ca9fb4335e726dab4f23b3bfe87271d8f005f41","https://git.kernel.org/stable/c/252892d5a6a2f163ce18f32716e46fa4da7d4e79","https://git.kernel.org/stable/c/50f47c02be419bf0a3ae94c118addf67beef359f","https://git.kernel.org/stable/c/ffb8c27b0539dd90262d1021488e7817fae57c42"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71127","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Discard Beacon frames to non-broadcast address\n\nBeacon frames are required to be sent to the broadcast address, see IEEE\nStd 802.11-2020, 11.1.3.1 (\"The Address 1 field of the Beacon .. frame\nshall be set to the broadcast address\"). A unicast Beacon frame might be\nused as a targeted attack to get one of the associated STAs to do\nsomething (e.g., using CSA to move it to another channel). As such, it\nis better have strict filtering for this on the received side and\ndiscard all Beacon frames that are sent to an unexpected address.\n\nThis is even more important for cases where beacon protection is used.\nThe current implementation in mac80211 is correctly discarding unicast\nBeacon frames if the Protected Frame bit in the Frame Control field is\nset to 0. However, if that bit is set to 1, the logic used for checking\nfor configured BIGTK(s) does not actually work. If the driver does not\nhave logic for dropping unicast Beacon frames with Protected Frame bit\n1, these frames would be accepted in mac80211 processing as valid Beacon\nframes even though they are not protected. This would allow beacon\nprotection to be bypassed. While the logic for checking beacon\nprotection could be extended to cover this corner case, a more generic\ncheck for discard all Beacon frames based on A1=unicast address covers\nthis without needing additional changes.\n\nAddress all these issues by dropping received Beacon frames if they are\nsent to a non-broadcast address.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0a59a3895f804469276d188effa511c72e752f35","https://git.kernel.org/stable/c/193d18f60588e95d62e0f82b6a53893e5f2f19f8","https://git.kernel.org/stable/c/6e5bff40bb38741e40c33043ba0816fba5f93661","https://git.kernel.org/stable/c/7b240a8935d554ad36a52c2c37c32039f9afaef2","https://git.kernel.org/stable/c/88aab153d1528bc559292a12fb5105ee97528e1f","https://git.kernel.org/stable/c/a21704df4024708be698fb3fd5830d5b113b70e0","https://git.kernel.org/stable/c/be0974be5c42584e027883ac2af7dab5e950098c"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71128","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nerspan: Initialize options_len before referencing options.\n\nThe struct ip_tunnel_info has a flexible array member named\noptions that is protected by a counted_by(options_len)\nattribute.\n\nThe compiler will use this information to enforce runtime bounds\nchecking deployed by FORTIFY_SOURCE string helpers.\n\nAs laid out in the GCC documentation, the counter must be\ninitialized before the first reference to the flexible array\nmember.\n\nAfter scanning through the files that use struct ip_tunnel_info\nand also refer to options or options_len, it appears the normal\ncase is to use the ip_tunnel_info_opts_set() helper.\n\nSaid helper would initialize options_len properly before copying\ndata into options, however in the GRE ERSPAN code a partial\nupdate is done, preventing the use of the helper function.\n\nBefore this change the handling of ERSPAN traffic in GRE tunnels\nwould cause a kernel panic when the kernel is compiled with\nGCC 15+ and having FORTIFY_SOURCE configured:\n\nmemcpy: detected buffer overflow: 4 byte write of buffer size 0\n\nCall Trace:\n <IRQ>\n __fortify_panic+0xd/0xf\n erspan_rcv.cold+0x68/0x83\n ? ip_route_input_slow+0x816/0x9d0\n gre_rcv+0x1b2/0x1c0\n gre_rcv+0x8e/0x100\n ? raw_v4_input+0x2a0/0x2b0\n ip_protocol_deliver_rcu+0x1ea/0x210\n ip_local_deliver_finish+0x86/0x110\n ip_local_deliver+0x65/0x110\n ? ip_rcv_finish_core+0xd6/0x360\n ip_rcv+0x186/0x1a0\n\nReported-at: https://launchpad.net/bugs/2129580","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/35ddf66c65eff93fff91406756ba273600bf61a3","https://git.kernel.org/stable/c/b282b2a9eed848587c1348abdd5d83fa346a2743"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71129","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Sign extend kfunc call arguments\n\nThe kfunc calls are native calls so they should follow LoongArch calling\nconventions. Sign extend its arguments properly to avoid kernel panic.\nThis is done by adding a new emit_abi_ext() helper. The emit_abi_ext()\nhelper performs extension in place meaning a value already store in the\ntarget register (Note: this is different from the existing sign_extend()\nhelper and thus we can't reuse it).","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04182,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d666db731e95890e0eda7ea61bc925fd2be90c6","https://git.kernel.org/stable/c/321993a874f571a94b5a596f1132f798c663b56e","https://git.kernel.org/stable/c/3f5a238f24d7b75f9efe324d3539ad388f58536e","https://git.kernel.org/stable/c/fd43edf357a3a1f5ed1c4bf450b60001c9091c39"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71130","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer\n\nInitialize the eb.vma array with values of 0 when the eb structure is\nfirst set up. In particular, this sets the eb->vma[i].vma pointers to\nNULL, simplifying cleanup and getting rid of the bug described below.\n\nDuring the execution of eb_lookup_vmas(), the eb->vma array is\nsuccessively filled up with struct eb_vma objects. This process includes\ncalling eb_add_vma(), which might fail; however, even in the event of\nfailure, eb->vma[i].vma is set for the currently processed buffer.\n\nIf eb_add_vma() fails, eb_lookup_vmas() returns with an error, which\nprompts a call to eb_release_vmas() to clean up the mess. Since\neb_lookup_vmas() might fail during processing any (possibly not first)\nbuffer, eb_release_vmas() checks whether a buffer's vma is NULL to know\nat what point did the lookup function fail.\n\nIn eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper\nfunction eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is\nset to NULL in case i915_gem_object_userptr_submit_init() fails; the\ncurrent one needs to be cleaned up by eb_release_vmas() at this point,\nso the next one is set. If eb_add_vma() fails, neither the current nor\nthe next vma is set to NULL, which is a source of a NULL deref bug\ndescribed in the issue linked in the Closes tag.\n\nWhen entering eb_lookup_vmas(), the vma pointers are set to the slab\npoison value, instead of NULL. This doesn't matter for the actual\nlookup, since it gets overwritten anyway, however the eb_release_vmas()\nfunction only recognizes NULL as the stopping value, hence the pointers\nare being set to NULL as they go in case of intermediate failure. This\npatch changes the approach to filling them all with NULL at the start\ninstead, rather than handling that manually during failure.\n\n(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04428,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0336188cc85d0eab8463bd1bbd4ded4e9602de8b","https://git.kernel.org/stable/c/24d55ac8e31d2f8197bfad71ffcb3bae21ed7117","https://git.kernel.org/stable/c/25d69e07770745992387c016613fd7ac8eaf9893","https://git.kernel.org/stable/c/4fe2bd195435e71c117983d87f278112c5ab364c","https://git.kernel.org/stable/c/63f23aa2fbb823c8b15a29269fde220d227ce5b3"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71131","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: seqiv - Do not use req->iv after crypto_aead_encrypt\n\nAs soon as crypto_aead_encrypt is called, the underlying request\nmay be freed by an asynchronous completion.  Thus dereferencing\nreq->iv after it returns is invalid.\n\nInstead of checking req->iv against info, create a new variable\nunaligned_info and use it for that purpose instead.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0279978adec6f1296af66b642cce641c6580be46","https://git.kernel.org/stable/c/18202537856e0fae079fed2c9308780bcff2bb9d","https://git.kernel.org/stable/c/50f196d2bbaee4ab2494bb1b0d294deba292951a","https://git.kernel.org/stable/c/50fdb78b7c0bcc550910ef69c0984e751cac72fa","https://git.kernel.org/stable/c/5476f7f8a311236604b78fcc5b2a63b3a61b0169","https://git.kernel.org/stable/c/baf0e2d1e03ddb04781dfe7f22a654d3611f69b2","https://git.kernel.org/stable/c/ccbb96434d88e32358894c879457b33f7508e798"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71132","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmc91x: fix broken irq-context in PREEMPT_RT\n\nWhen smc91x.c is built with PREEMPT_RT, the following splat occurs\nin FVP_RevC:\n\n[   13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000\n[   13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106]\n[   13.062137]      preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work\n[   13.062266] C\n** replaying previous printk message **\n[   13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}\n[   13.062353] Hardware name:  , BIOS\n[   13.062382] Workqueue: mld mld_ifc_work\n[   13.062469] Call trace:\n[   13.062494]  show_stack+0x24/0x40 (C)\n[   13.062602]  __dump_stack+0x28/0x48\n[   13.062710]  dump_stack_lvl+0x7c/0xb0\n[   13.062818]  dump_stack+0x18/0x34\n[   13.062926]  process_scheduled_works+0x294/0x450\n[   13.063043]  worker_thread+0x260/0x3d8\n[   13.063124]  kthread+0x1c4/0x228\n[   13.063235]  ret_from_fork+0x10/0x20\n\nThis happens because smc_special_trylock() disables IRQs even on PREEMPT_RT,\nbut smc_special_unlock() does not restore IRQs on PREEMPT_RT.\nThe reason is that smc_special_unlock() calls spin_unlock_irqrestore(),\nand rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke\nrcu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero.\n\nTo address this issue, replace smc_special_trylock() with spin_trylock_irqsave().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1c4cb705e733250d13243f6a69b8b5a92e39b9f6","https://git.kernel.org/stable/c/36561b86cb2501647662cfaf91286dd6973804a6","https://git.kernel.org/stable/c/6402078bd9d1ed46e79465e1faaa42e3458f8a33","https://git.kernel.org/stable/c/9d222141b00156509d67d80c771fbefa92c43ace","https://git.kernel.org/stable/c/b6018d5c1a8f09d5efe4d6961d7ee45fdf3a7ce3","https://git.kernel.org/stable/c/ef277ae121b3249c99994652210a326b52d527b0"],"published_time":"2026-01-14T15:16:02","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71114","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nvia_wdt: fix critical boot hang due to unnamed resource allocation\n\nThe VIA watchdog driver uses allocate_resource() to reserve a MMIO\nregion for the watchdog control register. However, the allocated\nresource was not given a name, which causes the kernel resource tree\nto contain an entry marked as \"<BAD>\" under /proc/iomem on x86\nplatforms.\n\nDuring boot, this unnamed resource can lead to a critical hang because\nsubsequent resource lookups and conflict checks fail to handle the\ninvalid entry properly.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1d56025a3af50db0f3da2792f41eb9943eee5324","https://git.kernel.org/stable/c/47c910965c936724070d2a8094a4c3ed8f452856","https://git.kernel.org/stable/c/7aa31ee9ec92915926e74731378c009c9cc04928","https://git.kernel.org/stable/c/c6a2dd4f2e4e6cbdfe7a1618160281af897b75db","https://git.kernel.org/stable/c/c7b986adc9e9336066350542ac5a2005d305ae78","https://git.kernel.org/stable/c/d2c7c90aca7b37f60f16b2bedcfeb16204f2f35d","https://git.kernel.org/stable/c/f7b6370d0fbee06a867037d675797a606cb62e57"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71115","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\num: init cpu_tasks[] earlier\n\nThis is currently done in uml_finishsetup(), but e.g. with\nKCOV enabled we'll crash because some init code can call\ninto e.g. memparse(), which has coverage annotations, and\nthen the checks in check_kcov_mode() crash because current\nis NULL.\n\nSimply initialize the cpu_tasks[] array statically, which\nfixes the crash. For the later SMP work, it seems to have\nnot really caused any problems yet, but initialize all of\nthe entries anyway.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7b5d4416964c07c902163822a30a622111172b01","https://git.kernel.org/stable/c/dbbf6d47130674640cd12a0781a0fb2a575d0e44"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71116","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: make decode_pool() more resilient against corrupted osdmaps\n\nIf the osdmap is (maliciously) corrupted such that the encoded length\nof ceph_pg_pool envelope is less than what is expected for a particular\nencoding version, out-of-bounds reads may ensue because the only bounds\ncheck that is there is based on that length value.\n\nThis patch adds explicit bounds checks for each field that is decoded\nor skipped.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/145d140abda80e33331c5781d6603014fa75d258","https://git.kernel.org/stable/c/2acb8517429ab42146c6c0ac1daed1f03d2fd125","https://git.kernel.org/stable/c/5d0d8c292531fe356c4e94dcfdf7d7212aca9957","https://git.kernel.org/stable/c/8c738512714e8c0aa18f8a10c072d5b01c83db39","https://git.kernel.org/stable/c/c82e39ff67353a5a6cbc07b786b8690bd2c45aaa","https://git.kernel.org/stable/c/d061be4c8040ffb1110d537654a038b8b6ad39d2","https://git.kernel.org/stable/c/e927ab132b87ba3f076705fc2684d94b24201ed1"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71117","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Remove queue freezing from several sysfs store callbacks\n\nFreezing the request queue from inside sysfs store callbacks may cause a\ndeadlock in combination with the dm-multipath driver and the\nqueue_if_no_path option. Additionally, freezing the request queue slows\ndown system boot on systems where sysfs attributes are set synchronously.\n\nFix this by removing the blk_mq_freeze_queue() / blk_mq_unfreeze_queue()\ncalls from the store callbacks that do not strictly need these callbacks.\nAdd the __data_racy annotation to request_queue.rq_timeout to suppress\nKCSAN data race reports about the rq_timeout reads.\n\nThis patch may cause a small delay in applying the new settings.\n\nFor all the attributes affected by this patch, I/O will complete\ncorrectly whether the old or the new value of the attribute is used.\n\nThis patch affects the following sysfs attributes:\n* io_poll_delay\n* io_timeout\n* nomerges\n* read_ahead_kb\n* rq_affinity\n\nHere is an example of a deadlock triggered by running test srp/002\nif this patch is not applied:\n\ntask:multipathd\nCall Trace:\n <TASK>\n __schedule+0x8c1/0x1bf0\n schedule+0xdd/0x270\n schedule_preempt_disabled+0x1c/0x30\n __mutex_lock+0xb89/0x1650\n mutex_lock_nested+0x1f/0x30\n dm_table_set_restrictions+0x823/0xdf0\n __bind+0x166/0x590\n dm_swap_table+0x2a7/0x490\n do_resume+0x1b1/0x610\n dev_suspend+0x55/0x1a0\n ctl_ioctl+0x3a5/0x7e0\n dm_ctl_ioctl+0x12/0x20\n __x64_sys_ioctl+0x127/0x1a0\n x64_sys_call+0xe2b/0x17d0\n do_syscall_64+0x96/0x3a0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n </TASK>\ntask:(udev-worker)\nCall Trace:\n <TASK>\n __schedule+0x8c1/0x1bf0\n schedule+0xdd/0x270\n blk_mq_freeze_queue_wait+0xf2/0x140\n blk_mq_freeze_queue_nomemsave+0x23/0x30\n queue_ra_store+0x14e/0x290\n queue_attr_store+0x23e/0x2c0\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3b2/0x630\n vfs_write+0x4fd/0x1390\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x276/0x17d0\n do_syscall_64+0x96/0x3a0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n </TASK>","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03022,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3997b3147c7b68b0308378fa95a766015f8ceb1c","https://git.kernel.org/stable/c/935a20d1bebf6236076785fac3ff81e3931834e9"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71118","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Avoid walking the Namespace if start_node is NULL\n\nAlthough commit 0c9992315e73 (\"ACPICA: Avoid walking the ACPI Namespace\nif it is not there\") fixed the situation when both start_node and\nacpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed\non Honor Magicbook 14 Pro [1].\n\nThat happens due to the access to the member of parent_node in\nacpi_ns_get_next_node().  The NULL pointer dereference will always\nhappen, no matter whether or not the start_node is equal to\nACPI_ROOT_OBJECT, so move the check of start_node being NULL\nout of the if block.\n\nUnfortunately, all the attempts to contact Honor have failed, they\nrefused to provide any technical support for Linux.\n\nThe bad DSDT table's dump could be found on GitHub [2].\n\nDMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025\n\n[ rjw: Subject adjustment, changelog edits ]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d8bb08126920fd4b12dbf32d9250757c9064b36","https://git.kernel.org/stable/c/1bc34293dfbd266c29875206849b4f8e8177e6df","https://git.kernel.org/stable/c/7f9b951ed11842373851dd3c91860778356d62d3","https://git.kernel.org/stable/c/9d6c58dae8f6590c746ac5d0012ffe14a77539f0","https://git.kernel.org/stable/c/b84edef48cc8afb41150949a87dcfa81bc95b53e","https://git.kernel.org/stable/c/ecb296286c8787895625bd4c53e9478db4ae139c","https://git.kernel.org/stable/c/f91dad0a3b381244183ffbea4cec5a7a69d6f41e"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71119","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/kexec: Enable SMT before waking offline CPUs\n\nIf SMT is disabled or a partial SMT state is enabled, when a new kernel\nimage is loaded for kexec, on reboot the following warning is observed:\n\nkexec: Waking offline cpu 228.\nWARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc\n[snip]\n NIP kexec_prepare_cpus+0x1b0/0x1bc\n LR  kexec_prepare_cpus+0x1a0/0x1bc\n Call Trace:\n  kexec_prepare_cpus+0x1a0/0x1bc (unreliable)\n  default_machine_kexec+0x160/0x19c\n  machine_kexec+0x80/0x88\n  kernel_kexec+0xd0/0x118\n  __do_sys_reboot+0x210/0x2c4\n  system_call_exception+0x124/0x320\n  system_call_vectored_common+0x15c/0x2ec\n\nThis occurs as add_cpu() fails due to cpu_bootable() returning false for\nCPUs that fail the cpu_smt_thread_allowed() check or non primary\nthreads if SMT is disabled.\n\nFix the issue by enabling SMT and resetting the number of SMT threads to\nthe number of threads per core, before attempting to wake up all present\nCPUs.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.06957,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d5c9e901ad40bd39b38e119c0454b52d7663930","https://git.kernel.org/stable/c/7cccd82a0e4aad192fd74fc60e61ed9aed5857a3","https://git.kernel.org/stable/c/c2296a1e42418556efbeb5636c4fa6aa6106713a","https://git.kernel.org/stable/c/d790ef0c4819424ee0c2f448c0a8154c5ca369d1","https://git.kernel.org/stable/c/f0c0a681ffb77b8c5290c88c02d968199663939b"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71120","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf\n\nA zero length gss_token results in pages == 0 and in_token->pages[0]\nis NULL. The code unconditionally evaluates\npage_address(in_token->pages[0]) for the initial memcpy, which can\ndereference NULL even when the copy length is 0. Guard the first\nmemcpy so it only runs when length > 0.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1c8bb965e9b0559ff0f5690615a527c30f651dd8","https://git.kernel.org/stable/c/4dedb6a11243a5c9eb9dbb97bca3c98bd725e83d","https://git.kernel.org/stable/c/7452d53f293379e2c38cfa8ad0694aa46fc4788b","https://git.kernel.org/stable/c/a2c6f25ab98b423f99ccd94874d655b8bcb01a19","https://git.kernel.org/stable/c/a8f1e445ce3545c90d69c9e8ff8f7821825fe810","https://git.kernel.org/stable/c/d4b69a6186b215d2dc1ebcab965ed88e8d41768d","https://git.kernel.org/stable/c/f9e53f69ac3bc4ef568b08d3542edac02e83fefd"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71121","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Do not reprogram affinitiy on ASP chip\n\nThe ASP chip is a very old variant of the GSP chip and is used e.g. in\nHP 730 workstations. When trying to reprogram the affinity it will crash\nwith a HPMC as the relevant registers don't seem to be at the usual\nlocation.  Let's avoid the crash by checking the sversion. Also note,\nthat reprogramming isn't necessary either, as the HP730 is a just a\nsingle-CPU machine.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00034,"ranking_epss":0.09971,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4d0858bbeea12a50bfb32137f74d4b74917ebadd","https://git.kernel.org/stable/c/60560d13ff368415c96a0c1247bea16d427c0641","https://git.kernel.org/stable/c/7a146f34e5be96330467397c9fd9d3d851b2cbbe","https://git.kernel.org/stable/c/845a92b74cf7a730200532ecb4482981cec9d006","https://git.kernel.org/stable/c/c8f810e20f4bbe50b49f73429d9fa6efad00623e","https://git.kernel.org/stable/c/dca7da244349eef4d78527cafc0bf80816b261f5","https://git.kernel.org/stable/c/e09fd2eb6d4c993ee9eaae556cb51e30ec1042df"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71122","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommufd/selftest: Check for overflow in IOMMU_TEST_OP_ADD_RESERVED\n\nsyzkaller found it could overflow math in the test infrastructure and\ncause a WARN_ON by corrupting the reserved interval tree. This only\neffects test kernels with CONFIG_IOMMUFD_TEST.\n\nValidate the user input length in the test ioctl.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4cc829d61f10c20523fd4085c1546e741a792a97","https://git.kernel.org/stable/c/b166b8e0a381429fefd9180e67fbc834b3cee82f","https://git.kernel.org/stable/c/e6a973af11135439de32ece3b9cbe3bfc043bea8","https://git.kernel.org/stable/c/e6c122cffcbb2e84d321ec8ba0e38ce8e7c10925"],"published_time":"2026-01-14T15:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71110","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: reset KASAN tag in defer_free() before accessing freed memory\n\nWhen CONFIG_SLUB_TINY is enabled, kfree_nolock() calls kasan_slab_free()\nbefore defer_free(). On ARM64 with MTE (Memory Tagging Extension),\nkasan_slab_free() poisons the memory and changes the tag from the\noriginal (e.g., 0xf3) to a poison tag (0xfe).\n\nWhen defer_free() then tries to write to the freed object to build the\ndeferred free list via llist_add(), the pointer still has the old tag,\ncausing a tag mismatch and triggering a KASAN use-after-free report:\n\n  BUG: KASAN: slab-use-after-free in defer_free+0x3c/0xbc mm/slub.c:6537\n  Write at addr f3f000000854f020 by task kworker/u8:6/983\n  Pointer tag: [f3], memory tag: [fe]\n\nFix this by calling kasan_reset_tag() before accessing the freed memory.\nThis is safe because defer_free() is part of the allocator itself and is\nexpected to manipulate freed memory for bookkeeping purposes.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00019,"ranking_epss":0.05102,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/53ca00a19d345197a37a1bf552e8d1e7b091666c","https://git.kernel.org/stable/c/65d4e5af2a2e82f4fc50d8259aee208fbc6b2c1d"],"published_time":"2026-01-14T15:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71111","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (w83791d) Convert macros to functions to avoid TOCTOU\n\nThe macro FAN_FROM_REG evaluates its arguments multiple times. When used\nin lockless contexts involving shared driver data, this leads to\nTime-of-Check to Time-of-Use (TOCTOU) race conditions, potentially\ncausing divide-by-zero errors.\n\nConvert the macro to a static function. This guarantees that arguments\nare evaluated only once (pass-by-value), preventing the race\nconditions.\n\nAdditionally, in store_fan_div, move the calculation of the minimum\nlimit inside the update lock. This ensures that the read-modify-write\nsequence operates on consistent data.\n\nAdhere to the principle of minimal changes by only converting macros\nthat evaluate arguments multiple times and are used in lockless\ncontexts.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.0002,"ranking_epss":0.0527,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3dceb68f6ad33156032ef4da21a93d84059cca6d","https://git.kernel.org/stable/c/670d7ef945d3a84683594429aea6ab2cdfa5ceb4","https://git.kernel.org/stable/c/a9fb6e8835a22f5796c1182ed612daed3fd273af","https://git.kernel.org/stable/c/bf5b03227f2e6d4360004886d268f9df8993ef8f","https://git.kernel.org/stable/c/c8cf0c2bdcccc6634b6915ff793b844e12436680","https://git.kernel.org/stable/c/f2b579a0c37c0df19603d719894a942a295f634a","https://git.kernel.org/stable/c/f94800fbc26ccf7c81eb791707b038a57aa39a18"],"published_time":"2026-01-14T15:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71112","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: add VLAN id validation before using\n\nCurrently, the VLAN id may be used without validation when\nreceive a VLAN configuration mailbox from VF. The length of\nvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause\nout-of-bounds memory access once the VLAN id is bigger than\nor equal to VLAN_N_VID.\n\nTherefore, VLAN id needs to be checked to ensure it is within\nthe range of VLAN_N_VID.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/00e56a7706e10b3d00a258d81fcb85a7e96372d6","https://git.kernel.org/stable/c/42c91dfa772c57de141e5a55a187ac760c0fd7e1","https://git.kernel.org/stable/c/46c7d9fe8dd869ea5de666aba8c1ec1061ca44a8","https://git.kernel.org/stable/c/6ef935e65902bfed53980ad2754b06a284ea8ac1","https://git.kernel.org/stable/c/91a51d01be5c9f82c12c2921ca5cceaa31b67128","https://git.kernel.org/stable/c/95cca255a7a5ad782639ff0298c2a486707d1046","https://git.kernel.org/stable/c/b7b4f3bf118f51b67691a55b464f04452e5dc6fc"],"published_time":"2026-01-14T15:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71113","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - zero initialize memory allocated via sock_kmalloc\n\nSeveral crypto user API contexts and requests allocated with\nsock_kmalloc() were left uninitialized, relying on callers to\nset fields explicitly. This resulted in the use of uninitialized\ndata in certain error paths or when new fields are added in the\nfuture.\n\nThe ACVP patches also contain two user-space interface files:\nalgif_kpp.c and algif_akcipher.c. These too rely on proper\ninitialization of their context structures.\n\nA particular issue has been observed with the newly added\n'inflight' variable introduced in af_alg_ctx by commit:\n\n  67b164a871af (\"crypto: af_alg - Disallow multiple in-flight AIO requests\")\n\nBecause the context is not memset to zero after allocation,\nthe inflight variable has contained garbage values. As a result,\naf_alg_alloc_areq() has incorrectly returned -EBUSY randomly when\nthe garbage value was interpreted as true:\n\n  https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209\n\nThe check directly tests ctx->inflight without explicitly\ncomparing against true/false. Since inflight is only ever set to\ntrue or false later, an uninitialized value has triggered\n-EBUSY failures. Zero-initializing memory allocated with\nsock_kmalloc() ensures inflight and other fields start in a known\nstate, removing random issues caused by uninitialized data.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/51a5ab36084f3251ef87eda3e6a6236f6488925e","https://git.kernel.org/stable/c/543bf004e4eafbb302b1e6c78570d425d2ca13a0","https://git.kernel.org/stable/c/5a4b65523608974a81edbe386f8a667a3e10c726","https://git.kernel.org/stable/c/6f6e309328d53a10c0fe1f77dec2db73373179b6","https://git.kernel.org/stable/c/84238876e3b3b262cf62d5f4d1338e983fb27010","https://git.kernel.org/stable/c/e125c8e346e4eb7b3e854c862fcb4392bc13ddba","https://git.kernel.org/stable/c/f81244fd6b14fecfa93b66b6bb1d59f96554e550"],"published_time":"2026-01-14T15:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71102","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscs: fix a wrong parameter in __scs_magic\n\n__scs_magic() needs a 'void *' variable, but a 'struct task_struct *' is\ngiven.  'task_scs(tsk)' is the starting address of the task's shadow call\nstack, and '__scs_magic(task_scs(tsk))' is the end address of the task's\nshadow call stack.  Here should be '__scs_magic(task_scs(tsk))'.\n\nThe user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE\nis enabled, the shadow call stack usage checking function\n(scs_check_usage) would scan an incorrect memory range.  This could lead\n\n1. **Inaccurate stack usage reporting**: The function would calculate\n   wrong usage statistics for the shadow call stack, potentially showing\n   incorrect value in kmsg.\n\n2. **Potential kernel crash**: If the value of __scs_magic(tsk)is\n   greater than that of __scs_magic(task_scs(tsk)), the for loop may\n   access unmapped memory, potentially causing a kernel panic.  However,\n   this scenario is unlikely because task_struct is allocated via the slab\n   allocator (which typically returns lower addresses), while the shadow\n   call stack returned by task_scs(tsk) is allocated via vmalloc(which\n   typically returns higher addresses).\n\nHowever, since this is purely a debugging feature\n(CONFIG_DEBUG_STACK_USAGE), normal production systems should be not\nunaffected.  The bug only impacts developers and testers who are actively\ndebugging stack usage with this configuration enabled.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/062774439d442882b44f5eab8c256ad3423ef284","https://git.kernel.org/stable/c/08bd4c46d5e63b78e77f2605283874bbe868ab19","https://git.kernel.org/stable/c/1727e8bd69103a68963a5613a0ddb6d8d37df5d3","https://git.kernel.org/stable/c/57ba40b001be27786d0570dd292289df748b306b","https://git.kernel.org/stable/c/9ef28943471a16e4f9646bc3e8e2de148e7d8d7b","https://git.kernel.org/stable/c/a19fb3611e4c06624fc0f83ef19f4fb8d57d4751","https://git.kernel.org/stable/c/cfdf6250b63b953b1d8e60814c8ca96c6f9d1c8c"],"published_time":"2026-01-14T15:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71103","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: adreno: fix deferencing ifpc_reglist when not declared\n\nOn plaforms with an a7xx GPU not supporting IFPC, the ifpc_reglist\nif still deferenced in a7xx_patch_pwrup_reglist() which causes\na kernel crash:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000008\n...\npc : a6xx_hw_init+0x155c/0x1e4c [msm]\nlr : a6xx_hw_init+0x9a8/0x1e4c [msm]\n...\nCall trace:\n  a6xx_hw_init+0x155c/0x1e4c [msm] (P)\n  msm_gpu_hw_init+0x58/0x88 [msm]\n  adreno_load_gpu+0x94/0x1fc [msm]\n  msm_open+0xe4/0xf4 [msm]\n  drm_file_alloc+0x1a0/0x2e4 [drm]\n  drm_client_init+0x7c/0x104 [drm]\n  drm_fbdev_client_setup+0x94/0xcf0 [drm_client_lib]\n  drm_client_setup+0xb4/0xd8 [drm_client_lib]\n  msm_drm_kms_post_init+0x2c/0x3c [msm]\n  msm_drm_init+0x1a4/0x228 [msm]\n  msm_drm_bind+0x30/0x3c [msm]\n...\n\nCheck the validity of ifpc_reglist before deferencing the table\nto setup the register values.\n\nPatchwork: https://patchwork.freedesktop.org/patch/688944/","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/129049d4fe22c998ae9fd1ec479fbb4ed5338c15","https://git.kernel.org/stable/c/19648135e904bce447d368ecb6136e5da809639c"],"published_time":"2026-01-14T15:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71104","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest's APIC timer in periodic\nmode, set the expiration to \"now\" if the target expiration is in the past\n(similar to what is done in update_target_expiration()).  Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over.  In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer.  Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active.  As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past.  As a result, the delta\nmay be calculated as a negative value.  When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming.  I.e. the large\nvalue will exceed the VMX Preemption Timer's maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM's request for an expiration in the past and\nimmediately re-invokes KVM's callback after reprogramming.  And because\nthe interrupt handler runs with IRQs disabled, restarting KVM's hrtimer\nover and over until the target expiration is advanced to \"now\" can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n  NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n  ...\n  RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n  ...\n  RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n  RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n  RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n  RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n  R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n  R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n  FS:  00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n  PKRU: 55555554\n  Call Trace:\n   <IRQ>\n   apic_timer_fn+0x31/0x50 [kvm]\n   __hrtimer_run_queues+0x100/0x280\n   hrtimer_interrupt+0x100/0x210\n   ? ttwu_do_wakeup+0x19/0x160\n   smp_apic_timer_interrupt+0x6a/0x130\n   apic_timer_interrupt+0xf/0x20\n   </IRQ>\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\"KVM: VMX: Move preemption timer <=> hrtimer dance to common x86\"), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way.  Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0002,"ranking_epss":0.0527,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/18ab3fc8e880791aa9f7c000261320fc812b5465","https://git.kernel.org/stable/c/786ed625c125c5cd180d6aaa37e653e3e4ffb8d9","https://git.kernel.org/stable/c/7b54ccef865e0aa62e4871d4ada2ba4b9dcb8bed","https://git.kernel.org/stable/c/807dbe8f3862fa7c164155857550ce94b36a11b9","https://git.kernel.org/stable/c/d2da0df7bbc4fb4fd7d0a1da704f81a09c72fe73","https://git.kernel.org/stable/c/e23f46f1a971c73dad2fd63e1408696114ddebe2","https://git.kernel.org/stable/c/e746e51947053a02af2ea964593dc4887108d379"],"published_time":"2026-01-14T15:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71105","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: use global inline_xattr_slab instead of per-sb slab cache\n\nAs Hong Yun reported in mailing list:\n\nloop7: detected capacity change from 0 to 131072\n------------[ cut here ]------------\nkmem_cache of name 'f2fs_xattr_entry-7:7' already exists\nWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]\nWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307\nCPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]\nRIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307\nCall Trace:\n __kmem_cache_create include/linux/slab.h:353 [inline]\n f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline]\n f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843\n f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918\n get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692\n vfs_get_tree+0x43/0x140 fs/super.c:1815\n do_new_mount+0x201/0x550 fs/namespace.c:3808\n do_mount fs/namespace.c:4136 [inline]\n __do_sys_mount fs/namespace.c:4347 [inline]\n __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe bug can be reproduced w/ below scripts:\n- mount /dev/vdb /mnt1\n- mount /dev/vdc /mnt2\n- umount /mnt1\n- mounnt /dev/vdb /mnt1\n\nThe reason is if we created two slab caches, named f2fs_xattr_entry-7:3\nand f2fs_xattr_entry-7:7, and they have the same slab size. Actually,\nslab system will only create one slab cache core structure which has\nslab name of \"f2fs_xattr_entry-7:3\", and two slab caches share the same\nstructure and cache address.\n\nSo, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it will\ndecrease reference count of slab cache, rather than release slab cache\nentirely, since there is one more user has referenced the cache.\n\nThen, if we try to create slab cache w/ name \"f2fs_xattr_entry-7:3\" again,\nslab system will find that there is existed cache which has the same name\nand trigger the warning.\n\nLet's changes to use global inline_xattr_slab instead of per-sb slab cache\nfor fixing.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1eb0b130196bcbc56c5c80c83139fa70c0aa82c5","https://git.kernel.org/stable/c/1f27ef42bb0b7c0740c5616ec577ec188b8a1d05","https://git.kernel.org/stable/c/474cc3ed37436ddfd63cac8dbffe3b1e219e9100","https://git.kernel.org/stable/c/72ce19dfed162da6e430467333b2da70471d08a4","https://git.kernel.org/stable/c/93d30fe19660dec6bf1bd3d5c186c1c737b21aa5","https://git.kernel.org/stable/c/be4c3a3c6c2304a8fcd14095d18d26f0cc4e222a","https://git.kernel.org/stable/c/e6d828eae00ec192e18c2ddaa2fd32050a96048a"],"published_time":"2026-01-14T15:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71106","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs: PM: Fix reverse check in filesystems_freeze_callback()\n\nThe freeze_all_ptr check in filesystems_freeze_callback() introduced by\ncommit a3f8f8662771 (\"power: always freeze efivarfs\") is reverse which\nquite confusingly causes all file systems to be frozen when\nfilesystem_freeze_enabled is false.\n\nOn my systems it causes the WARN_ON_ONCE() in __set_task_frozen() to\ntrigger, most likely due to an attempt to freeze a file system that is\nnot ready for that.\n\nAdd a logical negation to the check in question to reverse it as\nappropriate.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/222047f68e8565c558728f792f6fef152a1d4d51","https://git.kernel.org/stable/c/b107196729ff6b9d6cde0a71f49c1243def43328"],"published_time":"2026-01-14T15:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71107","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: ensure node page reads complete before f2fs_put_super() finishes\n\nXfstests generic/335, generic/336 sometimes crash with the following message:\n\nF2FS-fs (dm-0): detect filesystem reference count leak during umount, type: 9, count: 1\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/super.c:1939!\nOops: invalid opcode: 0000 [#1] SMP NOPTI\nCPU: 1 UID: 0 PID: 609351 Comm: umount Tainted: G        W           6.17.0-rc5-xfstests-g9dd1835ecda5 #1 PREEMPT(none)\nTainted: [W]=WARN\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:f2fs_put_super+0x3b3/0x3c0\nCall Trace:\n <TASK>\n generic_shutdown_super+0x7e/0x190\n kill_block_super+0x1a/0x40\n kill_f2fs_super+0x9d/0x190\n deactivate_locked_super+0x30/0xb0\n cleanup_mnt+0xba/0x150\n task_work_run+0x5c/0xa0\n exit_to_user_mode_loop+0xb7/0xc0\n do_syscall_64+0x1ae/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n </TASK>\n---[ end trace 0000000000000000 ]---\n\nIt appears that sometimes it is possible that f2fs_put_super() is called before\nall node page reads are completed.\nAdding a call to f2fs_wait_on_all_pages() for F2FS_RD_NODE fixes the problem.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04182,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0b36fae23621a09e772c8adf918b9011158f8511","https://git.kernel.org/stable/c/297baa4aa263ff8f5b3d246ee16a660d76aa82c4","https://git.kernel.org/stable/c/3b15d5f12935e9e25f9a571e680716bc9ee61025","https://git.kernel.org/stable/c/c3031cf2b61f1508662fc95ef9ad505cb0882a5f"],"published_time":"2026-01-14T15:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71108","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: Handle incorrect num_connectors capability\n\nThe UCSI spec states that the num_connectors field is 7 bits, and the\n8th bit is reserved and should be set to zero.\nSome buggy FW has been known to set this bit, and it can lead to a\nsystem not booting.\nFlag that the FW is not behaving correctly, and auto-fix the value\nso that the system boots correctly.\n\nFound on Lenovo P1 G8 during Linux enablement program. The FW will\nbe fixed, but seemed worth addressing in case it hit platforms that\naren't officially Linux supported.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/07c8d2a109d847775b3b4e2c3294c8e1eea75432","https://git.kernel.org/stable/c/132fe187e0d940f388f839fe2cde9b84106ad20d","https://git.kernel.org/stable/c/3042a57a8e8bce4a3100c3f6f03dc372aab24943","https://git.kernel.org/stable/c/30cd2cb1abf4c4acdb1ddb468c946f68939819fb","https://git.kernel.org/stable/c/58941bbb0050e365a98c64f1fc4a9a0ac127dba6","https://git.kernel.org/stable/c/914605b0de8128434eafc9582445306830748b93","https://git.kernel.org/stable/c/f72f97d0aee4a993a35f2496bca5efd24827235d"],"published_time":"2026-01-14T15:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71109","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits\n\nSince commit e424054000878 (\"MIPS: Tracing: Reduce the overhead of\ndynamic Function Tracer\"), the macro UASM_i_LA_mostly has been used,\nand this macro can generate more than 2 instructions. At the same\ntime, the code in ftrace assumes that no more than 2 instructions can\nbe generated, which is why it stores them in an int[2] array. However,\nas previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA)\ncauses a buffer overflow when _mcount is beyond 32 bits. This leads to\ncorruption of the variables located in the __read_mostly section.\n\nThis corruption was observed because the variable\n__cpu_primary_thread_mask was corrupted, causing a hang very early\nduring boot.\n\nThis fix prevents the corruption by avoiding the generation of\ninstructions if they could exceed 2 instructions in\nlength. Fortunately, insn_la_mcount is only used if the instrumented\ncode is located outside the kernel code section, so dynamic ftrace can\nstill be used, albeit in a more limited scope. This is still\npreferable to corrupting memory and/or crashing the kernel.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0002,"ranking_epss":0.05474,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/36dac9a3dda1f2bae343191bc16b910c603cac25","https://git.kernel.org/stable/c/7f39b9d0e86ed6236b9a5fb67616ab1f76c4f150","https://git.kernel.org/stable/c/e3e33ac2eb69d595079a1a1e444c2fb98efdd42d"],"published_time":"2026-01-14T15:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71101","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing\n\nThe hp_populate_*_elements_from_package() functions in the hp-bioscfg\ndriver contain out-of-bounds array access vulnerabilities.\n\nThese functions parse ACPI packages into internal data structures using\na for loop with index variable 'elem' that iterates through\nenum_obj/integer_obj/order_obj/password_obj/string_obj arrays.\n\nWhen processing multi-element fields like PREREQUISITES and\nENUM_POSSIBLE_VALUES, these functions read multiple consecutive array\nelements using expressions like 'enum_obj[elem + reqs]' and\n'enum_obj[elem + pos_values]' within nested loops.\n\nThe bug is that the bounds check only validated elem, but did not consider\nthe additional offset when accessing elem + reqs or elem + pos_values.\n\nThe fix changes the bounds check to validate the actual accessed index.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/79cab730dbaaac03b946c7f5681bd08c986e2abd","https://git.kernel.org/stable/c/cf7ae870560b988247a4bbbe5399edd326632680","https://git.kernel.org/stable/c/db4c26adf7117b1a4431d1197ae7109fee3230ad","https://git.kernel.org/stable/c/e44c42c830b7ab36e3a3a86321c619f24def5206"],"published_time":"2026-01-13T16:16:10","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71093","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ne1000: fix OOB in e1000_tbi_should_accept()\n\nIn e1000_tbi_should_accept() we read the last byte of the frame via\n'data[length - 1]' to evaluate the TBI workaround. If the descriptor-\nreported length is zero or larger than the actual RX buffer size, this\nread goes out of bounds and can hit unrelated slab objects. The issue\nis observed from the NAPI receive path (e1000_clean_rx_irq):\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790\nRead of size 1 at addr ffff888014114e54 by task sshd/363\n\nCPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <IRQ>\n dump_stack_lvl+0x5a/0x74\n print_address_description+0x7b/0x440\n print_report+0x101/0x200\n kasan_report+0xc1/0xf0\n e1000_tbi_should_accept+0x610/0x790\n e1000_clean_rx_irq+0xa8c/0x1110\n e1000_clean+0xde2/0x3c10\n __napi_poll+0x98/0x380\n net_rx_action+0x491/0xa20\n __do_softirq+0x2c9/0x61d\n do_softirq+0xd1/0x120\n </IRQ>\n <TASK>\n __local_bh_enable_ip+0xfe/0x130\n ip_finish_output2+0x7d5/0xb00\n __ip_queue_xmit+0xe24/0x1ab0\n __tcp_transmit_skb+0x1bcb/0x3340\n tcp_write_xmit+0x175d/0x6bd0\n __tcp_push_pending_frames+0x7b/0x280\n tcp_sendmsg_locked+0x2e4f/0x32d0\n tcp_sendmsg+0x24/0x40\n sock_write_iter+0x322/0x430\n vfs_write+0x56c/0xa60\n ksys_write+0xd1/0x190\n do_syscall_64+0x43/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f511b476b10\nCode: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24\nRSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10\nRDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003\nRBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00\nR10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003\n </TASK>\nAllocated by task 1:\n __kasan_krealloc+0x131/0x1c0\n krealloc+0x90/0xc0\n add_sysfs_param+0xcb/0x8a0\n kernel_add_sysfs_param+0x81/0xd4\n param_sysfs_builtin+0x138/0x1a6\n param_sysfs_init+0x57/0x5b\n do_one_initcall+0x104/0x250\n do_initcall_level+0x102/0x132\n do_initcalls+0x46/0x74\n kernel_init_freeable+0x28f/0x393\n kernel_init+0x14/0x1a0\n ret_from_fork+0x22/0x30\nThe buggy address belongs to the object at ffff888014114000\n which belongs to the cache kmalloc-2k of size 2048\nThe buggy address is located 1620 bytes to the right of\n 2048-byte region [ffff888014114000, ffff888014114800]\nThe buggy address belongs to the physical page:\npage:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110\nhead:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0\nflags: 0x100000000010200(slab|head|node=0|zone=1)\nraw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000\nraw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n==================================================================\n\nThis happens because the TBI check unconditionally dereferences the last\nbyte without validating the reported length first:\n\n\tu8 last_byte = *(data + length - 1);\n\nFix by rejecting the frame early if the length is zero, or if it exceeds\nadapter->rx_buffer_len. This preserves the TBI workaround semantics for\nvalid frames and prevents touching memory beyond the RX buffer.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/26c8bebc2f25288c2bcac7bc0a7662279a0e817c","https://git.kernel.org/stable/c/278b7cfe0d4da7502c7fd679b15032f014c92892","https://git.kernel.org/stable/c/2c4c0c09f9648ba766d399917d420d03e7b3e1f8","https://git.kernel.org/stable/c/4ccfa56f272241e8d8e2c38191fdbb03df489d80","https://git.kernel.org/stable/c/9c72a5182ed92904d01057f208c390a303f00a0f","https://git.kernel.org/stable/c/ad7a2a45e2417ac54089926b520924f8f0d91aea","https://git.kernel.org/stable/c/ee7c125fb3e8b04dd46510130b9fc92380e5d578"],"published_time":"2026-01-13T16:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71094","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix: validate PHY address before use\n\nThe ASIX driver reads the PHY address from the USB device via\nasix_read_phy_addr(). A malicious or faulty device can return an\ninvalid address (>= PHY_MAX_ADDR), which causes a warning in\nmdiobus_get_phy():\n\n  addr 207 out of range\n  WARNING: drivers/net/phy/mdio_bus.c:76\n\nValidate the PHY address in asix_read_phy_addr() and remove the\nnow-redundant check in ax88172a.c.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/38722e69ee64dbb020028c93898d25d6f4c0e0b2","https://git.kernel.org/stable/c/98a12c2547a44a5f03f35c108d2022cc652cbc4d","https://git.kernel.org/stable/c/a1e077a3f76eea0dc671ed6792e7d543946227e8","https://git.kernel.org/stable/c/bf8a0f3b787ca7c5889bfca12c60c483041fbee3","https://git.kernel.org/stable/c/f5f4f30f3811d37e1aa48667c36add74e5a8d99f","https://git.kernel.org/stable/c/fc96018f09f8d30586ca6582c5045a84eafef146"],"published_time":"2026-01-13T16:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71095","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: fix the crash issue for zero copy XDP_TX action\n\nThere is a crash issue when running zero copy XDP_TX action, the crash\nlog is shown below.\n\n[  216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000\n[  216.187524] Internal error: Oops: 0000000096000144 [#1]  SMP\n[  216.301694] Call trace:\n[  216.304130]  dcache_clean_poc+0x20/0x38 (P)\n[  216.308308]  __dma_sync_single_for_device+0x1bc/0x1e0\n[  216.313351]  stmmac_xdp_xmit_xdpf+0x354/0x400\n[  216.317701]  __stmmac_xdp_run_prog+0x164/0x368\n[  216.322139]  stmmac_napi_poll_rxtx+0xba8/0xf00\n[  216.326576]  __napi_poll+0x40/0x218\n[  216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt\n\nFor XDP_TX action, the xdp_buff is converted to xdp_frame by\nxdp_convert_buff_to_frame(). The memory type of the resulting xdp_frame\ndepends on the memory type of the xdp_buff. For page pool based xdp_buff\nit produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copy\nXSK pool based xdp_buff it produces xdp_frame with memory type\nMEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check the\nmemory type and always uses the page pool type, this leads to invalid\nmappings and causes the crash. Therefore, check the xdp_buff memory type\nin stmmac_xdp_xmit_back() to fix this issue.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.06957,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3f7823219407f2f18044c2b72366a48810c5c821","https://git.kernel.org/stable/c/45ee0462b88396a0bd1df1991f801c89994ea72b","https://git.kernel.org/stable/c/4d0ceb7677e1c4616afb96abb4518f70b65abb0d","https://git.kernel.org/stable/c/5e5988736a95b1de7f91b10ac2575454b70e4897","https://git.kernel.org/stable/c/a48e232210009be50591fdea8ba7c07b0f566a13"],"published_time":"2026-01-13T16:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71096","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly\n\nThe netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a\nLS_NLA_TYPE_DGID attribute, it is invalid if it does not.\n\nUse the nl parsing logic properly and call nla_parse_deprecated() to fill\nthe nlattrs array and then directly index that array to get the data for\nthe DGID. Just fail if it is NULL.\n\nRemove the for loop searching for the nla, and squash the validation and\nparsing into one function.\n\nFixes an uninitialized read from the stack triggered by userspace if it\ndoes not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE\nquery.\n\n    BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]\n    BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490\n     hex_byte_pack include/linux/hex.h:13 [inline]\n     ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490\n     ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509\n     ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633\n     pointer+0xc09/0x1bd0 lib/vsprintf.c:2542\n     vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930\n     vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279\n     vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426\n     vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465\n     vprintk+0x36/0x50 kernel/printk/printk_safe.c:82\n     _printk+0x17e/0x1b0 kernel/printk/printk.c:2475\n     ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]\n     ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141\n     rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]\n     rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]\n     rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259\n     netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n     netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346\n     netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896\n     sock_sendmsg_nosec net/socket.c:714 [inline]\n     __sock_sendmsg+0x333/0x3d0 net/socket.c:729\n     ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617\n     ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671\n     __sys_sendmsg+0x1aa/0x300 net/socket.c:2703\n     __compat_sys_sendmsg net/compat.c:346 [inline]\n     __do_compat_sys_sendmsg net/compat.c:353 [inline]\n     __se_compat_sys_sendmsg net/compat.c:350 [inline]\n     __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350\n     ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371\n     do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n     __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306\n     do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n     do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0b948afc1ded88b3562c893114387f34389eeb94","https://git.kernel.org/stable/c/376f46c8983458ead26cac83aa897a0b78491831","https://git.kernel.org/stable/c/45532638de5da24c201aa2a9b3dd4b054064de7b","https://git.kernel.org/stable/c/9d85524789c2f17c0e87de8d596bcccc3683a1fc","https://git.kernel.org/stable/c/a7b8e876e0ef0232b8076972c57ce9a7286b47ca","https://git.kernel.org/stable/c/acadd4097d25d6bd472bcb3f9f3eba2b5105d1ec","https://git.kernel.org/stable/c/bfe10318fc23e0b3f1d0a18dad387d29473a624d"],"published_time":"2026-01-13T16:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71097","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: Fix reference count leak when using error routes with nexthop objects\n\nWhen a nexthop object is deleted, it is marked as dead and then\nfib_table_flush() is called to flush all the routes that are using the\ndead nexthop.\n\nThe current logic in fib_table_flush() is to only flush error routes\n(e.g., blackhole) when it is called as part of network namespace\ndismantle (i.e., with flush_all=true). Therefore, error routes are not\nflushed when their nexthop object is deleted:\n\n # ip link add name dummy1 up type dummy\n # ip nexthop add id 1 dev dummy1\n # ip route add 198.51.100.1/32 nhid 1\n # ip route add blackhole 198.51.100.2/32 nhid 1\n # ip nexthop del id 1\n # ip route show\n blackhole 198.51.100.2 nhid 1 dev dummy1\n\nAs such, they keep holding a reference on the nexthop object which in\nturn holds a reference on the nexthop device, resulting in a reference\ncount leak:\n\n # ip link del dev dummy1\n [   70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2\n\nFix by flushing error routes when their nexthop is marked as dead.\n\nIPv6 does not suffer from this problem.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/30386e090c49e803c0616a7147e43409c32a2b0e","https://git.kernel.org/stable/c/33ff5c207c873215e54e6176624ed57423cb7dea","https://git.kernel.org/stable/c/5979338c83012110ccd45cae6517591770bfe536","https://git.kernel.org/stable/c/5de7ad7e18356e39e8fbf7edd185a5faaf4f385a","https://git.kernel.org/stable/c/ac782f4e3bfcde145b8a7f8af31d9422d94d172a","https://git.kernel.org/stable/c/e3fc381320d04e4a74311e576a86cac49a16fc43","https://git.kernel.org/stable/c/ee4183501ea556dca31f5ffd8690aa9fd25b609f"],"published_time":"2026-01-13T16:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71098","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nip6_gre: make ip6gre_header() robust\n\nOver the years, syzbot found many ways to crash the kernel\nin ip6gre_header() [1].\n\nThis involves team or bonding drivers ability to dynamically\nchange their dev->needed_headroom and/or dev->hard_header_len\n\nIn this particular crash mld_newpack() allocated an skb\nwith a too small reserve/headroom, and by the time mld_sendpack()\nwas called, syzbot managed to attach an ip6gre device.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:213 !\n <TASK>\n  skb_under_panic net/core/skbuff.c:223 [inline]\n  skb_push+0xc3/0xe0 net/core/skbuff.c:2641\n  ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371\n  dev_hard_header include/linux/netdevice.h:3436 [inline]\n  neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618\n  neigh_output include/net/neighbour.h:556 [inline]\n  ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136\n __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]\n  ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220\n  NF_HOOK_COND include/linux/netfilter.h:307 [inline]\n  ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247\n  NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318\n  mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855\n  mld_send_cr net/ipv6/mcast.c:2154 [inline]\n  mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1717357007db150c2d703f13f5695460e960f26c","https://git.kernel.org/stable/c/17e7386234f740f3e7d5e58a47b5847ea34c3bc2","https://git.kernel.org/stable/c/41a1a3140aff295dee8063906f70a514548105e8","https://git.kernel.org/stable/c/5fe210533e3459197eabfdbf97327dacbdc04d60","https://git.kernel.org/stable/c/91a2b25be07ce1a7549ceebbe82017551d2eec92","https://git.kernel.org/stable/c/adee129db814474f2f81207bd182bf343832a52e","https://git.kernel.org/stable/c/db5b4e39c4e63700c68a7e65fc4e1f1375273476"],"published_time":"2026-01-13T16:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71099","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl()\n\nIn xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping\nmetrics_lock. Since this lock protects the lifetime of oa_config, an\nattacker could guess the id and call xe_oa_remove_config_ioctl() with\nperfect timing, freeing oa_config before we dereference it, leading to\na potential use-after-free.\n\nFix this by caching the id in a local variable while holding the lock.\n\nv2: (Matt A)\n- Dropped mutex_unlock(&oa->metrics_lock) ordering change from\n  xe_oa_remove_config_ioctl()\n\n(cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.04296,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7cdb9a9da935c687563cc682155461fef5f9b48d","https://git.kernel.org/stable/c/c6d30b65b7a44dac52ad49513268adbf19eab4a2","https://git.kernel.org/stable/c/dcb171931954c51a1a7250d558f02b8f36570783"],"published_time":"2026-01-13T16:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71100","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: 8192cu: fix tid out of range in rtl92cu_tx_fill_desc()\n\nTID getting from ieee80211_get_tid() might be out of range of array size\nof sta_entry->tids[], so check TID is less than MAX_TID_COUNT. Othwerwise,\nUBSAN warn:\n\n UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30\n index 10 is out of range for type 'rtl_tid_data [9]'","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.04296,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/90a15ff324645aa806d81fa349497cd964861b66","https://git.kernel.org/stable/c/9765d6eb8298b07d499cdf9ef7c237d3540102d6","https://git.kernel.org/stable/c/dd39edb445f07400e748da967a07d5dca5c5f96e"],"published_time":"2026-01-13T16:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71084","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cm: Fix leaking the multicast GID table reference\n\nIf the CM ID is destroyed while the CM event for multicast creating is\nstill queued the cancel_work_sync() will prevent the work from running\nwhich also prevents destroying the ah_attr. This leaks a refcount and\ntriggers a WARN:\n\n   GID entry ref leak for dev syz1 index 2 ref=573\n   WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]\n   WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886\n\nDestroy the ah_attr after canceling the work, it is safe to call this\ntwice.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3ba6d01c4b3c584264dc733c6a2ecc5bbc8e0bb5","https://git.kernel.org/stable/c/57f3cb6c84159d12ba343574df2115fb18dd83ca","https://git.kernel.org/stable/c/5cb34bb5fd726491b809efbeb5cfd63ae5bf9cf3","https://git.kernel.org/stable/c/ab668a58c4a2ccb6d54add7a76f2f955d15d0196","https://git.kernel.org/stable/c/abf38398724ecc888f62c678d288da40d11878af","https://git.kernel.org/stable/c/c0acdee513239e1d6e1b490f56be0e6837dfd162","https://git.kernel.org/stable/c/d5ce588a9552878859a4d44b70b724216c188a5f"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71085","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()\n\nThere exists a kernel oops caused by a BUG_ON(nhead < 0) at\nnet/core/skbuff.c:2232 in pskb_expand_head().\nThis bug is triggered as part of the calipso_skbuff_setattr()\nroutine when skb_cow() is passed headroom > INT_MAX\n(i.e. (int)(skb_headroom(skb) + len_delta) < 0).\n\nThe root cause of the bug is due to an implicit integer cast in\n__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensure\nthat delta = headroom - skb_headroom(skb) is never negative, otherwise\nwe will trigger a BUG_ON in pskb_expand_head(). However, if\nheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, delta\nbecomes negative, and pskb_expand_head() is passed a negative value for\nnhead.\n\nFix the trigger condition in calipso_skbuff_setattr(). Avoid passing\n\"negative\" headroom sizes to skb_cow() within calipso_skbuff_setattr()\nby only using skb_cow() to grow headroom.\n\nPoC:\n\tUsing `netlabelctl` tool:\n\n        netlabelctl map del default\n        netlabelctl calipso add pass doi:7\n        netlabelctl map add default address:0::1/128 protocol:calipso,7\n\n        Then run the following PoC:\n\n        int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);\n\n        // setup msghdr\n        int cmsg_size = 2;\n        int cmsg_len = 0x60;\n        struct msghdr msg;\n        struct sockaddr_in6 dest_addr;\n        struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,\n                        sizeof(struct cmsghdr) + cmsg_len);\n        msg.msg_name = &dest_addr;\n        msg.msg_namelen = sizeof(dest_addr);\n        msg.msg_iov = NULL;\n        msg.msg_iovlen = 0;\n        msg.msg_control = cmsg;\n        msg.msg_controllen = cmsg_len;\n        msg.msg_flags = 0;\n\n        // setup sockaddr\n        dest_addr.sin6_family = AF_INET6;\n        dest_addr.sin6_port = htons(31337);\n        dest_addr.sin6_flowinfo = htonl(31337);\n        dest_addr.sin6_addr = in6addr_loopback;\n        dest_addr.sin6_scope_id = 31337;\n\n        // setup cmsghdr\n        cmsg->cmsg_len = cmsg_len;\n        cmsg->cmsg_level = IPPROTO_IPV6;\n        cmsg->cmsg_type = IPV6_HOPOPTS;\n        char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);\n        hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80\n\n        sendmsg(fd, &msg, 0);","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2bb759062efa188ea5d07242a43e5aa5464bbae1","https://git.kernel.org/stable/c/58fc7342b529803d3c221101102fe913df7adb83","https://git.kernel.org/stable/c/6b7522424529556c9cbc15e15e7bd4eeae310910","https://git.kernel.org/stable/c/73744ad5696dce0e0f43872aba8de6a83d6ad570","https://git.kernel.org/stable/c/86f365897068d09418488165a68b23cb5baa37f2","https://git.kernel.org/stable/c/bf3709738d8a8cc6fa275773170c5c29511a0b24","https://git.kernel.org/stable/c/c53aa6a5086f03f19564096ee084a202a8c738c0"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71086","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: fix invalid array index in rose_kill_by_device()\n\nrose_kill_by_device() collects sockets into a local array[] and then\niterates over them to disconnect sockets bound to a device being brought\ndown.\n\nThe loop mistakenly indexes array[cnt] instead of array[i]. For cnt <\nARRAY_SIZE(array), this reads an uninitialized entry; for cnt ==\nARRAY_SIZE(array), it is an out-of-bounds read. Either case can lead to\nan invalid socket pointer dereference and also leaks references taken\nvia sock_hold().\n\nFix the index to use i.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1418c12cd3bba79dc56b57b61c99efe40f579981","https://git.kernel.org/stable/c/6595beb40fb0ec47223d3f6058ee40354694c8e4","https://git.kernel.org/stable/c/819fb41ae54960f66025802400c9d3935eef4042","https://git.kernel.org/stable/c/92d900aac3a5721fb54f3328f1e089b44a861c38","https://git.kernel.org/stable/c/9f6185a32496834d6980b168cffcccc2d6b17280","https://git.kernel.org/stable/c/b409ba9e1e63ccf3ab4cc061e33c1f804183543e","https://git.kernel.org/stable/c/ed2639414d43ba037f798eaf619e878309310451"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71087","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\"i40evf: Allow PF driver to configure RSS\"),\nthe loop upper bounds were:\n    i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n    i <= adapter->rss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=`\naccesses one element past the end.\n\nFix the issues by using `<` instead of `<=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n  BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n  Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n  CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  Workqueue: iavf iavf_watchdog_task\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x6f/0xb0\n   print_report+0x170/0x4f3\n   kasan_report+0xe1/0x1a0\n   iavf_config_rss+0x619/0x800\n   iavf_watchdog_task+0x2be7/0x3230\n   process_one_work+0x7fd/0x1420\n   worker_thread+0x4d1/0xd40\n   kthread+0x344/0x660\n   ret_from_fork+0x249/0x320\n   ret_from_fork_asm+0x1a/0x30\n   </TASK>\n\n  Allocated by task 63:\n   kasan_save_stack+0x30/0x50\n   kasan_save_track+0x14/0x30\n   __kasan_kmalloc+0x7f/0x90\n   __kmalloc_noprof+0x246/0x6f0\n   iavf_watchdog_task+0x28fc/0x3230\n   process_one_work+0x7fd/0x1420\n   worker_thread+0x4d1/0xd40\n   kthread+0x344/0x660\n   ret_from_fork+0x249/0x320\n   ret_from_fork_asm+0x1a/0x30\n\n  The buggy address belongs to the object at ffff888102c50100\n   which belongs to the cache kmalloc-64 of size 64\n  The buggy address is located 0 bytes to the right of\n   allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n  The buggy address belongs to the physical page:\n  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n  flags: 0x200000000000000(node=0|zone=2)\n  page_type: f5(slab)\n  raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n  raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n  page dumped because: kasan: bad access detected\n\n  Memory state around the buggy address:\n   ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n   ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n  >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n                                       ^\n   ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n   ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/18de0e41d69d97fab10b91fecf10ae78a5e43232","https://git.kernel.org/stable/c/3095228e1320371e143835d0cebeef1a8a754c66","https://git.kernel.org/stable/c/5bb18bfd505ca1affbca921462c350095a6c798c","https://git.kernel.org/stable/c/6daa2893f323981c7894c68440823326e93a7d61","https://git.kernel.org/stable/c/ceb8459df28d22c225a82d74c0f725f2a935d194","https://git.kernel.org/stable/c/d7369dc8dd7cbf5cee3a22610028d847b6f02982","https://git.kernel.org/stable/c/f36de3045d006e6d9be1be495f2ed88d1721e752"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71088","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fallback earlier on simult connection\n\nSyzkaller reports a simult-connect race leading to inconsistent fallback\nstatus:\n\n  WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515\n  Modules linked in:\n  CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 Not tainted syzkaller #0 PREEMPT(full)\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n  RIP: 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515\n  Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6\n  RSP: 0018:ffffc900006cf338 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf\n  RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005\n  RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007\n  R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900\n  R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004\n  FS:  0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0\n  Call Trace:\n   <TASK>\n   tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197\n   tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922\n   tcp_v6_do_rcv+0x492/0x1740 net/ipv6/tcp_ipv6.c:1672\n   tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918\n   ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438\n   ip6_input_finish+0x1e4/0x4b0 net/ipv6/ip6_input.c:489\n   NF_HOOK include/linux/netfilter.h:318 [inline]\n   NF_HOOK include/linux/netfilter.h:312 [inline]\n   ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500\n   dst_input include/net/dst.h:471 [inline]\n   ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]\n   NF_HOOK include/linux/netfilter.h:318 [inline]\n   NF_HOOK include/linux/netfilter.h:312 [inline]\n   ipv6_rcv+0x264/0x650 net/ipv6/ip6_input.c:311\n   __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979\n   __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092\n   process_backlog+0x442/0x15e0 net/core/dev.c:6444\n   __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494\n   napi_poll net/core/dev.c:7557 [inline]\n   net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684\n   handle_softirqs+0x216/0x8e0 kernel/softirq.c:579\n   run_ksoftirqd kernel/softirq.c:968 [inline]\n   run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960\n   smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160\n   kthread+0x3c2/0x780 kernel/kthread.c:463\n   ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148\n   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n   </TASK>\n\nThe TCP subflow can process the simult-connect syn-ack packet after\ntransitioning to TCP_FIN1 state, bypassing the MPTCP fallback check,\nas the sk_state_change() callback is not invoked for * -> FIN_WAIT1\ntransitions.\n\nThat will move the msk socket to an inconsistent status and the next\nincoming data will hit the reported splat.\n\nClose the race moving the simult-fallback check at the earliest possible\nstage - that is at syn-ack generation time.\n\nAbout the fixes tags: [2] was supposed to also fix this issue introduced\nby [3]. [1] is required as a dependence: it was not explicitly marked as\na fix, but it is one and it has already been backported before [3]. In\nother words, this commit should be backported up to [3], including [2]\nand [1] if that's not already there.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/25f1ae942c097b7ae4ce5c2b9c6fefb8e3672b86","https://git.kernel.org/stable/c/71154bbe49423128c1c8577b6576de1ed6836830","https://git.kernel.org/stable/c/79f80a7a47849ef1b3c25a0bedcc448b9cb551c1","https://git.kernel.org/stable/c/b5f46a08269265e2f5e87d855287d6d22de0a32b","https://git.kernel.org/stable/c/c9bf315228287653522894df9d851e9b43db9516"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71089","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu: disable SVA when CONFIG_X86 is set\n\nPatch series \"Fix stale IOTLB entries for kernel address space\", v7.\n\nThis proposes a fix for a security vulnerability related to IOMMU Shared\nVirtual Addressing (SVA).  In an SVA context, an IOMMU can cache kernel\npage table entries.  When a kernel page table page is freed and\nreallocated for another purpose, the IOMMU might still hold stale,\nincorrect entries.  This can be exploited to cause a use-after-free or\nwrite-after-free condition, potentially leading to privilege escalation or\ndata corruption.\n\nThis solution introduces a deferred freeing mechanism for kernel page\ntable pages, which provides a safe window to notify the IOMMU to\ninvalidate its caches before the page is reused.\n\n\nThis patch (of 8):\n\nIn the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware\nshares and walks the CPU's page tables.  The x86 architecture maps the\nkernel's virtual address space into the upper portion of every process's\npage table.  Consequently, in an SVA context, the IOMMU hardware can walk\nand cache kernel page table entries.\n\nThe Linux kernel currently lacks a notification mechanism for kernel page\ntable changes, specifically when page table pages are freed and reused. \nThe IOMMU driver is only notified of changes to user virtual address\nmappings.  This can cause the IOMMU's internal caches to retain stale\nentries for kernel VA.\n\nUse-After-Free (UAF) and Write-After-Free (WAF) conditions arise when\nkernel page table pages are freed and later reallocated.  The IOMMU could\nmisinterpret the new data as valid page table entries.  The IOMMU might\nthen walk into attacker-controlled memory, leading to arbitrary physical\nmemory DMA access or privilege escalation.  This is also a\nWrite-After-Free issue, as the IOMMU will potentially continue to write\nAccessed and Dirty bits to the freed memory while attempting to walk the\nstale page tables.\n\nCurrently, SVA contexts are unprivileged and cannot access kernel\nmappings.  However, the IOMMU will still walk kernel-only page tables all\nthe way down to the leaf entries, where it realizes the mapping is for the\nkernel and errors out.  This means the IOMMU still caches these\nintermediate page table entries, making the described vulnerability a real\nconcern.\n\nDisable SVA on x86 architecture until the IOMMU can receive notification\nto flush the paging cache before freeing the CPU kernel page table pages.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.0001,"ranking_epss":0.01053,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/240cd7f2812cc25496b12063d11c823618f364e9","https://git.kernel.org/stable/c/72f98ef9a4be30d2a60136dd6faee376f780d06c","https://git.kernel.org/stable/c/7cad37e358970af1bb49030ff01f06a69fa7d985","https://git.kernel.org/stable/c/b34289505180a83607fcfdce14b5a290d0528476","https://git.kernel.org/stable/c/c2c3f1a3fd74ef16cf115f0c558616a13a8471b4","https://git.kernel.org/stable/c/c341dee80b5df49a936182341b36395c831c2661"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71090","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()\n\nnfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites\nfp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if\nthe client already has a SHARE_ACCESS_READ open from a previous OPEN\noperation, this action overwrites the existing pointer without\nreleasing its reference, orphaning the previous reference.\n\nAdditionally, the function originally stored the same nfsd_file\npointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with\nonly a single reference. When put_deleg_file() runs, it clears\nfi_rdeleg_file and calls nfs4_file_put_access() to release the file.\n\nHowever, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when\nthe fi_access[O_RDONLY] counter drops to zero. If another READ open\nexists on the file, the counter remains elevated and the nfsd_file\nreference from the delegation is never released. This potentially\ncauses open conflicts on that file.\n\nThen, on server shutdown, these leaks cause __nfsd_file_cache_purge()\nto encounter files with an elevated reference count that cannot be\ncleaned up, ultimately triggering a BUG() in kmem_cache_destroy()\nbecause there are still nfsd_file objects allocated in that cache.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.0508,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/8072e34e1387d03102b788677d491e2bcceef6f5","https://git.kernel.org/stable/c/c07dc84ed67c5a182273171639bacbbb87c12175"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71091","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nteam: fix check for port enabled in team_queue_override_port_prio_changed()\n\nThere has been a syzkaller bug reported recently with the following\ntrace:\n\nlist_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:59!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nCPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59\nCode: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286\nRAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000\nRDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005\nRBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230\nR13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480\nFS:  00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0\nCall Trace:\n <TASK>\n __list_del_entry_valid include/linux/list.h:132 [inline]\n __list_del_entry include/linux/list.h:223 [inline]\n list_del_rcu include/linux/rculist.h:178 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline]\n team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline]\n team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534\n team_option_set drivers/net/team/team_core.c:376 [inline]\n team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653\n genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684\n __sys_sendmsg+0x16d/0x220 net/socket.c:2716\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe problem is in this flow:\n1) Port is enabled, queue_id != 0, in qom_list\n2) Port gets disabled\n        -> team_port_disable()\n        -> team_queue_override_port_del()\n        -> del (removed from list)\n3) Port is disabled, queue_id != 0, not in any list\n4) Priority changes\n        -> team_queue_override_port_prio_changed()\n        -> checks: port disabled && queue_id != 0\n        -> calls del - hits the BUG as it is removed already\n\nTo fix this, change the check in team_queue_override_port_prio_changed()\nso it returns early if port is not enabled.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/107d245f84cb4f55f597d31eda34b42a2b7d6952","https://git.kernel.org/stable/c/25029e813c4aae5fcf7118e8dd5c56e382b9a1a3","https://git.kernel.org/stable/c/53a727a8bfd78c739e130a781192d0f6f8e03d39","https://git.kernel.org/stable/c/6bfb62b6010a16112dcae52f490e5e0e6abe12a3","https://git.kernel.org/stable/c/932ac51d9953eaf77a1252f79b656d4ca86163c6","https://git.kernel.org/stable/c/b71187648ef2349254673d0523fdf96d1fe3d758","https://git.kernel.org/stable/c/f820e438b8ec2a8354e70e75145f05fe45500d97"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71092","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Fix OOB write in bnxt_re_copy_err_stats()\n\nCommit ef56081d1864 (\"RDMA/bnxt_re: RoCE related hardware counters\nupdate\") added three new counters and placed them after\nBNXT_RE_OUT_OF_SEQ_ERR.\n\nBNXT_RE_OUT_OF_SEQ_ERR acts as a boundary marker for allocating hardware\nstatistics with different num_counters values on chip_gen_p5_p7 devices.\n\nAs a result, BNXT_RE_NUM_STD_COUNTERS are used when allocating\nhw_stats, which leads to an out-of-bounds write in\nbnxt_re_copy_err_stats().\n\nThe counters BNXT_RE_REQ_CQE_ERROR, BNXT_RE_RESP_CQE_ERROR, and\nBNXT_RE_RESP_REMOTE_ACCESS_ERRS are applicable to generic hardware, not\nonly p5/p7 devices.\n\nFix this by moving these counters before BNXT_RE_OUT_OF_SEQ_ERR so they\nare included in the generic counter set.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00019,"ranking_epss":0.05102,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/369a161c48723f60f06f3510b82ea7d96d0499ab","https://git.kernel.org/stable/c/9b68a1cc966bc947d00e4c0df7722d118125aa37"],"published_time":"2026-01-13T16:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71076","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/oa: Limit num_syncs to prevent oversized allocations\n\nThe OA open parameters did not validate num_syncs, allowing\nuserspace to pass arbitrarily large values, potentially\nleading to excessive allocations.\n\nAdd check to ensure that num_syncs does not exceed DRM_XE_MAX_SYNCS,\nreturning -EINVAL when the limit is violated.\n\nv2: use XE_IOCTL_DBG() and drop duplicated check. (Ashutosh)\n\n(cherry picked from commit e057b2d2b8d815df3858a87dffafa2af37e5945b)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/338849090ee610ff6d11e5e90857d2c27a4121ab","https://git.kernel.org/stable/c/b963636331fb4f3f598d80492e2fa834757198eb","https://git.kernel.org/stable/c/f8dd66bfb4e184c71bd26418a00546ebe7f5c17a"],"published_time":"2026-01-13T16:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71077","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Cap the number of PCR banks\n\ntpm2_get_pcr_allocation() does not cap any upper limit for the number of\nbanks. Cap the limit to eight banks so that out of bounds values coming\nfrom external I/O cause on only limited harm.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/275c686f1e3cc056ec66c764489ec1fe1e51b950","https://git.kernel.org/stable/c/858344bc9210bea9ab2bdc7e9e331ba84c164e50","https://git.kernel.org/stable/c/8ceee7288152bc121a6bf92997261838c78bfe06","https://git.kernel.org/stable/c/b69492161c056d36789aee42a87a33c18c8ed5e1","https://git.kernel.org/stable/c/ceb70d31da5671d298bad94ae6c20e4bbb800f96","https://git.kernel.org/stable/c/d88481653d74d622d1d0d2c9bad845fc2cc6fd23","https://git.kernel.org/stable/c/faf07e611dfa464b201223a7253e9dc5ee0f3c9e"],"published_time":"2026-01-13T16:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71078","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64s/slb: Fix SLB multihit issue during SLB preload\n\nOn systems using the hash MMU, there is a software SLB preload cache that\nmirrors the entries loaded into the hardware SLB buffer. This preload\ncache is subject to periodic eviction — typically after every 256 context\nswitches — to remove old entry.\n\nTo optimize performance, the kernel skips switch_mmu_context() in\nswitch_mm_irqs_off() when the prev and next mm_struct are the same.\nHowever, on hash MMU systems, this can lead to inconsistencies between\nthe hardware SLB and the software preload cache.\n\nIf an SLB entry for a process is evicted from the software cache on one\nCPU, and the same process later runs on another CPU without executing\nswitch_mmu_context(), the hardware SLB may retain stale entries. If the\nkernel then attempts to reload that entry, it can trigger an SLB\nmulti-hit error.\n\nThe following timeline shows how stale SLB entries are created and can\ncause a multi-hit error when a process moves between CPUs without a\nMMU context switch.\n\nCPU 0                                   CPU 1\n-----                                    -----\nProcess P\nexec                                    swapper/1\n load_elf_binary\n  begin_new_exc\n    activate_mm\n     switch_mm_irqs_off\n      switch_mmu_context\n       switch_slb\n       /*\n        * This invalidates all\n        * the entries in the HW\n        * and setup the new HW\n        * SLB entries as per the\n        * preload cache.\n        */\ncontext_switch\nsched_migrate_task migrates process P to cpu-1\n\nProcess swapper/0                       context switch (to process P)\n(uses mm_struct of Process P)           switch_mm_irqs_off()\n                                         switch_slb\n                                           load_slb++\n                                            /*\n                                            * load_slb becomes 0 here\n                                            * and we evict an entry from\n                                            * the preload cache with\n                                            * preload_age(). We still\n                                            * keep HW SLB and preload\n                                            * cache in sync, that is\n                                            * because all HW SLB entries\n                                            * anyways gets evicted in\n                                            * switch_slb during SLBIA.\n                                            * We then only add those\n                                            * entries back in HW SLB,\n                                            * which are currently\n                                            * present in preload_cache\n                                            * (after eviction).\n                                            */\n                                        load_elf_binary continues...\n                                         setup_new_exec()\n                                          slb_setup_new_exec()\n\n                                        sched_switch event\n                                        sched_migrate_task migrates\n                                        process P to cpu-0\n\ncontext_switch from swapper/0 to Process P\n switch_mm_irqs_off()\n  /*\n   * Since both prev and next mm struct are same we don't call\n   * switch_mmu_context(). This will cause the HW SLB and SW preload\n   * cache to go out of sync in preload_new_slb_context. Because there\n   * was an SLB entry which was evicted from both HW and preload cache\n   * on cpu-1. Now later in preload_new_slb_context(), when we will try\n   * to add the same preload entry again, we will add this to the SW\n   * preload cache and then will add it to the HW SLB. Since on cpu-0\n   * this entry was never invalidated, hence adding this entry to the HW\n   * SLB will cause a SLB multi-hit error.\n   */\nload_elf_binary cont\n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/00312419f0863964625d6dcda8183f96849412c6","https://git.kernel.org/stable/c/01324c0328181b94cf390bda22ff91c75126ea57","https://git.kernel.org/stable/c/2e9a95d60f1df7b57618fd5ef057aef331575bd2","https://git.kernel.org/stable/c/4ae1e46d8a290319f33f71a2710a1382ba5431e8","https://git.kernel.org/stable/c/895123c309a34d2cfccf7812b41e17261a3a6f37","https://git.kernel.org/stable/c/b13a3dbfa196af68eae2031f209743735ad416bf","https://git.kernel.org/stable/c/c9f865022a1823d814032a09906e91e4701a35fc"],"published_time":"2026-01-13T16:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71079","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write\n\nA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()\ndue to lock ordering inversion between device_lock and rfkill_global_mutex.\n\nThe problematic lock order is:\n\nThread A (rfkill_fop_write):\n  rfkill_fop_write()\n    mutex_lock(&rfkill_global_mutex)\n      rfkill_set_block()\n        nfc_rfkill_set_block()\n          nfc_dev_down()\n            device_lock(&dev->dev)    <- waits for device_lock\n\nThread B (nfc_unregister_device):\n  nfc_unregister_device()\n    device_lock(&dev->dev)\n      rfkill_unregister()\n        mutex_lock(&rfkill_global_mutex)  <- waits for rfkill_global_mutex\n\nThis creates a classic ABBA deadlock scenario.\n\nFix this by moving rfkill_unregister() and rfkill_destroy() outside the\ndevice_lock critical section. Store the rfkill pointer in a local variable\nbefore releasing the lock, then call rfkill_unregister() after releasing\ndevice_lock.\n\nThis change is safe because rfkill_fop_write() holds rfkill_global_mutex\nwhile calling the rfkill callbacks, and rfkill_unregister() also acquires\nrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will\nwait for any ongoing callback to complete before proceeding, and\ndevice_del() is only called after rfkill_unregister() returns, preventing\nany use-after-free.\n\nThe similar lock ordering in nfc_register_device() (device_lock ->\nrfkill_global_mutex via rfkill_register) is safe because during\nregistration the device is not yet in rfkill_list, so no concurrent\nrfkill operations can occur on this device.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0002,"ranking_epss":0.0527,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5","https://git.kernel.org/stable/c/2e0831e9fc46a06daa6d4d8d57a2738e343130c3","https://git.kernel.org/stable/c/6b93c8ab6f6cda8818983a4ae3fcf84b023037b4","https://git.kernel.org/stable/c/8fc4632fb508432895430cd02b38086bdd649083","https://git.kernel.org/stable/c/e02a1c33f10a0ed3aba855ab8ae2b6c4c5be8012","https://git.kernel.org/stable/c/ee41f4f3ccf8cd6ba3732e867abbec7e6d8d12e5","https://git.kernel.org/stable/c/f3a8a7c1aa278f2378b2f3a10500c6674dffdfda"],"published_time":"2026-01-13T16:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71080","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix a BUG in rt6_get_pcpu_route() under PREEMPT_RT\n\nOn PREEMPT_RT kernels, after rt6_get_pcpu_route() returns NULL, the\ncurrent task can be preempted. Another task running on the same CPU\nmay then execute rt6_make_pcpu_route() and successfully install a\npcpu_rt entry. When the first task resumes execution, its cmpxchg()\nin rt6_make_pcpu_route() will fail because rt6i_pcpu is no longer\nNULL, triggering the BUG_ON(prev). It's easy to reproduce it by adding\nmdelay() after rt6_get_pcpu_route().\n\nUsing preempt_disable/enable is not appropriate here because\nip6_rt_pcpu_alloc() may sleep.\n\nFix this by handling the cmpxchg() failure gracefully on PREEMPT_RT:\nfree our allocation and return the existing pcpu_rt installed by\nanother task. The BUG_ON is replaced by WARN_ON_ONCE for non-PREEMPT_RT\nkernels where such races should not occur.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04379,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1adaea51c61b52e24e7ab38f7d3eba023b2d050d","https://git.kernel.org/stable/c/1dc33ad0867325f8d2c6d7b2a6f542d4f3121f66","https://git.kernel.org/stable/c/787515ccb2292f82eb0876993129154629a49651"],"published_time":"2026-01-13T16:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71081","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: stm32: sai: fix OF node leak on probe\n\nThe reference taken to the sync provider OF node when probing the\nplatform device is currently only dropped if the set_sync() callback\nfails during DAI probe.\n\nMake sure to drop the reference on platform probe failures (e.g. probe\ndeferral) and on driver unbind.\n\nThis also avoids a potential use-after-free in case the DAI is ever\nreprobed without first rebinding the platform driver.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04343,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/23261f0de09427367e99f39f588e31e2856a690e","https://git.kernel.org/stable/c/3752afcc6d80d5525e236e329895ba2cb93bcb26","https://git.kernel.org/stable/c/4054a3597d047f3fe87864ef87f399b5d523e6c0","https://git.kernel.org/stable/c/7daa50a2157e41c964b745ab1dc378b5b3b626d1","https://git.kernel.org/stable/c/acda653169e180b1d860dbb6bc5aceb105858394","https://git.kernel.org/stable/c/bae74771fc5d3b2a9cf6f5aa64596083d032c4a3"],"published_time":"2026-01-13T16:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71082","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: revert use of devm_kzalloc in btusb\n\nThis reverts commit 98921dbd00c4e (\"Bluetooth: Use devm_kzalloc in\nbtusb.c file\").\n\nIn btusb_probe(), we use devm_kzalloc() to allocate the btusb data. This\nties the lifetime of all the btusb data to the binding of a driver to\none interface, INTF. In a driver that binds to other interfaces, ISOC\nand DIAG, this is an accident waiting to happen.\n\nThe issue is revealed in btusb_disconnect(), where calling\nusb_driver_release_interface(&btusb_driver, data->intf) will have devm\nfree the data that is also being used by the other interfaces of the\ndriver that may not be released yet.\n\nTo fix this, revert the use of devm and go back to freeing memory\nexplicitly.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1e54c19eaf84ba652c4e376571093e58e144b339","https://git.kernel.org/stable/c/252714f1e8bdd542025b16321c790458014d6880","https://git.kernel.org/stable/c/c0ecb3e4451fe94f4315e6d09c4046dfbc42090b","https://git.kernel.org/stable/c/cca0e9206e3bcc63cd3e72193e60149165d493cc","https://git.kernel.org/stable/c/fdf7c640fb8a44a59b0671143d8c2f738bc48003","https://git.kernel.org/stable/c/fff9206b0907252a41eb12b7c1407b9347df18b1"],"published_time":"2026-01-13T16:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71083","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: Avoid NULL pointer deref for evicted BOs\n\nIt is possible for a BO to exist that is not currently associated with a\nresource, e.g. because it has been evicted.\n\nWhen devcoredump tries to read the contents of all BOs for dumping, we need\nto expect this as well -- in this case, ENODATA is recorded instead of the\nbuffer contents.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3d004f7341d4898889801ebb2ef61ffca610dd6f","https://git.kernel.org/stable/c/47a85604a761005d255ae38115ee630cc6931756","https://git.kernel.org/stable/c/491adc6a0f9903c32b05f284df1148de39e8e644","https://git.kernel.org/stable/c/4b9944493c6d92d7b29cfd83aaf3deb842b8da79","https://git.kernel.org/stable/c/5a81095d3e1b521ac7cfe3b14d5f149bace3d6e0","https://git.kernel.org/stable/c/b94182b3d7228aec18d069cba56d5982e9bfe1b1"],"published_time":"2026-01-13T16:16:07","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71068","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: bound check rq_pages index in inline path\n\nsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without\nverifying rc_curpage stays within the allocated page array. Add guards\nbefore the first use and after advancing to a new page.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5f140b525180c628db8fa6c897f138194a2de417","https://git.kernel.org/stable/c/7ba826aae1d43212f3baa53a2175ad949e21926e","https://git.kernel.org/stable/c/a22316f5e9a29e4b92030bd8fb9435fe0eb1d5c9","https://git.kernel.org/stable/c/d1bea0ce35b6095544ee82bb54156fc62c067e58","https://git.kernel.org/stable/c/da1ccfc4c452541584a4eae89e337cfa21be6d5a"],"published_time":"2026-01-13T16:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71071","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/mediatek: fix use-after-free on probe deferral\n\nThe driver is dropping the references taken to the larb devices during\nprobe after successful lookup as well as on errors. This can\npotentially lead to a use-after-free in case a larb device has not yet\nbeen bound to its driver so that the iommu driver probe defers.\n\nFix this by keeping the references as expected while the iommu driver is\nbound.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1ef70a0b104ae8011811f60bcfaa55ff49385171","https://git.kernel.org/stable/c/5c04217d06a1161aaf36267e9d971ab6f847d5a7","https://git.kernel.org/stable/c/896ec55da3b90bdb9fc04fedc17ad8c359b2eee5","https://git.kernel.org/stable/c/de83d4617f9fe059623e97acf7e1e10d209625b5","https://git.kernel.org/stable/c/f6c08d3aa441bbc1956e9d65f1cbb89113a5aa8a"],"published_time":"2026-01-13T16:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71072","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nshmem: fix recovery on rename failures\n\nmaple_tree insertions can fail if we are seriously short on memory;\nsimple_offset_rename() does not recover well if it runs into that.\nThe same goes for simple_offset_rename_exchange().\n\nMoreover, shmem_whiteout() expects that if it succeeds, the caller will\nprogress to d_move(), i.e. that shmem_rename2() won't fail past the\nsuccessful call of shmem_whiteout().\n\nNot hard to fix, fortunately - mtree_store() can't fail if the index we\nare trying to store into is already present in the tree as a singleton.\n\nFor simple_offset_rename_exchange() that's enough - we just need to be\ncareful about the order of operations.\n\nFor simple_offset_rename() solution is to preinsert the target into the\ntree for new_dir; the rest can be done without any potentially failing\noperations.\n\nThat preinsertion has to be done in shmem_rename2() rather than in\nsimple_offset_rename() itself - otherwise we'd need to deal with the\npossibility of failure after successful shmem_whiteout().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.04259,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4642686699a46718d7f2fb5acd1e9d866a9d9cca","https://git.kernel.org/stable/c/4b0fe71fb3965d0db83cdfc2f4fe0b3227d70113","https://git.kernel.org/stable/c/e1b4c6a58304fd490124cc2b454d80edc786665c"],"published_time":"2026-01-13T16:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71073","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nInput: lkkbd - disable pending work before freeing device\n\nlkkbd_interrupt() schedules lk->tq via schedule_work(), and the work\nhandler lkkbd_reinit() dereferences the lkkbd structure and its\nserio/input_dev fields.\n\nlkkbd_disconnect() and error paths in lkkbd_connect() free the lkkbd\nstructure without preventing the reinit work from being queued again\nuntil serio_close() returns. This can allow the work handler to run\nafter the structure has been freed, leading to a potential use-after-free.\n\nUse disable_work_sync() instead of cancel_work_sync() to ensure the\nreinit work cannot be re-queued, and call it both in lkkbd_disconnect()\nand in lkkbd_connect() error paths after serio_open().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00017,"ranking_epss":0.04296,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3a7cd1397c209076c371d53bf39a55c138f62342","https://git.kernel.org/stable/c/cffc4e29b1e2d44ab094cf142d7c461ff09b9104","https://git.kernel.org/stable/c/e58c88f0cb2d8ed89de78f6f17409d29cfab6c5c"],"published_time":"2026-01-13T16:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71074","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfunctionfs: fix the open/removal races\n\nffs_epfile_open() can race with removal, ending up with file->private_data\npointing to freed object.\n\nThere is a total count of opened files on functionfs (both ep0 and\ndynamic ones) and when it hits zero, dynamic files get removed.\nUnfortunately, that removal can happen while another thread is\nin ffs_epfile_open(), but has not incremented the count yet.\nIn that case open will succeed, leaving us with UAF on any subsequent\nread() or write().\n\nThe root cause is that ffs->opened is misused; atomic_dec_and_test() vs.\natomic_add_return() is not a good idea, when object remains visible all\nalong.\n\nTo untangle that\n\t* serialize openers on ffs->mutex (both for ep0 and for dynamic files)\n\t* have dynamic ones use atomic_inc_not_zero() and fail if we had\nzero ->opened; in that case the file we are opening is doomed.\n\t* have the inodes of dynamic files marked on removal (from the\ncallback of simple_recursive_removal()) - clear ->i_private there.\n\t* have open of dynamic ones verify they hadn't been already removed,\nalong with checking that state is FFS_ACTIVE.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":7e-05,"ranking_epss":0.00457,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/e5bf5ee266633cb18fff6f98f0b7d59a62819eee"],"published_time":"2026-01-13T16:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-71075","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: aic94xx: fix use-after-free in device removal path\n\nThe asd_pci_remove() function fails to synchronize with pending tasklets\nbefore freeing the asd_ha structure, leading to a potential\nuse-after-free vulnerability.\n\nWhen a device removal is triggered (via hot-unplug or module unload),\nrace condition can occur.\n\nThe fix adds tasklet_kill() before freeing the asd_ha structure,\nensuring all scheduled tasklets complete before cleanup proceeds.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04372,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/278455a82245a572aeb218a6212a416a98e418de","https://git.kernel.org/stable/c/751c19635c2bfaaf2836a533caa3663633066dcf","https://git.kernel.org/stable/c/a41dc180b6e1229ae49ca290ae14d82101c148c3","https://git.kernel.org/stable/c/b3e655e52b98a1d3df41c8e42035711e083099f8","https://git.kernel.org/stable/c/c8f6f88cd1df35155258285c4f43268b361819df","https://git.kernel.org/stable/c/e354793a7ab9bb0934ea699a9d57bcd1b48fc27b","https://git.kernel.org/stable/c/f6ab594672d4cba08540919a4e6be2e202b60007"],"published_time":"2026-01-13T16:16:06","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68823","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nublk: fix deadlock when reading partition table\n\nWhen one process(such as udev) opens ublk block device (e.g., to read\nthe partition table via bdev_open()), a deadlock[1] can occur:\n\n1. bdev_open() grabs disk->open_mutex\n2. The process issues read I/O to ublk backend to read partition table\n3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request()\n   runs bio->bi_end_io() callbacks\n4. If this triggers fput() on file descriptor of ublk block device, the\n   work may be deferred to current task's task work (see fput() implementation)\n5. This eventually calls blkdev_release() from the same context\n6. blkdev_release() tries to grab disk->open_mutex again\n7. Deadlock: same task waiting for a mutex it already holds\n\nThe fix is to run blk_update_request() and blk_mq_end_request() with bottom\nhalves disabled. This forces blkdev_release() to run in kernel work-queue\ncontext instead of current task work context, and allows ublk server to make\nforward progress, and avoids the deadlock.\n\n[axboe: rewrite comment in ublk]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00455,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0460e09a614291f06c008443f47393c37b7358e7","https://git.kernel.org/stable/c/64c0b7e2293757e8320f13434cd809f1c9257a62","https://git.kernel.org/stable/c/9bcc47343ee0ef346aa7b2b460c8ff56bd882fe7","https://git.kernel.org/stable/c/c258f5c4502c9667bccf5d76fa731ab9c96687c1"],"published_time":"2026-01-13T16:16:04","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68817","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency\n\nUnder high concurrency, A tree-connection object (tcon) is freed on\na disconnect path while another path still holds a reference and later\nexecutes *_put()/write on it.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.0001,"ranking_epss":0.00992,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/063cbbc6f595ea36ad146e1b7d2af820894beb21","https://git.kernel.org/stable/c/21a3d01fc6db5129f81edb0ab7cb94fd758bcbea","https://git.kernel.org/stable/c/446beed646b2e426dd53d27358365f8678e1dd01","https://git.kernel.org/stable/c/b39a1833cc4a2755b02603eec3a71a85e9dff926","https://git.kernel.org/stable/c/d092de8a26c952379ded8e6b0bda31d89befac1a","https://git.kernel.org/stable/c/d64977495e44855f2b28d8ce56107c963a7a50e4"],"published_time":"2026-01-13T16:16:03","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69271","summary":"Insufficiently Protected Credentials vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Sniffing Attacks.This issue affects DX NetOps Spectrum: 24.3.13 and earlier.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00049,"ranking_epss":0.15481,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69272","summary":"Cleartext Transmission of Sensitive Information vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Sniffing Attacks.This issue affects DX NetOps Spectrum: 21.2.1 and earlier.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.0002,"ranking_epss":0.05439,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69273","summary":"Improper Authentication vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Authentication Bypass.This issue affects DX NetOps Spectrum: 24.3.10 and earlier.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00079,"ranking_epss":0.23497,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69274","summary":"Authorization Bypass Through User-Controlled Key vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Privilege Escalation.This issue affects DX NetOps Spectrum: 24.3.10 and earlier.","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00062,"ranking_epss":0.19452,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69275","summary":"Dependency on Vulnerable Third-Party Component vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows DOM-Based XSS.This issue affects DX NetOps Spectrum: 24.3.9 and earlier.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00041,"ranking_epss":0.12482,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69276","summary":"Deserialization of Untrusted Data vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Object Injection.This issue affects DX NetOps Spectrum: 24.3.13 and earlier.","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00228,"ranking_epss":0.45628,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69268","summary":"Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Reflected XSS.This issue affects DX NetOps Spectrum: 24.3.8 and earlier.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00041,"ranking_epss":0.12482,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:10","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69269","summary":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows OS Command Injection.This issue affects DX NetOps Spectrum: 23.3.6 and earlier.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00158,"ranking_epss":0.36841,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:10","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69270","summary":"Information Exposure Through Query Strings in GET Request vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Session Hijacking.This issue affects DX NetOps Spectrum: 24.3.8 and earlier.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00067,"ranking_epss":0.20893,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:10","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-69267","summary":"Improper Limitation of a Pathname to a Restricted Directory (Path Traversal) vulnerability in Broadcom DX NetOps Spectrum on Windows, Linux allows Path Traversal.This issue affects DX NetOps Spectrum: 24.3.8 and earlier.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00068,"ranking_epss":0.21132,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36756"],"published_time":"2026-01-12T05:16:09","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12776","summary":"The Report Builder component of the application stores user input directly in a web page and displays it to other users, which raised concerns about a possible Cross-Site Scripting (XSS) attack. Proper management of this functionality helps ensure a secure and seamless user experience.  Although the user input is not validated in the report creation, these scripts are not executed when the report is run by end users. The script is executed when the report is modified through the report builder by a user with edit permissions. \n\n\n\n\nThe Report Builder is part of the WebConsole.  The WebConsole package is currently end of life, and is no longer maintained. We strongly recommend against installing or using it in any production environment. However, if you choose to install it, for example, to access functionality like the Report Builder, it must be deployed within a fully isolated network that has no access to sensitive data or internet connectivity. This is a critical security precaution, as the retired package may contain unpatched vulnerabilities and is no longer supported with updates or fixes.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.0003,"ranking_epss":0.08701,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://documentation.commvault.com/securityadvisories/CV_2025_06_3.html"],"published_time":"2026-01-07T22:15:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67709","summary":"There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00054,"ranking_epss":0.17244,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67710","summary":"There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00054,"ranking_epss":0.17244,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67711","summary":"There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00054,"ranking_epss":0.17244,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67704","summary":"There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00054,"ranking_epss":0.17244,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67705","summary":"There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00054,"ranking_epss":0.17244,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67706","summary":"ArcGIS Server versions 11.5 and earlier on Windows and Linux do not sufficiently validate uploaded files, enabling a remote unauthenticated attacker to upload arbitrary files to the server’s designated upload directories.\n\nHowever, the server’s architecture enforces controls that restrict uploaded files to non‑executable storage locations and prevent modification or replacement of existing application components or system configurations. Uploaded files cannot be executed, leveraged to escalate privileges, or used to access sensitive data.\n\nBecause the issue does not enable execution, service disruption, unauthorized access, or integrity compromise, its impact on confidentiality, integrity, and availability is low. Note that race conditions, secret values, or man‑in‑the‑middle conditions are required for exploitation.","cvss":5.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.6,"epss":0.00092,"ranking_epss":0.26104,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67707","summary":"ArcGIS Server versions 11.5 and earlier on Windows and Linux do not sufficiently validate uploaded files, enabling a remote unauthenticated attacker to upload arbitrary files to the server’s designated upload directories.\n\nHowever, the server’s architecture enforces controls that restrict uploaded files to non‑executable storage locations and prevent modification or replacement of existing application components or system configurations. Uploaded files cannot be executed, leveraged to escalate privileges, or used to access sensitive data.\n\nBecause the issue does not enable execution, service disruption, unauthorized access, or integrity compromise, its impact on confidentiality, integrity, and availability is low. Note that race conditions, secret values, or man‑in‑the‑middle conditions are required for exploitation.","cvss":5.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.6,"epss":0.00293,"ranking_epss":0.52649,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67708","summary":"There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00054,"ranking_epss":0.17244,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-67703","summary":"There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser.","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.00054,"ranking_epss":0.17244,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-security-2025-update-2-patch"],"published_time":"2025-12-31T23:15:40","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-54321","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential null-ptr-deref in device_add()\n\nI got the following null-ptr-deref report while doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nCPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G    B   W        N 6.1.0-rc3+\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n <TASK>\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x196/0x210\n bus_remove_device+0x1bd/0x240\n device_add+0xd3d/0x1100\n w1_add_master_device+0x476/0x490 [wire]\n ds2482_probe+0x303/0x3e0 [ds2482]\n\nThis is how it happened:\n\nw1_alloc_dev()\n  // The dev->driver is set to w1_master_driver.\n  memcpy(&dev->dev, device, sizeof(struct device));\n  device_add()\n    bus_add_device()\n    dpm_sysfs_add() // It fails, calls bus_remove_device.\n\n    // error path\n    bus_remove_device()\n      // The dev->driver is not null, but driver is not bound.\n      __device_release_driver()\n        klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.\n\n    // normal path\n    bus_probe_device() // It's not called yet.\n      device_bind_driver()\n\nIf dev->driver is set, in the error path after calling bus_add_device()\nin device_add(), bus_remove_device() is called, then the device will be\ndetached from driver. But device_bind_driver() is not called yet, so it\ncauses null-ptr-deref while access the 'knode_driver'. To fix this, set\ndev->driver to null in the error path before calling bus_remove_device().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.06957,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/17982304806c5c10924e73f7ca5556e0d7378452","https://git.kernel.org/stable/c/2c59650d078b1b3f1ea50d5f8ee9fcc537dc02d3","https://git.kernel.org/stable/c/7cf515bf9e8c2908dc170ecf2df117162a16c9c5","https://git.kernel.org/stable/c/97aa8fb74bbe9aaf4ed5962a784f73b071bd16bf","https://git.kernel.org/stable/c/f6837f34a34973ef6600c08195ed300e24e97317"],"published_time":"2025-12-30T13:16:21","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-54285","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niomap: Fix possible overflow condition in iomap_write_delalloc_scan\n\nfolio_next_index() returns an unsigned long value which left shifted\nby PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead\nuse folio_pos(folio) + folio_size(folio), which does this correctly.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00011,"ranking_epss":0.01351,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0c6cf409093f307ee05114f834516730c0da5b21","https://git.kernel.org/stable/c/5c281b0c5d18c8eeb1cfd5023f4adb153e6d1240","https://git.kernel.org/stable/c/eee2d2e6ea5550118170dbd5bb1316ceb38455fb"],"published_time":"2025-12-30T13:16:17","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-54207","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nHID: uclogic: Correct devm device reference for hidinput input_dev name\n\nReference the HID device rather than the input device for the devm\nallocation of the input_dev name. Referencing the input_dev would lead to a\nuse-after-free when the input_dev was unregistered and subsequently fires a\nuevent that depends on the name. At the point of firing the uevent, the\nname would be freed by devres management.\n\nUse devm_kasprintf to simplify the logic for allocating memory and\nformatting the input_dev name string.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00024,"ranking_epss":0.06301,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4c2707dfee5847dc0b5ecfbe512c29c93832fdc4","https://git.kernel.org/stable/c/51f49e3927ad545cec0c0afb86856ccacd9f085d","https://git.kernel.org/stable/c/58f0d1c0e494a88f301bf455da7df4366f179bbb","https://git.kernel.org/stable/c/dd613a4e45f8d35f49a63a2064e5308fa5619e29","https://git.kernel.org/stable/c/f283805d984343b2f216e2f4c6c7af265b9542ae","https://git.kernel.org/stable/c/f78bb490b16ecb506d4904be4b00bf9aad6588f9"],"published_time":"2025-12-30T13:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14728","summary":"Rapid7 Velociraptor versions before 0.75.6 contain a directory traversal issue on Linux servers that allows a rogue client to upload a file which is written outside the datastore directory. Velociraptor is normally only allowed to write in the datastore directory. The issue occurs due to insufficient sanitization of directory names which end with a \".\", only encoding the final \".\" AS \"%2E\".\n\n\nAlthough files can be written to incorrect locations, the containing directory must end with \"%2E\". This limits the impact of this vulnerability, and prevents it from overwriting critical files.","cvss":6.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.8,"epss":0.00615,"ranking_epss":0.69852,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://docs.velociraptor.app/announcements/advisories/cve-2025-14728/"],"published_time":"2025-12-29T19:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68749","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix race condition when unbinding BOs\n\nFix 'Memory manager not clean during takedown' warning that occurs\nwhen ivpu_gem_bo_free() removes the BO from the BOs list before it\ngets unmapped. Then file_priv_unbind() triggers a warning in\ndrm_mm_takedown() during context teardown.\n\nProtect the unmapping sequence with bo_list_lock to ensure the BO is\nalways fully unmapped when removed from the list. This ensures the BO\nis either fully unmapped at context teardown time or present on the\nlist and unmapped by file_priv_unbind().","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00017,"ranking_epss":0.03918,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/00812636df370bedf4e44a0c81b86ea96bca8628","https://git.kernel.org/stable/c/0328bb097bef05a796217c54b3d651cc3782827c","https://git.kernel.org/stable/c/d71333ffdd3707d84cfb95acfaf8ba892adc066b","https://git.kernel.org/stable/c/fb16493ebd8f171bcf0772262619618a131f30f7"],"published_time":"2025-12-24T13:16:29","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68725","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Do not let BPF test infra emit invalid GSO types to stack\n\nYinhao et al. reported that their fuzzer tool was able to trigger a\nskb_warn_bad_offload() from netif_skb_features() -> gso_features_check().\nWhen a BPF program - triggered via BPF test infra - pushes the packet\nto the loopback device via bpf_clone_redirect() then mentioned offload\nwarning can be seen. GSO-related features are then rightfully disabled.\n\nWe get into this situation due to convert___skb_to_skb() setting\ngso_segs and gso_size but not gso_type. Technically, it makes sense\nthat this warning triggers since the GSO properties are malformed due\nto the gso_type. Potentially, the gso_type could be marked non-trustworthy\nthrough setting it at least to SKB_GSO_DODGY without any other specific\nassumptions, but that also feels wrong given we should not go further\ninto the GSO engine in the first place.\n\nThe checks were added in 121d57af308d (\"gso: validate gso_type in GSO\nhandlers\") because there were malicious (syzbot) senders that combine\na protocol with a non-matching gso_type. If we would want to drop such\npackets, gso_features_check() currently only returns feature flags via\nnetif_skb_features(), so one location for potentially dropping such skbs\ncould be validate_xmit_unreadable_skb(), but then otoh it would be\nan additional check in the fast-path for a very corner case. Given\nbpf_clone_redirect() is the only place where BPF test infra could emit\nsuch packets, lets reject them right there.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.02122,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/04a899573fb87273a656f178b5f920c505f68875","https://git.kernel.org/stable/c/0f3a60869ca22024dfb9c6fce412b0c70cb4ea36","https://git.kernel.org/stable/c/768376ece7036ecb8604961793a1b72afe6345dd","https://git.kernel.org/stable/c/8670b53b8ee91f028f7240531064020b7413c461","https://git.kernel.org/stable/c/bb7902ed7d7f6d6a7c6c4dc25410d6127ce1085f","https://git.kernel.org/stable/c/e0ffb64a2d72c6705b4a4c9efef600409f7e98a0","https://git.kernel.org/stable/c/fbea4c63b5385588cb44ab21f91e55e33c719a54"],"published_time":"2025-12-24T11:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68365","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Initialize allocated memory before use\n\nKMSAN reports: Multiple uninitialized values detected:\n\n- KMSAN: uninit-value in ntfs_read_hdr (3)\n- KMSAN: uninit-value in bcmp (3)\n\nMemory is allocated by __getname(), which is a wrapper for\nkmem_cache_alloc(). This memory is used before being properly\ncleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to\nproperly allocate and clear memory before use.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.02122,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/192e8ce302f14ac66259231dd10cede19858d742","https://git.kernel.org/stable/c/7d52c592cf53f5bb7163967edc01d2d7d80de44a","https://git.kernel.org/stable/c/a58e29849aef8d26554a982989a2190b49aaf8ed","https://git.kernel.org/stable/c/a8a3ca23bbd9d849308a7921a049330dc6c91398","https://git.kernel.org/stable/c/bdf38063fd15f2fc7361dc0b5d3c259741eab835","https://git.kernel.org/stable/c/f7728057220cabd720e27e46097edad48e5bd728"],"published_time":"2025-12-24T11:16:00","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68358","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix racy bitfield write in btrfs_clear_space_info_full()\n\nFrom the memory-barriers.txt document regarding memory barrier ordering\nguarantees:\n\n (*) These guarantees do not apply to bitfields, because compilers often\n     generate code to modify these using non-atomic read-modify-write\n     sequences.  Do not attempt to use bitfields to synchronize parallel\n     algorithms.\n\n (*) Even in cases where bitfields are protected by locks, all fields\n     in a given bitfield must be protected by one lock.  If two fields\n     in a given bitfield are protected by different locks, the compiler's\n     non-atomic read-modify-write sequences can cause an update to one\n     field to corrupt the value of an adjacent field.\n\nbtrfs_space_info has a bitfield sharing an underlying word consisting of\nthe fields full, chunk_alloc, and flush:\n\nstruct btrfs_space_info {\n        struct btrfs_fs_info *     fs_info;              /*     0     8 */\n        struct btrfs_space_info *  parent;               /*     8     8 */\n        ...\n        int                        clamp;                /*   172     4 */\n        unsigned int               full:1;               /*   176: 0  4 */\n        unsigned int               chunk_alloc:1;        /*   176: 1  4 */\n        unsigned int               flush:1;              /*   176: 2  4 */\n        ...\n\nTherefore, to be safe from parallel read-modify-writes losing a write to\none of the bitfield members protected by a lock, all writes to all the\nbitfields must use the lock. They almost universally do, except for\nbtrfs_clear_space_info_full() which iterates over the space_infos and\nwrites out found->full = 0 without a lock.\n\nImagine that we have one thread completing a transaction in which we\nfinished deleting a block_group and are thus calling\nbtrfs_clear_space_info_full() while simultaneously the data reclaim\nticket infrastructure is running do_async_reclaim_data_space():\n\n          T1                                             T2\nbtrfs_commit_transaction\n  btrfs_clear_space_info_full\n  data_sinfo->full = 0\n  READ: full:0, chunk_alloc:0, flush:1\n                                              do_async_reclaim_data_space(data_sinfo)\n                                              spin_lock(&space_info->lock);\n                                              if(list_empty(tickets))\n                                                space_info->flush = 0;\n                                                READ: full: 0, chunk_alloc:0, flush:1\n                                                MOD/WRITE: full: 0, chunk_alloc:0, flush:0\n                                                spin_unlock(&space_info->lock);\n                                                return;\n  MOD/WRITE: full:0, chunk_alloc:0, flush:1\n\nand now data_sinfo->flush is 1 but the reclaim worker has exited. This\nbreaks the invariant that flush is 0 iff there is no work queued or\nrunning. Once this invariant is violated, future allocations that go\ninto __reserve_bytes() will add tickets to space_info->tickets but will\nsee space_info->flush is set to 1 and not queue the work. After this,\nthey will block forever on the resulting ticket, as it is now impossible\nto kick the worker again.\n\nI also confirmed by looking at the assembly of the affected kernel that\nit is doing RMW operations. For example, to set the flush (3rd) bit to 0,\nthe assembly is:\n  andb    $0xfb,0x60(%rbx)\nand similarly for setting the full (1st) bit to 0:\n  andb    $0xfe,-0x20(%rax)\n\nSo I think this is really a bug on practical systems.  I have observed\na number of systems in this exact state, but am currently unable to\nreproduce it.\n\nRather than leaving this footgun lying around for the future, take\nadvantage of the fact that there is room in the struct anyway, and that\nit is already quite large and simply change the three bitfield members to\nbools. This avoids writes to space_info->full having any effect on\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.02122,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/38e818718c5e04961eea0fa8feff3f100ce40408","https://git.kernel.org/stable/c/55835646da78e83e7ad06abd741ca8fd8c0b0ea7","https://git.kernel.org/stable/c/6f442808a86eef847ee10afa9e6459494ed85bb3","https://git.kernel.org/stable/c/742b90eaf394f0018352c0e10dc89763b2dd5267","https://git.kernel.org/stable/c/b0bb67385480a3aa4c54b139e4f371ddd06b5150","https://git.kernel.org/stable/c/d4a81b8ec639895999275ea2472c69825cd67ea4","https://git.kernel.org/stable/c/db4ae18e1b31e0421fb5312e56aefa382bbc6ece"],"published_time":"2025-12-24T11:15:59","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68351","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix refcount leak in exfat_find\n\nFix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.\n\nFunction `exfat_get_dentry_set` would increase the reference counter of\n`es->bh` on success. Therefore, `exfat_put_dentry_set` must be called\nafter `exfat_get_dentry_set` to ensure refcount consistency. This patch\nrelocate two checks to avoid possible leaks.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":8e-05,"ranking_epss":0.00797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/9aee8de970f18c2aaaa348e3de86c38e2d956c1d","https://git.kernel.org/stable/c/d009ff8959d28d2a33aeb96a5f7e7161c421d78f","https://git.kernel.org/stable/c/fc9ce762525e73438d31b613f18bca92a4d3d578"],"published_time":"2025-12-24T11:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68340","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nteam: Move team device type change at the end of team_port_add\n\nAttempting to add a port device that is already up will expectedly fail,\nbut not before modifying the team device header_ops.\n\nIn the case of the syzbot reproducer the gre0 device is\nalready in state UP when it attempts to add it as a\nport device of team0, this fails but before that\nheader_ops->create of team0 is changed from eth_header to ipgre_header\nin the call to team_dev_type_check_change.\n\nLater when we end up in ipgre_header() struct ip_tunnel* points to nonsense\nas the private data of the device still holds a struct team.\n\nExample sequence of iproute2 commands to reproduce the hang/BUG():\nip link add dev team0 type team\nip link add dev gre0 type gre\nip link set dev gre0 up\nip link set dev gre0 master team0\nip link set dev team0 up\nping -I team0 1.1.1.1\n\nMove team_dev_type_check_change down where all other checks have passed\nas it changes the dev type with no way to restore it in case\none of the checks that follow it fail.\n\nAlso make sure to preserve the origial mtu assignment:\n  - If port_dev is not the same type as dev, dev takes mtu from port_dev\n  - If port_dev is the same type as dev, port_dev takes mtu from dev\n\nThis is done by adding a conditional before the call to dev_set_mtu\nto prevent it from assigning port_dev->mtu = dev->mtu and instead\nletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.\nThe conditional is needed because the patch moves the call to\nteam_dev_type_check_change past dev_set_mtu.\n\nTesting:\n  - team device driver in-tree selftests\n  - Add/remove various devices as slaves of team device\n  - syzbot","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0ae9cfc454ea5ead5f3ddbdfe2e70270d8e2c8ef","https://git.kernel.org/stable/c/4040b5e8963982a00aa821300cb746efc9f2947e","https://git.kernel.org/stable/c/a74ab1b532ecc5f9106621a8f75b4c3d04466b35","https://git.kernel.org/stable/c/c8b15b0d2eec3b5c7f585e5a53dfc8d36c818283","https://git.kernel.org/stable/c/e26235840fd961e4ebe5568f11a2a078cf726663","https://git.kernel.org/stable/c/e3eed4f038214494af62c7d2d64749e5108ce6ca"],"published_time":"2025-12-23T14:16:40","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68333","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Fix possible deadlock in the deferred_irq_workfn()\n\nFor PREEMPT_RT=y kernels, the deferred_irq_workfn() is executed in\nthe per-cpu irq_work/* task context and not disable-irq, if the rq\nreturned by container_of() is current CPU's rq, the following scenarios\nmay occur:\n\nlock(&rq->__lock);\n<Interrupt>\n  lock(&rq->__lock);\n\nThis commit use IRQ_WORK_INIT_HARD() to replace init_irq_work() to\ninitialize rq->scx.deferred_irq_work, make the deferred_irq_workfn()\nis always invoked in hard-irq context.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.03985,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/541959b2fadb832a7d0ceb95041dc52bdcf6bff7","https://git.kernel.org/stable/c/600b4379b9a7ba41340d652211fb29699da4c629","https://git.kernel.org/stable/c/a257e974210320ede524f340ffe16bf4bf0dda1e"],"published_time":"2025-12-22T17:16:01","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14765","summary":"Use after free in WebGPU in Google Chrome prior to 143.0.7499.147 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00127,"ranking_epss":0.32132,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop_16.html","https://issues.chromium.org/issues/448294721"],"published_time":"2025-12-16T23:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14766","summary":"Out of bounds read and write in V8 in Google Chrome prior to 143.0.7499.147 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00101,"ranking_epss":0.28081,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop_16.html","https://issues.chromium.org/issues/466786677"],"published_time":"2025-12-16T23:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33225","summary":"NVIDIA Resiliency Extension for Linux contains a vulnerability in log aggregation, where an attacker could cause predictable log-file names. A successful exploit of this vulnerability may lead to escalation of privileges, code execution, denial of service, information disclosure, and data tampering.","cvss":8.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.4,"epss":0.0005,"ranking_epss":0.158,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://nvd.nist.gov/vuln/detail/CVE-2025-33225","https://nvidia.custhelp.com/app/answers/detail/a_id/5746","https://www.cve.org/CVERecord?id=CVE-2025-33225"],"published_time":"2025-12-16T18:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33235","summary":"NVIDIA Resiliency Extension for Linux contains a vulnerability in the checkpointing core, where an attacker may cause a race condition. A successful exploit of this vulnerability might lead to information disclosure, data tampering, denial of service, or escalation of privileges.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02464,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://nvd.nist.gov/vuln/detail/CVE-2025-33235","https://nvidia.custhelp.com/app/answers/detail/a_id/5746","https://www.cve.org/CVERecord?id=CVE-2025-33235"],"published_time":"2025-12-16T18:16:11","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68223","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: delete radeon_fence_process in is_signaled, no deadlock\n\nDelete the attempt to progress the queue when checking if fence is\nsignaled. This avoids deadlock.\n\ndma-fence_ops::signaled can be called with the fence lock in unknown\nstate. For radeon, the fence lock is also the wait queue lock. This can\ncause a self deadlock when signaled() tries to make forward progress on\nthe wait queue. But advancing the queue is unneeded because incorrectly\nreturning false from signaled() is perfectly acceptable.\n\n(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0002,"ranking_epss":0.05239,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/73bc12d6a547f9571ce4393acfd73c004e2df9e5","https://git.kernel.org/stable/c/7e3e9b3a44c23c8eac86a41308c05077d6d30f41","https://git.kernel.org/stable/c/9d0ed508a9e2af82951ce7d834f58c139fc2bd9b","https://git.kernel.org/stable/c/9eb00b5f5697bd56baa3222c7a1426fa15bacfb5","https://git.kernel.org/stable/c/d40a72d7e3bad4dfb311ef078f5a57362f088c7f"],"published_time":"2025-12-16T14:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68211","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksm: use range-walk function to jump over holes in scan_get_next_rmap_item\n\nCurrently, scan_get_next_rmap_item() walks every page address in a VMA to\nlocate mergeable pages.  This becomes highly inefficient when scanning\nlarge virtual memory areas that contain mostly unmapped regions, causing\nksmd to use large amount of cpu without deduplicating much pages.\n\nThis patch replaces the per-address lookup with a range walk using\nwalk_page_range().  The range walker allows KSM to skip over entire\nunmapped holes in a VMA, avoiding unnecessary lookups.  This problem was\npreviously discussed in [1].\n\nConsider the following test program which creates a 32 TiB mapping in the\nvirtual address space but only populates a single page:\n\n#include <unistd.h>\n#include <stdio.h>\n#include <sys/mman.h>\n\n/* 32 TiB */\nconst size_t size = 32ul * 1024 * 1024 * 1024 * 1024;\n\nint main() {\n        char *area = mmap(NULL, size, PROT_READ | PROT_WRITE,\n                          MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0);\n\n        if (area == MAP_FAILED) {\n                perror(\"mmap() failed\\n\");\n                return -1;\n        }\n\n        /* Populate a single page such that we get an anon_vma. */\n        *area = 0;\n\n        /* Enable KSM. */\n        madvise(area, size, MADV_MERGEABLE);\n        pause();\n        return 0;\n}\n\n$ ./ksm-sparse  &\n$ echo 1 > /sys/kernel/mm/ksm/run \n\nWithout this patch ksmd uses 100% of the cpu for a long time (more then 1\nhour in my test machine) scanning all the 32 TiB virtual address space\nthat contain only one mapped page.  This makes ksmd essentially deadlocked\nnot able to deduplicate anything of value.  With this patch ksmd walks\nonly the one mapped page and skips the rest of the 32 TiB virtual address\nspace, making the scan fast using little cpu.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.0702,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/10644e8839544dd5699c03c8fb1aeeefc41602fd","https://git.kernel.org/stable/c/220cb3e425e17587f560335924cba9f16a842c64","https://git.kernel.org/stable/c/67137b715b7db28d82e4ed07a7092c2fa6ba7adb","https://git.kernel.org/stable/c/74f78421c925b6d17695566f0c5941de57fd44b3","https://git.kernel.org/stable/c/9c2f8a9b68024e5ebb4813665845ec0a95f2eac3","https://git.kernel.org/stable/c/f5548c318d6520d4fa3c5ed6003eeb710763cbc5","https://git.kernel.org/stable/c/f62973e0767e4fcd6799087787fca08ca2a85b8c"],"published_time":"2025-12-16T14:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-68214","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntimers: Fix NULL function pointer race in timer_shutdown_sync()\n\nThere is a race condition between timer_shutdown_sync() and timer\nexpiration that can lead to hitting a WARN_ON in expire_timers().\n\nThe issue occurs when timer_shutdown_sync() clears the timer function\nto NULL while the timer is still running on another CPU. The race\nscenario looks like this:\n\nCPU0\t\t\t\t\tCPU1\n\t\t\t\t\t<SOFTIRQ>\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tbase->running_timer = timer;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t[call_timer_fn enter]\n\t\t\t\t\tmod_timer()\n\t\t\t\t\t...\ntimer_shutdown_sync()\nlock_timer_base()\n// For now, will not detach the timer but only clear its function to NULL\nif (base->running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer->function = NULL;\nunlock_timer_base()\n\t\t\t\t\t[call_timer_fn exit]\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\tbase->running_timer = NULL;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t...\n\t\t\t\t\t// Now timer is pending while its function set to NULL.\n\t\t\t\t\t// next timer trigger\n\t\t\t\t\t<SOFTIRQ>\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tWARN_ON_ONCE(!fn) // hit\n\t\t\t\t\t...\nlock_timer_base()\n// Now timer will detach\nif (base->running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer->function = NULL;\nunlock_timer_base()\n\nThe problem is that timer_shutdown_sync() clears the timer function\nregardless of whether the timer is currently running. This can leave a\npending timer with a NULL function pointer, which triggers the\nWARN_ON_ONCE(!fn) check in expire_timers().\n\nFix this by only clearing the timer function when actually detaching the\ntimer. If the timer is running, leave the function pointer intact, which is\nsafe because the timer will be properly detached when it finishes running.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.0001,"ranking_epss":0.0102,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/176725f4848376530a0f0da9023f956afcc33585","https://git.kernel.org/stable/c/1a975716cc8977f461e45e28e3e5977d46ad7a6a","https://git.kernel.org/stable/c/20739af07383e6eb1ec59dcd70b72ebfa9ac362c","https://git.kernel.org/stable/c/6665fbd7730b26d770c232b20d1b907e6a67a914","https://git.kernel.org/stable/c/a01efa7a780c42ac5170a949bd95c9786ffcc60a","https://git.kernel.org/stable/c/ba43ac025c4318241f8edf94f31d2eebab86991b"],"published_time":"2025-12-16T14:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14373","summary":"Inappropriate implementation in Toolbar in Google Chrome on Android prior to 143.0.7499.110 allowed a remote attacker to perform domain spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00038,"ranking_epss":0.11411,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/461532432"],"published_time":"2025-12-12T20:15:40","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14174","summary":"Out of bounds memory access in ANGLE in Google Chrome on Mac prior to 143.0.7499.110 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00871,"ranking_epss":0.75187,"kev":true,"propose_action":"Google Chromium contains an out of bounds memory access vulnerability in ANGLE that could allow a remote attacker to perform out of bounds memory access via a crafted HTML page. This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera.","ransomware_campaign":"Unknown","references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/466192044","https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnotes-security","https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-14174"],"published_time":"2025-12-12T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-14372","summary":"Use after free in Password Manager in Google Chrome prior to 143.0.7499.110 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.1,"epss":0.0005,"ranking_epss":0.15565,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop_10.html","https://issues.chromium.org/issues/460599518"],"published_time":"2025-12-12T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13214","summary":"IBM Aspera Orchestrator 4.0.0 through 4.1.0 is vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.","cvss":7.6,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.6,"epss":0.00143,"ranking_epss":0.34674,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7254434"],"published_time":"2025-12-11T20:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13481","summary":"IBM Aspera Orchestrator 4.0.0 through 4.1.0 could allow an authenticated user to execute arbitrary commands with elevated privileges on the system due to improper validation of user supplied input.","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00058,"ranking_epss":0.1845,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7254434"],"published_time":"2025-12-11T20:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13148","summary":"IBM Aspera Orchestrator 4.0.0 through 4.1.0 could allow could an authenticated user to change the password of another user without prior knowledge of that password.","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.0004,"ranking_epss":0.12265,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7254434"],"published_time":"2025-12-11T20:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13211","summary":"IBM Aspera Orchestrator 4.0.0 through 4.1.0 could allow an authenticated user to cause a denial of service in the email service due to improper control of interaction frequency.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00062,"ranking_epss":0.19606,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7254434"],"published_time":"2025-12-11T20:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12381","summary":"Improper Privilege Management vulnerability in AlgoSec Firewall Analyzer on Linux, 64 bit allows Privilege Escalation, Parameter Injection.\n\nA local user with access to the command line may escalate their privileges by abusing the parameters of a command that is approved in the sudoers file. \nThis issue affects Firewall Analyzer: A33.0, A33.10.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04426,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://techdocs.algosec.com/en/cves/Content/tech-notes/cves/cve-2025-12381.htm"],"published_time":"2025-12-09T16:17:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-40251","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndevlink: rate: Unset parent pointer in devl_rate_nodes_destroy\n\nThe function devl_rate_nodes_destroy is documented to \"Unset parent for\nall rate objects\". However, it was only calling the driver-specific\n`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing\nthe parent's refcount, without actually setting the\n`devlink_rate->parent` pointer to NULL.\n\nThis leaves a dangling pointer in the `devlink_rate` struct, which cause\nrefcount error in netdevsim[1] and mlx5[2]. In addition, this is\ninconsistent with the behavior of `devlink_nl_rate_parent_node_set`,\nwhere the parent pointer is correctly cleared.\n\nThis patch fixes the issue by explicitly setting `devlink_rate->parent`\nto NULL after notifying the driver, thus fulfilling the function's\ndocumented behavior for all rate objects.\n\n[1]\nrepro steps:\necho 1 > /sys/bus/netdevsim/new_device\ndevlink dev eswitch set netdevsim/netdevsim1 mode switchdev\necho 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs\ndevlink port function rate add netdevsim/netdevsim1/test_node\ndevlink port function rate set netdevsim/netdevsim1/128 parent test_node\necho 1 > /sys/bus/netdevsim/del_device\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n <TASK>\n devl_rate_leaf_destroy+0x8d/0x90\n __nsim_dev_port_del+0x6c/0x70 [netdevsim]\n nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]\n nsim_drv_remove+0x2b/0xb0 [netdevsim]\n device_release_driver_internal+0x194/0x1f0\n bus_remove_device+0xc6/0x130\n device_del+0x159/0x3c0\n device_unregister+0x1a/0x60\n del_device_store+0x111/0x170 [netdevsim]\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x55/0x10f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\ndevlink dev eswitch set pci/0000:08:00.0 mode switchdev\ndevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000\ndevlink port function rate add pci/0000:08:00.0/group1\ndevlink port function rate set pci/0000:08:00.0/32768 parent group1\nmodprobe -r mlx5_ib mlx5_fwctl mlx5_core\n\ndmesg:\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0\nCPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x42/0xe0\nCall Trace:\n <TASK>\n devl_rate_leaf_destroy+0x8d/0x90\n mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]\n mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]\n mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]\n mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]\n notifier_call_chain+0x33/0xa0\n blocking_notifier_call_chain+0x3b/0x50\n mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]\n mlx5_eswitch_disable+0x63/0x90 [mlx5_core]\n mlx5_unload+0x1d/0x170 [mlx5_core]\n mlx5_uninit_one+0xa2/0x130 [mlx5_core]\n remove_one+0x78/0xd0 [mlx5_core]\n pci_device_remove+0x39/0xa0\n device_release_driver_internal+0x194/0x1f0\n unbind_store+0x99/0xa0\n kernfs_fop_write_iter+0x12e/0x1e0\n vfs_write+0x215/0x3d0\n ksys_write+0x5f/0xd0\n do_syscall_64+0x53/0x1f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00025,"ranking_epss":0.06957,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/542f45486f1ce2d2dde75bd85aca0389ef7046c3","https://git.kernel.org/stable/c/715d9cda646a8a38ea8b2bb5afb679a7464055e2","https://git.kernel.org/stable/c/90e51e20bcec9bff5b2421ce1bd95704764655f5","https://git.kernel.org/stable/c/c70df6c17d389cc743f0eb30160e2d6bc6910db8","https://git.kernel.org/stable/c/f94c1a114ac209977bdf5ca841b98424295ab1f0"],"published_time":"2025-12-04T16:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33211","summary":"NVIDIA Triton Server for Linux contains a vulnerability where an attacker may cause an improper validation of specified quantity in input. A successful exploit of this vulnerability may lead to denial of service.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00204,"ranking_epss":0.42624,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://nvd.nist.gov/vuln/detail/CVE-2025-33211","https://nvidia.custhelp.com/app/answers/detail/a_id/5734","https://www.cve.org/CVERecord?id=CVE-2025-33211"],"published_time":"2025-12-03T19:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13992","summary":"Side-channel information leakage in Navigation and Loading in Google Chrome prior to 139.0.7258.66 allowed a remote attacker to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00039,"ranking_epss":0.1179,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/08/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/40095391"],"published_time":"2025-12-03T19:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33201","summary":"NVIDIA Triton Inference Server contains a vulnerability where an attacker may cause an improper check for unusual or exceptional conditions issue by sending extra large payloads. A successful exploit of this vulnerability may lead to denial of service.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00135,"ranking_epss":0.33336,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://nvd.nist.gov/vuln/detail/CVE-2025-33201","https://nvidia.custhelp.com/app/answers/detail/a_id/5734","https://www.cve.org/CVERecord?id=CVE-2025-33201"],"published_time":"2025-12-03T19:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13634","summary":"Inappropriate implementation in Downloads in Google Chrome on Windows prior to 143.0.7499.41 allowed a local attacker to bypass mark of the web via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.4,"epss":9e-05,"ranking_epss":0.00819,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/429140219"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13635","summary":"Inappropriate implementation in Downloads in Google Chrome prior to 143.0.7499.41 allowed a local attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)","cvss":4.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.4,"epss":0.0001,"ranking_epss":0.0112,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/405727341"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13636","summary":"Inappropriate implementation in Split View in Google Chrome prior to 143.0.7499.41 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted domain name. (Chromium security severity: Low)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00125,"ranking_epss":0.31863,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/446181124"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13637","summary":"Inappropriate implementation in Downloads in Google Chrome prior to 143.0.7499.41 allowed a remote attacker who convinced a user to engage in specific UI gestures to bypass download protections via a crafted HTML page. (Chromium security severity: Low)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00036,"ranking_epss":0.10707,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/392375329"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13638","summary":"Use after free in Media Stream in Google Chrome prior to 143.0.7499.41 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Low)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00196,"ranking_epss":0.41543,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/448046109"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13639","summary":"Inappropriate implementation in WebRTC in Google Chrome prior to 143.0.7499.41 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page. (Chromium security severity: Low)","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.00054,"ranking_epss":0.17027,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/448408148"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13640","summary":"Inappropriate implementation in Passwords in Google Chrome prior to 143.0.7499.41 allowed a local attacker to bypass authentication via physical access to the device. (Chromium security severity: Low)","cvss":3.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.5,"epss":0.0002,"ranking_epss":0.05275,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/452071826"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13720","summary":"Bad cast in Loader in Google Chrome prior to 143.0.7499.41 allowed a remote attacker who had compromised the renderer process to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00146,"ranking_epss":0.35098,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/457818670"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13721","summary":"Race in v8 in Google Chrome prior to 143.0.7499.41 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00111,"ranking_epss":0.29732,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/355120682"],"published_time":"2025-12-02T19:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13631","summary":"Inappropriate implementation in Google Updater in Google Chrome on Mac prior to 143.0.7499.41 allowed a remote attacker to perform privilege escalation via a crafted file. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00144,"ranking_epss":0.34794,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/448113221"],"published_time":"2025-12-02T19:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13632","summary":"Inappropriate implementation in DevTools in Google Chrome prior to 143.0.7499.41 allowed an attacker who convinced a user to install a malicious extension to potentially perform a sandbox escape via a crafted Chrome Extension. (Chromium security severity: High)","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00031,"ranking_epss":0.08901,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/439058242"],"published_time":"2025-12-02T19:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13633","summary":"Use after free in Digital Credentials in Google Chrome prior to 143.0.7499.41 allowed a remote attacker who had compromised the renderer process to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00196,"ranking_epss":0.41543,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/458082926"],"published_time":"2025-12-02T19:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13630","summary":"Type Confusion in V8 in Google Chrome prior to 143.0.7499.41 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00146,"ranking_epss":0.35098,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/12/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/456547591"],"published_time":"2025-12-02T19:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11933","summary":"Improper Input Validation in the TLS 1.3 CKS extension parsing in wolfSSL 5.8.2 and earlier on multiple platforms allows a remote unauthenticated attacker to potentially cause a denial-of-service via a crafted ClientHello message with duplicate CKS extensions.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00056,"ranking_epss":0.17755,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/wolfSSL/wolfssl","https://github.com/wolfSSL/wolfssl/pull/9132"],"published_time":"2025-11-21T23:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11934","summary":"Improper input validation in the TLS 1.3 CertificateVerify signature algorithm negotiation in wolfSSL 5.8.2 and earlier on multiple platforms allows for downgrading the signature algorithm used. For example when a client sends ECDSA P521 as the supported signature algorithm the server previously could respond as ECDSA P256 being the accepted signature algorithm and the connection would continue with using ECDSA P256, if the client supports ECDSA P256.","cvss":2.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":2.7,"epss":0.00015,"ranking_epss":0.03101,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/wolfSSL/wolfssl","https://github.com/wolfSSL/wolfssl/pull/9113","https://github.com/wolfSSL/wolfssl/pull/9113"],"published_time":"2025-11-21T23:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11935","summary":"With TLS 1.3 pre-shared key (PSK) a malicious or faulty server could ignore the request for PFS (perfect forward secrecy) and the client would continue on with the connection using PSK without PFS. This happened when a server responded to a ClientHello containing psk_dhe_ke without a key_share extension. The re-use of an authenticated PSK connection that on the clients side unexpectedly did not have PFS, reduces the security of the connection.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00011,"ranking_epss":0.01404,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/wolfSSL/wolfssl","https://github.com/wolfSSL/wolfssl/pull/9112"],"published_time":"2025-11-21T22:16:18","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-61949","summary":"LogStare Collector contains a stored cross-site scripting vulnerability in UserManagement. If crafted user information is stored, an arbitrary script may be executed on the web browser of the user who logs in to the product's management page.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00054,"ranking_epss":0.17096,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://jvn.jp/en/jp/JVN77560819/","https://www.logstare.com/vulnerability/2025-001/"],"published_time":"2025-11-21T07:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-62189","summary":"LogStare Collector contains an incorrect authorization vulnerability in UserRegistration. If exploited, a non-administrative user may create a new user account by sending a crafted HTTP request.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00056,"ranking_epss":0.17611,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://jvn.jp/en/jp/JVN77560819/","https://www.logstare.com/vulnerability/2025-001/"],"published_time":"2025-11-21T07:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-62687","summary":"Cross-site request forgery vulnerability exists in LogStare Collector. If a user views a crafted page while logged, unintended operations may be performed.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.0003,"ranking_epss":0.08593,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://jvn.jp/en/jp/JVN77560819/","https://www.logstare.com/vulnerability/2025-001/"],"published_time":"2025-11-21T07:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-64299","summary":"LogStare Collector improperly handles the password hash data. An administrative user may obtain the other users' password hashes.","cvss":4.9,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.9,"epss":0.00052,"ranking_epss":0.16408,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://jvn.jp/en/jp/JVN77560819/","https://www.logstare.com/vulnerability/2025-001/"],"published_time":"2025-11-21T07:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-58097","summary":"The installation directory of LogStare Collector is configured with incorrect access permissions. A non-administrative user may manipulate files within the installation directory and execute arbitrary code with the administrative privilege.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.0395,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://jvn.jp/en/jp/JVN77560819/","https://www.logstare.com/vulnerability/2025-001/"],"published_time":"2025-11-21T07:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36161","summary":"IBM Concert 1.0.0 through 2.0.0 could allow a remote attacker to obtain sensitive information, caused by the failure to properly enable HTTP Strict-Transport-Security. An attacker could exploit this vulnerability to obtain sensitive information using man in the middle techniques.","cvss":5.9,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.9,"epss":0.00025,"ranking_epss":0.06709,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7252019"],"published_time":"2025-11-20T16:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13316","summary":"Twonky Server 8.5.2 on Linux and Windows is vulnerable to a cryptographic flaw, use of hard-coded cryptographic keys. An attacker with knowledge of the encrypted administrator password can decrypt the value with static keys to view the plain text password and gain administrator-level access to Twonky Server.","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.7268,"ranking_epss":0.98765,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.rapid7.com/blog/post/cve-2025-13315-cve-2025-13316-critical-twonky-server-authentication-bypass-not-fixed/"],"published_time":"2025-11-19T18:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13315","summary":"Twonky Server 8.5.2 on Linux and Windows is vulnerable to an access control flaw. An unauthenticated attacker can bypass web service API authentication controls to leak a log file and read the administrator's username and encrypted password.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.82373,"ranking_epss":0.9922,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.rapid7.com/blog/post/cve-2025-13315-cve-2025-13316-critical-twonky-server-authentication-bypass-not-fixed/"],"published_time":"2025-11-19T18:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13229","summary":"Type Confusion in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00146,"ranking_epss":0.35098,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/446113731"],"published_time":"2025-11-18T00:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13230","summary":"Type Confusion in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00146,"ranking_epss":0.35098,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/446124892"],"published_time":"2025-11-18T00:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13226","summary":"Type Confusion in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00146,"ranking_epss":0.35098,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/446113732"],"published_time":"2025-11-18T00:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13227","summary":"Type Confusion in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00146,"ranking_epss":0.35098,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/446122633"],"published_time":"2025-11-18T00:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13228","summary":"Type Confusion in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00146,"ranking_epss":0.35098,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/446124893"],"published_time":"2025-11-18T00:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13224","summary":"Type Confusion in V8 in Google Chrome prior to 142.0.7444.175 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00146,"ranking_epss":0.35098,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/11/stable-channel-update-for-desktop_17.html","https://issues.chromium.org/issues/450328966"],"published_time":"2025-11-17T23:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13223","summary":"Type Confusion in V8 in Google Chrome prior to 142.0.7444.175 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.02686,"ranking_epss":0.85811,"kev":true,"propose_action":"Google Chromium V8 contains a type confusion vulnerability that allows for heap corruption.","ransomware_campaign":"Unknown","references":["https://chromereleases.googleblog.com/2025/11/stable-channel-update-for-desktop_17.html","https://issues.chromium.org/issues/460017370","https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-13223"],"published_time":"2025-11-17T23:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-9479","summary":"Out of bounds read in V8 in Google Chrome prior to 133.0.6943.141 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00134,"ranking_epss":0.33255,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/02/stable-channel-update-for-desktop_25.html","https://issues.chromium.org/issues/390743124"],"published_time":"2025-11-14T03:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13097","summary":"Inappropriate implementation in DevTools in Google Chrome prior to 136.0.7103.59 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium)","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00067,"ranking_epss":0.20814,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/04/stable-channel-update-for-desktop_29.html","https://issues.chromium.org/issues/402791076"],"published_time":"2025-11-14T03:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13107","summary":"Inappropriate implementation in Compositing in Google Chrome prior to 140.0.7339.80 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00136,"ranking_epss":0.33504,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/429440615"],"published_time":"2025-11-14T03:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2024-13178","summary":"Inappropriate implementation in Fullscreen in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00136,"ranking_epss":0.33504,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2024/08/stable-channel-update-for-desktop_21.html","https://issues.chromium.org/issues/40068607"],"published_time":"2025-11-14T03:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2024-7017","summary":"Inappropriate implementation in DevTools in Google Chrome prior to 126.0.6478.182 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00145,"ranking_epss":0.35011,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2024/07/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/338248595"],"published_time":"2025-11-14T03:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-13042","summary":"Inappropriate implementation in V8 in Google Chrome prior to 142.0.7444.166 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00144,"ranking_epss":0.34794,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/11/stable-channel-update-for-desktop_11.html","https://issues.chromium.org/issues/457351015"],"published_time":"2025-11-12T17:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-40164","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Fix using smp_processor_id() in preemptible code warnings\n\nSyzbot reported the following warning:\n\nBUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879\ncaller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331\nCPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49\n usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331\n usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708\n usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417\n __dev_set_mtu net/core/dev.c:9443 [inline]\n netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496\n netif_set_mtu+0xb0/0x160 net/core/dev.c:9520\n dev_set_mtu+0xae/0x170 net/core/dev_api.c:247\n dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572\n dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821\n sock_do_ioctl+0x19d/0x280 net/socket.c:1204\n sock_ioctl+0x42f/0x6a0 net/socket.c:1311\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl fs/ioctl.c:892 [inline]\n __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFor historical and portability reasons, the netif_rx() is usually\nrun in the softirq or interrupt context, this commit therefore add\nlocal_bh_disable/enable() protection in the usbnet_resume_rx().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":9e-05,"ranking_epss":0.00812,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0134c7bff14bd50314a4f92b182850ddfc38e255","https://git.kernel.org/stable/c/17fbad93879e87a334062882b45fa727ba1b3dd7","https://git.kernel.org/stable/c/327cd4b68b4398b6c24f10eb2b2533ffbfc10185","https://git.kernel.org/stable/c/65d04291adf7c59338f87aab9c6fe0bfa9993e64","https://git.kernel.org/stable/c/d1944bab8e0c1511f0cbf364aa06547735bb0ddb","https://git.kernel.org/stable/c/f45fffae5e2549bd0a4670cc52a15ad54c9f121e"],"published_time":"2025-11-12T11:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-40149","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().\n\nget_netdev_for_sock() is called during setsockopt(),\nso not under RCU.\n\nUsing sk_dst_get(sk)->dev could trigger UAF.\n\nLet's use __sk_dst_get() and dst_dev_rcu().\n\nNote that the only ->ndo_sk_get_lower_dev() user is\nbond_sk_get_lower_dev(), which uses RCU.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00023,"ranking_epss":0.06079,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/13159c7125636371543a82cb7bbae00ab36730cc","https://git.kernel.org/stable/c/2b1bef126bbb8d0da51491357559126d567c1dee","https://git.kernel.org/stable/c/c65f27b9c3be2269918e1cbad6d8884741f835c5","https://git.kernel.org/stable/c/e37ca0092ddace60833790b4ad7a390408fb1be9","https://git.kernel.org/stable/c/f09cd209359a23f88d4f3fa3d2379d057027e53c","https://git.kernel.org/stable/c/feb474ddbf26b51f462ae2e60a12013bdcfc5407"],"published_time":"2025-11-12T11:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12382","summary":"Improper Limitation of a Pathname 'Path Traversal') vulnerability in Algosec Firewall Analyzer on Linux, 64 bit allows an authenticated user to upload files to a restricted directory leading to code injection. This issue affects Algosec Firewall Analyzer: A33.0 (up to build 320), A33.10 (up to build 210).","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00109,"ranking_epss":0.29374,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://techdocs.algosec.com/en/cves/Content/tech-notes/cves/cve-2025-12382.htm"],"published_time":"2025-11-12T10:15:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33202","summary":"NVIDIA Triton Inference Server for Linux and Windows contains a vulnerability where an attacker could cause a stack overflow by sending extra-large payloads. A successful exploit of this vulnerability might lead to denial of service.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.001,"ranking_epss":0.27902,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://nvd.nist.gov/vuln/detail/CVE-2025-33202","https://nvidia.custhelp.com/app/answers/detail/a_id/5723","https://www.cve.org/CVERecord?id=CVE-2025-33202"],"published_time":"2025-11-11T17:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12443","summary":"Out of bounds read in WebXR in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00022,"ranking_epss":0.05795,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/452071845"],"published_time":"2025-11-10T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12444","summary":"Incorrect security UI in Fullscreen UI in Google Chrome prior to 142.0.7444.59 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)","cvss":4.2,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.2,"epss":0.00056,"ranking_epss":0.17789,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/390571618"],"published_time":"2025-11-10T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12445","summary":"Policy bypass in Extensions in Google Chrome prior to 142.0.7444.59 allowed an attacker who convinced a user to install a malicious extension to leak cross-origin data via a crafted Chrome Extension. (Chromium security severity: Low)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00016,"ranking_epss":0.03464,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/428397712"],"published_time":"2025-11-10T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12446","summary":"Incorrect security UI in SplitView in Google Chrome prior to 142.0.7444.59 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted domain name. (Chromium security severity: Low)","cvss":4.2,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.2,"epss":0.00057,"ranking_epss":0.18048,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/444932667"],"published_time":"2025-11-10T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12725","summary":"Out of bounds read in WebGPU in Google Chrome on Android prior to 142.0.7444.137 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00091,"ranking_epss":0.25789,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/11/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/443906252"],"published_time":"2025-11-10T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12727","summary":"Inappropriate implementation in V8 in Google Chrome prior to 142.0.7444.137 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00098,"ranking_epss":0.27217,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/11/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/454485895"],"published_time":"2025-11-10T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12728","summary":"Inappropriate implementation in Omnibox in Google Chrome on Android prior to 142.0.7444.137 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.2,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.2,"epss":0.00057,"ranking_epss":0.18048,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/11/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/452392032"],"published_time":"2025-11-10T20:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12436","summary":"Policy bypass in Extensions in Google Chrome prior to 142.0.7444.59 allowed an attacker who convinced a user to install a malicious extension to obtain potentially sensitive information from process memory via a crafted Chrome Extension. (Chromium security severity: Medium)","cvss":5.9,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.9,"epss":0.00014,"ranking_epss":0.02582,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/40054742"],"published_time":"2025-11-10T20:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12437","summary":"Use after free in PageInfo in Google Chrome prior to 142.0.7444.59 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00092,"ranking_epss":0.26087,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/446294487"],"published_time":"2025-11-10T20:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12438","summary":"Use after free in Ozone in Google Chrome on Linux and ChromeOS prior to 142.0.7444.59 allowed a remote attacker to potentially exploit object corruption via a crafted HTML page. (Chromium security severity: Medium)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00092,"ranking_epss":0.26087,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/433027577"],"published_time":"2025-11-10T20:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12440","summary":"Inappropriate implementation in Autofill in Google Chrome prior to 142.0.7444.59 allowed a remote attacker who convinced a user to engage in specific UI gestures to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low)","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00026,"ranking_epss":0.0725,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/430555440"],"published_time":"2025-11-10T20:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12441","summary":"Out of bounds read in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00023,"ranking_epss":0.06235,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/444049512"],"published_time":"2025-11-10T20:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12430","summary":"Object lifecycle issue in Media in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: High)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00039,"ranking_epss":0.11785,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/442860743"],"published_time":"2025-11-10T20:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12431","summary":"Inappropriate implementation in Extensions in Google Chrome prior to 142.0.7444.59 allowed an attacker who convinced a user to install a malicious extension to bypass navigation restrictions via a crafted Chrome Extension. (Chromium security severity: High)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00018,"ranking_epss":0.04483,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/436887350"],"published_time":"2025-11-10T20:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12432","summary":"Race in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00053,"ranking_epss":0.16626,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/439522866"],"published_time":"2025-11-10T20:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12433","summary":"Inappropriate implementation in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00017,"ranking_epss":0.03895,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/449760249"],"published_time":"2025-11-10T20:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12429","summary":"Inappropriate implementation in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00042,"ranking_epss":0.12842,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/450618029"],"published_time":"2025-11-10T20:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12428","summary":"Type Confusion in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00056,"ranking_epss":0.17775,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html","https://issues.chromium.org/issues/447613211"],"published_time":"2025-11-10T20:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11458","summary":"Heap buffer overflow in Sync in Google Chrome prior to 141.0.7390.65 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: High)","cvss":8.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.1,"epss":0.00038,"ranking_epss":0.11499,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/443196747"],"published_time":"2025-11-06T23:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11460","summary":"Use after free in Storage in Google Chrome prior to 141.0.7390.65 allowed a remote attacker to execute arbitrary code via a crafted video file. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00085,"ranking_epss":0.2477,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop.html","https://issues.chromium.org/issues/446722008"],"published_time":"2025-11-06T23:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11756","summary":"Use after free in Safe Browsing in Google Chrome prior to 141.0.7390.107 allowed a remote attacker who had compromised the renderer process to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00088,"ranking_epss":0.25253,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_14.html","https://issues.chromium.org/issues/447192722"],"published_time":"2025-11-06T23:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-12036","summary":"Out of bounds memory access in V8 in Google Chrome prior to 141.0.7390.122 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00065,"ranking_epss":0.20267,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_21.html","https://issues.chromium.org/issues/452296415"],"published_time":"2025-11-06T23:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11211","summary":"Out of bounds read in Media in Google Chrome prior to 141.0.7390.54 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Medium)","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00033,"ranking_epss":0.09616,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html","https://issues.chromium.org/issues/441917796"],"published_time":"2025-11-06T22:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11215","summary":"Off by one error in V8 in Google Chrome prior to 141.0.7390.54 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium)","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.00034,"ranking_epss":0.09856,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html","https://issues.chromium.org/issues/439758498"],"published_time":"2025-11-06T22:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11219","summary":"Use after free in V8 in Google Chrome prior to 141.0.7390.54 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Low)","cvss":3.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.1,"epss":0.0003,"ranking_epss":0.08613,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html","https://issues.chromium.org/issues/439772737"],"published_time":"2025-11-06T22:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11205","summary":"Heap buffer overflow in WebGPU in Google Chrome prior to 141.0.7390.54 allowed a remote attacker who had compromised the renderer process to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00083,"ranking_epss":0.24435,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html","https://issues.chromium.org/issues/442444724"],"published_time":"2025-11-06T22:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11206","summary":"Heap buffer overflow in Video in Google Chrome prior to 141.0.7390.54 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00083,"ranking_epss":0.24433,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html","https://issues.chromium.org/issues/444755026"],"published_time":"2025-11-06T22:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11207","summary":"Side-channel information leakage in Storage in Google Chrome prior to 141.0.7390.54 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00045,"ranking_epss":0.13919,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html","https://issues.chromium.org/issues/428189824"],"published_time":"2025-11-06T22:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11208","summary":"Inappropriate implementation in Media in Google Chrome prior to 141.0.7390.54 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":6.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.3,"epss":0.00041,"ranking_epss":0.1253,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html","https://issues.chromium.org/issues/397878997"],"published_time":"2025-11-06T22:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-11210","summary":"Side-channel information leakage in Tab in Google Chrome prior to 141.0.7390.54 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00019,"ranking_epss":0.04973,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html","https://issues.chromium.org/issues/440523110"],"published_time":"2025-11-06T22:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-40090","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix recursive locking in RPC handle list access\n\nSince commit 305853cce3794 (\"ksmbd: Fix race condition in RPC handle list\naccess\"), ksmbd_session_rpc_method() attempts to lock sess->rpc_lock.\n\nThis causes hung connections / tasks when a client attempts to open\na named pipe. Using Samba's rpcclient tool:\n\n $ rpcclient //192.168.1.254 -U user%password\n $ rpcclient $> srvinfo\n <connection hung here>\n\nKernel side:\n  \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/0:0 state:D stack:0 pid:5021 tgid:5021 ppid:2 flags:0x00200000\n  Workqueue: ksmbd-io handle_ksmbd_work\n  Call trace:\n  __schedule from schedule+0x3c/0x58\n  schedule from schedule_preempt_disabled+0xc/0x10\n  schedule_preempt_disabled from rwsem_down_read_slowpath+0x1b0/0x1d8\n  rwsem_down_read_slowpath from down_read+0x28/0x30\n  down_read from ksmbd_session_rpc_method+0x18/0x3c\n  ksmbd_session_rpc_method from ksmbd_rpc_open+0x34/0x68\n  ksmbd_rpc_open from ksmbd_session_rpc_open+0x194/0x228\n  ksmbd_session_rpc_open from create_smb2_pipe+0x8c/0x2c8\n  create_smb2_pipe from smb2_open+0x10c/0x27ac\n  smb2_open from handle_ksmbd_work+0x238/0x3dc\n  handle_ksmbd_work from process_scheduled_works+0x160/0x25c\n  process_scheduled_works from worker_thread+0x16c/0x1e8\n  worker_thread from kthread+0xa8/0xb8\n  kthread from ret_from_fork+0x14/0x38\n  Exception stack(0x8529ffb0 to 0x8529fff8)\n\nThe task deadlocks because the lock is already held:\n  ksmbd_session_rpc_open\n    down_write(&sess->rpc_lock)\n    ksmbd_rpc_open\n      ksmbd_session_rpc_method\n        down_read(&sess->rpc_lock)   <-- deadlock\n\nAdjust ksmbd_session_rpc_method() callers to take the lock when necessary.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00561,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1891abe832cbf5a11039e088766131d0f1642d02","https://git.kernel.org/stable/c/3412fbd81b46b9cfae013817b61d4bbd27e09e36","https://git.kernel.org/stable/c/4602b8cee1481dbb896182e5cb1e8cf12910e9e7","https://git.kernel.org/stable/c/5493571f4351f74e11db9943e98a07c56467cf7e","https://git.kernel.org/stable/c/88f170814fea74911ceab798a43cbd7c5599bed4"],"published_time":"2025-10-30T10:15:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36081","summary":"IBM Concert Software\n\n1.0.0 through 2.0.0 could allow a user to modify system logs due to improper neutralization of log input.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00027,"ranking_epss":0.07605,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7249356"],"published_time":"2025-10-28T15:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36083","summary":"IBM Concert Software \n\n1.0.0 through 2.0.0 could allow a local user to obtain sensitive information from buffers due to improper clearing of heap memory before release.","cvss":6.2,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.2,"epss":0.00011,"ranking_epss":0.013,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7249356"],"published_time":"2025-10-28T15:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36085","summary":"IBM Concert 1.0.0 through 2.0.0 Software is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.","cvss":5.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.4,"epss":0.00024,"ranking_epss":0.06332,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7249356"],"published_time":"2025-10-28T15:16:12","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-40082","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nBUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186\nRead of size 2 at addr ffff8880289ef218 by task syz.6.248/14290\n\nCPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x5f0 mm/kasan/report.c:482\n kasan_report+0xca/0x100 mm/kasan/report.c:595\n hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186\n hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738\n vfs_listxattr+0xbe/0x140 fs/xattr.c:493\n listxattr+0xee/0x190 fs/xattr.c:924\n filename_listxattr fs/xattr.c:958 [inline]\n path_listxattrat+0x143/0x360 fs/xattr.c:988\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe0e9fae16d\nCode: 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\nRSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3\nRAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000\nRBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000\n </TASK>\n\nAllocated by task 14290:\n kasan_save_stack+0x24/0x50 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4333 [inline]\n __kmalloc_noprof+0x219/0x540 mm/slub.c:4345\n kmalloc_noprof include/linux/slab.h:909 [inline]\n hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21\n hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697\n vfs_listxattr+0xbe/0x140 fs/xattr.c:493\n listxattr+0xee/0x190 fs/xattr.c:924\n filename_listxattr fs/xattr.c:958 [inline]\n path_listxattrat+0x143/0x360 fs/xattr.c:988\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWhen hfsplus_uni2asc is called from hfsplus_listxattr,\nit actually passes in a struct hfsplus_attr_unistr*.\nThe size of the corresponding structure is different from that of hfsplus_unistr,\nso the previous fix (94458781aee6) is insufficient.\nThe pointer on the unicode buffer is still going beyond the allocated memory.\n\nThis patch introduces two warpper functions hfsplus_uni2asc_xattr_str and\nhfsplus_uni2asc_str to process two unicode buffers,\nstruct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.\nWhen ustrlen value is bigger than the allocated memory size,\nthe ustrlen value is limited to an safe size.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":6e-05,"ranking_epss":0.00332,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/343fe375a8dd6ee51a193a1c233b999f5ea4d479","https://git.kernel.org/stable/c/5b5228964619b180f366940505b77255b1a03929","https://git.kernel.org/stable/c/782acde47e127c98a113726e2ff8024bd65c0454","https://git.kernel.org/stable/c/857aefc70d4ae3b9bf1ae67434d27d0f79f80c9e","https://git.kernel.org/stable/c/bea3e1d4467bcf292c8e54f080353d556d355e26","https://git.kernel.org/stable/c/c3db89ea1ed3d540eebe8f3c36e806fb75ee4a1e"],"published_time":"2025-10-28T12:15:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-40039","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix race condition in RPC handle list access\n\nThe 'sess->rpc_handle_list' XArray manages RPC handles within a ksmbd\nsession. Access to this list is intended to be protected by\n'sess->rpc_lock' (an rw_semaphore). However, the locking implementation was\nflawed, leading to potential race conditions.\n\nIn ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock\nbefore calling xa_store() and xa_erase(). Since these operations modify\nthe XArray structure, a write lock is required to ensure exclusive access\nand prevent data corruption from concurrent modifications.\n\nFurthermore, ksmbd_session_rpc_method() accessed the list using xa_load()\nwithout holding any lock at all. This could lead to reading inconsistent\ndata or a potential use-after-free if an entry is concurrently removed and\nthe pointer is dereferenced.\n\nFix these issues by:\n1. Using down_write() and up_write() in ksmbd_session_rpc_open()\n   to ensure exclusive access during XArray modification, and ensuring\n   the lock is correctly released on error paths.\n2. Adding down_read() and up_read() in ksmbd_session_rpc_method()\n   to safely protect the lookup.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00011,"ranking_epss":0.01402,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/305853cce379407090a73b38c5de5ba748893aee","https://git.kernel.org/stable/c/5cc679ba0f4505936124cd4179ba66bb0a4bd9f3","https://git.kernel.org/stable/c/69674b029002b1d90b655f014bdf64f404efa54d","https://git.kernel.org/stable/c/6b615a8fb3af0baf8126cde3d4fee97d57222ffc","https://git.kernel.org/stable/c/6bd7e0e55dcea2cf0d391bbc21c2eb069b4be3e1"],"published_time":"2025-10-28T12:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-40040","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[   44.607039] ------------[ cut here ]------------\n[   44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[   44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[   44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[   44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[   44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n<snip other registers, drop unreliable trace>\n\n[   44.617726] Call Trace:\n[   44.617926]  <TASK>\n[   44.619284]  userfaultfd_release+0xef/0x1b0\n[   44.620976]  __fput+0x3f9/0xb60\n[   44.621240]  fput_close_sync+0x110/0x210\n[   44.622222]  __x64_sys_close+0x8f/0x120\n[   44.622530]  do_syscall_64+0x5b/0x2f0\n[   44.622840]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all().  Specifically, a VMA which has a valid pointer\nto vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma->vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide.  This setup causes the following mishap during the &=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. \nAfter ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then\npromoted to unsigned long before the & operation.  This promotion fills\nupper 32 bits with leading 0s, as we're doing unsigned conversion (and\neven for a signed conversion, this wouldn't help as the leading bit is 0).\n& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff\ninstead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\"userfaultfd: remove (VM_)BUG_ON()s\"), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[   45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0001,"ranking_epss":0.0112,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/41cb9fd904fe0c39d52e82dd84dc3c96b7aa9693","https://git.kernel.org/stable/c/76385629f45740b7888f8fcd83bde955b10f61fe","https://git.kernel.org/stable/c/788e5385d0ff69cdba1cabccb9dab8d9647b9239","https://git.kernel.org/stable/c/850f1ea245bdc0ce6a3fd36bfb80d8cf9647cb71","https://git.kernel.org/stable/c/92b82e232b8d8b116ac6e57aeae7a6033db92c60","https://git.kernel.org/stable/c/ac50c6e0a8f91a02b681af81abb2362fbb67cc18","https://git.kernel.org/stable/c/b69f19244c2b6475c8a6eb72f0fb0d53509e48cd","https://git.kernel.org/stable/c/f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93"],"published_time":"2025-10-28T12:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33131","summary":"IBM DB2 High Performance Unload 6.1.0.3, 5.1.0.1, 6.1.0.2, 6.5, 6.5.0.0 IF1, 6.1.0.1, 6.1, and 5.1 could allow an authenticated user to cause the program to crash due to a buffer being overwritten when it is allocated on the stack.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00034,"ranking_epss":0.09934,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7249336"],"published_time":"2025-10-28T00:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33132","summary":"IBM DB2 High Performance Unload 6.1.0.3, 5.1.0.1, 6.1.0.2, 6.5, 6.5.0.0 IF1, 6.1.0.1, 6.1, and 5.1 could allow an authenticated user to cause the program to crash due to the incorrect calculation of the size of the data that is being pointed to.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00034,"ranking_epss":0.09934,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7249336"],"published_time":"2025-10-28T00:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33133","summary":"IBM DB2 High Performance Unload 6.1.0.3, 5.1.0.1, 6.1.0.2, 6.5, 6.5.0.0 IF1, 6.1.0.1, 6.1, and 5.1 could allow an authenticated user to cause the program to crash due an out of bounds write.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00034,"ranking_epss":0.09934,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7249336"],"published_time":"2025-10-28T00:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33126","summary":"IBM DB2 High Performance Unload 6.1.0.3, 5.1.0.1, 6.1.0.2, 6.5, 6.5.0.0 IF1, 6.1.0.1, 6.1, 5.1, 6.1.0.3, 5.1.0.1, 6.1.0.2, 6.5, 6.5.0.0 IF1, 6.1.0.1, 6.1, 5.1, 6.1.0.3, 5.1.0.1, 6.1.0.2, 6.5, 6.5.0.0 IF1, 6.1.0.1, 6.1, 5.1, 6.1.0.3, 5.1.0.1, 6.1.0.2, 6.5, 6.5.0.0 IF1, 6.1.0.1, 6.1, and 5.1 could allow an authenticated user to cause the program to crash due to the incorrect calculation of a buffer size.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00034,"ranking_epss":0.09934,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7249336"],"published_time":"2025-10-28T00:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-57870","summary":"A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This vulnerability allows a remote, unauthenticated attacker to execute arbitrary SQL commands via a specific ArcGIS Feature Service operation. Successful exploitation can potentially result in unauthorized access, modification, or deletion of data from the underlying Enterprise Geodatabase.","cvss":10.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":10.0,"epss":0.00169,"ranking_epss":0.38194,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/arcgis-server-feature-services-security-patch"],"published_time":"2025-10-22T15:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-40005","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nspi: cadence-quadspi: Implement refcount to handle unbind during busy\n\ndriver support indirect read and indirect write operation with\nassumption no force device removal(unbind) operation. However\nforce device removal(removal) is still available to root superuser.\n\nUnbinding driver during operation causes kernel crash. This changes\nensure driver able to handle such operation for indirect read and\nindirect write by implementing refcount to track attached devices\nto the controller and gracefully wait and until attached devices\nremove operation completed before proceed with removal operation.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00021,"ranking_epss":0.05592,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/56787f4a75907ae99b5f5842b756fa68e2482f6d","https://git.kernel.org/stable/c/65ed52200080eafce3eead05cf22ce01238defca","https://git.kernel.org/stable/c/7446284023e8ef694fb392348185349c773eefb3","https://git.kernel.org/stable/c/8df235f768cea7a5829cb02525622646eb0df5f5","https://git.kernel.org/stable/c/b7ec8a2b094a33d0464958c2cbf75b8f229098b0"],"published_time":"2025-10-20T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36128","summary":"IBM MQ 9.1, 9.2, 9.3, 9.4 LTS and 9.3, 9.4 CD is vulnerable to a denial of service, caused by improper enforcement of the timeout on individual read operations. By conducting slowloris-type attacks, a remote attacker could exploit this vulnerability to cause a denial of service.","cvss":7.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.5,"epss":0.00112,"ranking_epss":0.29759,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7244480"],"published_time":"2025-10-16T17:15:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36002","summary":"IBM Sterling B2B Integrator 6.2.0.0 through 6.2.0.5, and 6.2.1.0 and IBM Sterling File Gateway 6.2.0.0 through 6.2.0.5, and 6.2.1.0 stores user credentials in configuration files which can be read by a local user.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00011,"ranking_epss":0.01264,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7248129"],"published_time":"2025-10-16T15:15:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39966","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Fix race during abort for file descriptors\n\nfput() doesn't actually call file_operations release() synchronously, it\nputs the file on a work queue and it will be released eventually.\n\nThis is normally fine, except for iommufd the file and the iommufd_object\nare tied to gether. The file has the object as it's private_data and holds\na users refcount, while the object is expected to remain alive as long as\nthe file is.\n\nWhen the allocation of a new object aborts before installing the file it\nwill fput() the file and then go on to immediately kfree() the obj. This\ncauses a UAF once the workqueue completes the fput() and tries to\ndecrement the users refcount.\n\nFix this by putting the core code in charge of the file lifetime, and call\n__fput_sync() during abort to ensure that release() is called before\nkfree. __fput_sync() is a bit too tricky to open code in all the object\nimplementations. Instead the objects tell the core code where the file\npointer is and the core will take care of the life cycle.\n\nIf the object is successfully allocated then the file will hold a users\nrefcount and the iommufd_object cannot be destroyed.\n\nIt is worth noting that close(); ioctl(IOMMU_DESTROY); doesn't have an\nissue because close() is already using a synchronous version of fput().\n\nThe UAF looks like this:\n\n    BUG: KASAN: slab-use-after-free in iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376\n    Write of size 4 at addr ffff888059c97804 by task syz.0.46/6164\n\n    CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0 PREEMPT(full)\n    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025\n    Call Trace:\n     <TASK>\n     __dump_stack lib/dump_stack.c:94 [inline]\n     dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n     print_address_description mm/kasan/report.c:378 [inline]\n     print_report+0xcd/0x630 mm/kasan/report.c:482\n     kasan_report+0xe0/0x110 mm/kasan/report.c:595\n     check_region_inline mm/kasan/generic.c:183 [inline]\n     kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:189\n     instrument_atomic_read_write include/linux/instrumented.h:96 [inline]\n     atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:400 [inline]\n     __refcount_dec include/linux/refcount.h:455 [inline]\n     refcount_dec include/linux/refcount.h:476 [inline]\n     iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376\n     __fput+0x402/0xb70 fs/file_table.c:468\n     task_work_run+0x14d/0x240 kernel/task_work.c:227\n     resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n     exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n     exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n     syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n     syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n     do_syscall_64+0x41c/0x4c0 arch/x86/entry/syscall_64.c:100\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f","cvss":7.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.0,"epss":0.0001,"ranking_epss":0.01016,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/17195a7d754a5c6a31888702ca93f6f08f3383ad","https://git.kernel.org/stable/c/4e034bf045b12852a24d5d33f2451850818ba0c1","https://git.kernel.org/stable/c/e4825368285e33d6360c6c6a6a10d2d83da06e55"],"published_time":"2025-10-15T08:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39967","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: fix integer overflow in fbcon_do_set_font\n\nFix integer overflow vulnerabilities in fbcon_do_set_font() where font\nsize calculations could overflow when handling user-controlled font\nparameters.\n\nThe vulnerabilities occur when:\n1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount\n   multiplication with user-controlled values that can overflow.\n2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow\n3. This results in smaller allocations than expected, leading to buffer\n   overflows during font data copying.\n\nAdd explicit overflow checking using check_mul_overflow() and\ncheck_add_overflow() kernel helpers to safety validate all size\ncalculations before allocation.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04666,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1a194e6c8e1ee745e914b0b7f50fa86c89ed13fe","https://git.kernel.org/stable/c/4a4bac869560f943edbe3c2b032062f6673b13d3","https://git.kernel.org/stable/c/994bdc2d23c79087fbf7dcd9544454e8ebcef877","https://git.kernel.org/stable/c/9c8ec14075c5317edd6b242f1be8167aa1e4e333","https://git.kernel.org/stable/c/a6eb9f423b3db000aaedf83367b8539f6b72dcfc","https://git.kernel.org/stable/c/adac90bb1aaf45ca66f9db8ac100be16750ace78","https://git.kernel.org/stable/c/b8a6e85328aeb9881531dbe89bcd2637a06c3c95","https://git.kernel.org/stable/c/c0c01f9aa08c8e10e10e8c9ebb5be01a4eff6eb7"],"published_time":"2025-10-15T08:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-55247","summary":"Improper link resolution before file access ('link following') in .NET allows an authorized attacker to elevate privileges locally.","cvss":7.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.3,"epss":0.00015,"ranking_epss":0.02968,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55247"],"published_time":"2025-10-14T17:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-55248","summary":"Inadequate encryption strength in .NET, .NET Framework, Visual Studio allows an authorized attacker to disclose information over a network.","cvss":4.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.8,"epss":0.00026,"ranking_epss":0.07268,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55248"],"published_time":"2025-10-14T17:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-27906","summary":"IBM Content Navigator 3.0.11, 3.0.15, 3.1.0, and 3.2.0 could expose the directory listing of the application upon using an application URL. Application files and folders are visible in the browser to a user; however, the contents of the files cannot be read obtained or modified.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00031,"ranking_epss":0.08783,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7247854"],"published_time":"2025-10-14T15:16:08","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39964","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Disallow concurrent writes in af_alg_sendmsg\n\nIssuing two writes to the same af_alg socket is bogus as the\ndata will be interleaved in an unpredictable fashion.  Furthermore,\nconcurrent writes may create inconsistencies in the internal\nsocket state.\n\nDisallow this by adding a new ctx->write field that indiciates\nexclusive ownership for writing.","cvss":3.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.3,"epss":0.00026,"ranking_epss":0.07296,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0f28c4adbc4a97437874c9b669fd7958a8c6d6ce","https://git.kernel.org/stable/c/1b34cbbf4f011a121ef7b2d7d6e6920a036d5285","https://git.kernel.org/stable/c/1f323a48e9b5ebfe6dc7d130fdf5c3c0e92a07c8","https://git.kernel.org/stable/c/45bcf60fe49b37daab1acee57b27211ad1574042","https://git.kernel.org/stable/c/7c4491b5644e3a3708f3dbd7591be0a570135b84","https://git.kernel.org/stable/c/9aee87da5572b3a14075f501752e209801160d3d","https://git.kernel.org/stable/c/e4c1ec11132ec466f7362a95f36a506ce4dc08c9"],"published_time":"2025-10-13T14:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39965","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: xfrm_alloc_spi shouldn't use 0 as SPI\n\nx->id.spi == 0 means \"no SPI assigned\", but since commit\n94f39804d891 (\"xfrm: Duplicate SPI Handling\"), we now create states\nand add them to the byspi list with this value.\n\n__xfrm_state_delete doesn't remove those states from the byspi list,\nsince they shouldn't be there, and this shows up as a UAF the next\ntime we go through the byspi list.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00613,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0baf92d0b1590b903c1f4ead75e61715e50e8146","https://git.kernel.org/stable/c/9fcedabaae0096f712bbb4ccca6a8538af1cd1c8","https://git.kernel.org/stable/c/a78e55776522373c446f18d5002a8de4b09e6bf7","https://git.kernel.org/stable/c/cd8ae32e4e4652db55bce6b9c79267d8946765a9"],"published_time":"2025-10-13T14:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-2138","summary":"IBM Engineering Requirements Management Doors Next 7.0.2, 7.0.3, and 7.1 \n\ncould allow an authenticated user on the network to delete comments from other users due to client-side enforcement of server-side security.","cvss":3.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.5,"epss":0.00015,"ranking_epss":0.02968,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7247716"],"published_time":"2025-10-12T14:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-2139","summary":"IBM Engineering Requirements Management Doors Next 7.0.2, 7.0.3, and 7.1 could allow an authenticated user on the network to delete reviews from other users due to client-side enforcement of server-side security.","cvss":3.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.5,"epss":0.00042,"ranking_epss":0.1292,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7247716"],"published_time":"2025-10-12T14:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-2140","summary":"IBM Engineering Requirements Management Doors Next 7.0.2, 7.0.3, and 7.1 could allow an authenticated user on the network to spoof email identity of the sender due to improper verification of source data.","cvss":5.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.7,"epss":8e-05,"ranking_epss":0.00698,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7247716"],"published_time":"2025-10-12T14:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-33096","summary":"IBM Engineering Requirements Management Doors Next 7.0.2, 7.0.3, and 7.1 could allow an authenticated user to cause a denial of service by uploading specially crafted files using uncontrolled recursion.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00045,"ranking_epss":0.13963,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7247716"],"published_time":"2025-10-12T14:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36171","summary":"IBM Aspera Faspex 5.0.0 through 5.0.13.1 could allow a privileged user to cause a denial of service from improperly validated API input due to excessive resource consumption.","cvss":4.9,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.9,"epss":0.00065,"ranking_epss":0.20359,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7247502"],"published_time":"2025-10-09T14:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-36225","summary":"IBM Aspera 5.0.0 through 5.0.13.1 \n\ncould disclose sensitive user information from the system to an authenticated user due to an observable discrepancy of returned data.","cvss":4.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.3,"epss":0.0003,"ranking_epss":0.08693,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7247502"],"published_time":"2025-10-09T14:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-37401","summary":"IBM Aspera Faspex 5.0.0 through 5.0.13.1 uses a cross-domain policy file that includes domains that should not be trusted.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00031,"ranking_epss":0.08967,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://www.ibm.com/support/pages/node/7247502"],"published_time":"2025-10-09T14:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39960","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: acpi: initialize acpi_gpio_info struct\n\nSince commit 7c010d463372 (\"gpiolib: acpi: Make sure we fill struct\nacpi_gpio_info\"), uninitialized acpi_gpio_info struct are passed to\n__acpi_find_gpio() and later in the call stack info->quirks is used in\nacpi_populate_gpio_lookup. This breaks the i2c_hid_cpi driver:\n\n[   58.122916] i2c_hid_acpi i2c-UNIW0001:00: HID over i2c has not been provided an Int IRQ\n[   58.123097] i2c_hid_acpi i2c-UNIW0001:00: probe with driver i2c_hid_acpi failed with error -22\n\nFix this by initializing the acpi_gpio_info pass to __acpi_find_gpio()","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/19c839a98c731169f06d32e7c9e00c78a0086ebe","https://git.kernel.org/stable/c/27d94a2a52cbb54927c0140bd5b978c56e9a283a"],"published_time":"2025-10-09T13:15:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39961","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/pgtbl: Fix possible race while increase page table level\n\nThe AMD IOMMU host page table implementation supports dynamic page table levels\n(up to 6 levels), starting with a 3-level configuration that expands based on\nIOVA address. The kernel maintains a root pointer and current page table level\nto enable proper page table walks in alloc_pte()/fetch_pte() operations.\n\nThe IOMMU IOVA allocator initially starts with 32-bit address and onces its\nexhuasted it switches to 64-bit address (max address is determined based\non IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU\ndriver increases page table level.\n\nBut in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads\npgtable->[root/mode] without lock. So its possible that in exteme corner case,\nwhen increase_address_space() is updating pgtable->[root/mode], fetch_pte()\nreads wrong page table level (pgtable->mode). It does compare the value with\nlevel encoded in page table and returns NULL. This will result is\niommu_unmap ops to fail and upper layer may retry/log WARN_ON.\n\nCPU 0                                         CPU 1\n------                                       ------\nmap pages                                    unmap pages\nalloc_pte() -> increase_address_space()      iommu_v1_unmap_pages() -> fetch_pte()\n  pgtable->root = pte (new root value)\n                                             READ pgtable->[mode/root]\n\t\t\t\t\t       Reads new root, old mode\n  Updates mode (pgtable->mode += 1)\n\nSince Page table level updates are infrequent and already synchronized with a\nspinlock, implement seqcount to enable lock-free read operations on the read path.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00012,"ranking_epss":0.01597,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/075abf0b1a958acfbea2435003d228e738e90346","https://git.kernel.org/stable/c/1e56310b40fd2e7e0b9493da9ff488af145bdd0c","https://git.kernel.org/stable/c/7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2","https://git.kernel.org/stable/c/cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b"],"published_time":"2025-10-09T13:15:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39962","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix untrusted unsigned subtract\n\nFix the following Smatch static checker warning:\n\n   net/rxrpc/rxgk_app.c:65 rxgk_yfs_decode_ticket()\n   warn: untrusted unsigned subtract. 'ticket_len - 10 * 4'\n\nby prechecking the length of what we're trying to extract in two places in\nthe token and decoding for a response packet.\n\nAlso use sizeof() on the struct we're extracting rather specifying the size\nnumerically to be consistent with the other related statements.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2429a197648178cd4dc930a9d87c13c547460564","https://git.kernel.org/stable/c/71571e187106631a8127f2dde780f35caa358d33"],"published_time":"2025-10-09T13:15:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39963","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix incorrect io_kiocb reference in io_link_skb\n\nIn io_link_skb function, there is a bug where prev_notif is incorrectly\nassigned using 'nd' instead of 'prev_nd'. This causes the context\nvalidation check to compare the current notification with itself instead\nof comparing it with the previous notification.\n\nFix by using the correct prev_nd parameter when obtaining prev_notif.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00012,"ranking_epss":0.01866,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2c139a47eff8de24e3350dadb4c9d5e3426db826","https://git.kernel.org/stable/c/50a98ce1ea694f1ff8e87bc2f8f84096d1736f6a","https://git.kernel.org/stable/c/a89c34babc2e5834aa0905278f26f4dbe4b26b76"],"published_time":"2025-10-09T13:15:32","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39959","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: amd: acp: Fix incorrect retrival of acp_chip_info\n\nUse dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev)\nto correctly obtain acp_chip_info members in the acp I2S driver.\nPreviously, some members were not updated properly due to incorrect\ndata access, which could potentially lead to null pointer\ndereferences.\n\nThis issue was missed in the earlier commit\n(\"ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot\"),\nwhich only addressed set_tdm_slot(). This change ensures that all\nrelevant functions correctly retrieve acp_chip_info, preventing\nfurther null pointer dereference issues.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/65c5cfbd6d938f77a0df3c34855a4f7d8a61fd10","https://git.kernel.org/stable/c/d7871f400cad1da376f1d7724209a1c49226c456"],"published_time":"2025-10-09T10:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39957","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: increase scan_ies_len for S1G\n\nCurrently the S1G capability element is not taken into account\nfor the scan_ies_len, which leads to a buffer length validation\nfailure in ieee80211_prep_hw_scan() and subsequent WARN in\n__ieee80211_start_scan(). This prevents hw scanning from functioning.\nTo fix ensure we accommodate for the S1G capability length.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00016,"ranking_epss":0.03375,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0dbad5f5549e54ac269cc04ce89f212892a98cab","https://git.kernel.org/stable/c/32adb020b0c32939da1322dcc87fc0ae2bc935d1","https://git.kernel.org/stable/c/7e2f3213e85eba00acb4cfe6d71647892d63c3a1","https://git.kernel.org/stable/c/93e063f15e17acb8cd6ac90c8f0802c2624e1a74"],"published_time":"2025-10-09T10:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39958","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/s390: Make attach succeed when the device was surprise removed\n\nWhen a PCI device is removed with surprise hotplug, there may still be\nattempts to attach the device to the default domain as part of tear down\nvia (__iommu_release_dma_ownership()), or because the removal happens\nduring probe (__iommu_probe_device()). In both cases zpci_register_ioat()\nfails with a cc value indicating that the device handle is invalid. This\nis because the device is no longer part of the instance as far as the\nhypervisor is concerned.\n\nCurrently this leads to an error return and s390_iommu_attach_device()\nfails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()\nbecause attaching to the default domain must never fail.\n\nWith the device fenced by the hypervisor no DMAs to or from memory are\npossible and the IOMMU translations have no effect. Proceed as if the\nregistration was successful and let the hotplug event handling clean up\nthe device.\n\nThis is similar to how devices in the error state are handled since\ncommit 59bbf596791b (\"iommu/s390: Make attach succeed even if the device\nis in error state\") except that for removal the domain will not be\nregistered later. This approach was also previously discussed at the\nlink.\n\nHandle both cases, error state and removal, in a helper which checks if\nthe error needs to be propagated or ignored. Avoid magic number\ncondition codes by using the pre-existing, but never used, defines for\nPCI load/store condition codes and rename them to reflect that they\napply to all PCI instructions.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/359613f2fa009587154511e4842e8ab9532edd15","https://git.kernel.org/stable/c/9ffaf5229055fcfbb3b3d6f1c7e58d63715c3f73"],"published_time":"2025-10-09T10:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39955","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().\n\nsyzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk\nin the TCP_ESTABLISHED state. [0]\n\nsyzbot reused the server-side TCP Fast Open socket as a new client before\nthe TFO socket completes 3WHS:\n\n  1. accept()\n  2. connect(AF_UNSPEC)\n  3. connect() to another destination\n\nAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes\nit to TCP_CLOSE and makes connect() possible, which restarts timers.\n\nSince tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the\nretransmit timer triggered the warning and the intended packet was not\nretransmitted.\n\nLet's call reqsk_fastopen_remove() in tcp_disconnect().\n\n[0]:\nWARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))\nModules linked in:\nCPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))\nCode: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e\nRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293\nRAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017\nRDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400\nRBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8\nR10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540\nR13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0\nFS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0\nCall Trace:\n <IRQ>\n tcp_write_timer (net/ipv4/tcp_timer.c:738)\n call_timer_fn (kernel/time/timer.c:1747)\n __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)\n timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)\n tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)\n __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))\n tmigr_handle_remote (kernel/time/timer_migration.c:1096)\n handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)\n irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))\n </IRQ>","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04666,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/17d699727577814198d744d6afe54735c6b54c99","https://git.kernel.org/stable/c/33a4fdf0b4a25f8ce65380c3b0136b407ca57609","https://git.kernel.org/stable/c/45c8a6cc2bcd780e634a6ba8e46bffbdf1fc5c01","https://git.kernel.org/stable/c/7ec092a91ff351dcde89c23e795b73a328274db6","https://git.kernel.org/stable/c/a4378dedd6e07e62f2fccb17d78c9665718763d0","https://git.kernel.org/stable/c/ae313d14b45eca7a6bb29cb9bf396d977e7d28fb","https://git.kernel.org/stable/c/dfd06131107e7b699ef1e2a24ed2f7d17c917753","https://git.kernel.org/stable/c/fa4749c065644af4db496b338452a69a3e5147d9"],"published_time":"2025-10-09T10:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39956","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nigc: don't fail igc_probe() on LED setup error\n\nWhen igc_led_setup() fails, igc_probe() fails and triggers kernel panic\nin free_netdev() since unregister_netdev() is not called. [1]\nThis behavior can be tested using fault-injection framework, especially\nthe failslab feature. [2]\n\nSince LED support is not mandatory, treat LED setup failures as\nnon-fatal and continue probe with a warning message, consequently\navoiding the kernel panic.\n\n[1]\n kernel BUG at net/core/dev.c:12047!\n Oops: invalid opcode: 0000 [#1] SMP NOPTI\n CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:free_netdev+0x278/0x2b0\n [...]\n Call Trace:\n  <TASK>\n  igc_probe+0x370/0x910\n  local_pci_probe+0x3a/0x80\n  pci_device_probe+0xd1/0x200\n [...]\n\n[2]\n #!/bin/bash -ex\n\n FAILSLAB_PATH=/sys/kernel/debug/failslab/\n DEVICE=0000:00:05.0\n START_ADDR=$(grep \" igc_led_setup\" /proc/kallsyms \\\n         | awk '{printf(\"0x%s\", $1)}')\n END_ADDR=$(printf \"0x%x\" $((START_ADDR + 0x100)))\n\n echo $START_ADDR > $FAILSLAB_PATH/require-start\n echo $END_ADDR > $FAILSLAB_PATH/require-end\n echo 1 > $FAILSLAB_PATH/times\n echo 100 > $FAILSLAB_PATH/probability\n echo N > $FAILSLAB_PATH/ignore-gfp-wait\n\n echo $DEVICE > /sys/bus/pci/drivers/igc/bind","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/528eb4e19ec0df30d0c9ae4074ce945667dde919","https://git.kernel.org/stable/c/bec504867acc7315de9cd96ef9161fa52a25abe8","https://git.kernel.org/stable/c/f05e82d8553232cef150a6dbb70ed67d162abb2b"],"published_time":"2025-10-09T10:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39954","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nclk: sunxi-ng: mp: Fix dual-divider clock rate readback\n\nWhen dual-divider clock support was introduced, the P divider offset was\nleft out of the .recalc_rate readback function. This causes the clock\nrate to become bogus or even zero (possibly due to the P divider being\n1, leading to a divide-by-zero).\n\nFix this by incorporating the P divider offset into the calculation.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/25fbbaf515acd13399589bd5ee6de5f35740cef2","https://git.kernel.org/stable/c/40108f69c372af3aea73e7829d6849a44638d662"],"published_time":"2025-10-09T10:15:31","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53687","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk\n\nWhen the best clk is searched, we iterate over all possible clk.\n\nIf we find a better match, the previous one, if any, needs to be freed.\nIf a better match has already been found, we still need to free the new\none, otherwise it leaks.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/01dd8a43a84616c830782166ba3cceb01ad95363","https://git.kernel.org/stable/c/1962717c4649e026a4252fe6625175affd28a593","https://git.kernel.org/stable/c/1f426293fef1c13742b2a685bf7e363f51f6ee03","https://git.kernel.org/stable/c/46574e5a0a2aee41e6ebb979cfe1dbaea8693e16","https://git.kernel.org/stable/c/832e231cff476102e8204a9e7bddfe5c6154a375","https://git.kernel.org/stable/c/933e5b2998bc3a527d15efbf1e97c9e63297aa3c","https://git.kernel.org/stable/c/9dd8091959bc41fee51d0827276a2b982e84adf0","https://git.kernel.org/stable/c/f0bf102ef9b05d7294bd8d506755465f6867d944"],"published_time":"2025-10-07T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53679","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt7601u: fix an integer underflow\n\nFix an integer underflow that leads to a null pointer dereference in\n'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet\ncould be manipulated, which could trigger an integer underflow of\n'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently\ncauses the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be\nbypassed, eventually leading to a dereference of the pointer 'p', which\nis a null pointer.\n\nEnsure that 'dma_len' is greater than 'min_seg_len'.\n\nFound by a modified version of syzkaller.\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G        W  O      5.14.0+\n#139\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nRIP: 0010:skb_add_rx_frag+0x143/0x370\nCode: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44\n89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02\n00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00\nRSP: 0018:ffffc900000cfc90 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8\nRBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010\nR10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000\nR13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008\nFS:  0000000000000000(0000) GS:ffff88811a800000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n mt7601u_rx_tasklet+0xc73/0x1270\n ? mt7601u_submit_rx_buf.isra.0+0x510/0x510\n ? tasklet_action_common.isra.0+0x79/0x2f0\n tasklet_action_common.isra.0+0x206/0x2f0\n __do_softirq+0x1b5/0x880\n ? tasklet_unlock+0x30/0x30\n run_ksoftirqd+0x26/0x50\n smpboot_thread_fn+0x34f/0x7d0\n ? smpboot_register_percpu_thread+0x370/0x370\n kthread+0x3a1/0x480\n ? set_kthread_struct+0x120/0x120\n ret_from_fork+0x1f/0x30\nModules linked in: 88XXau(O) 88x2bu(O)\n---[ end trace 57f34f93b4da0f9b ]---\nRIP: 0010:skb_add_rx_frag+0x143/0x370\nCode: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44\n89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02\n00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00\nRSP: 0018:ffffc900000cfc90 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8\nRBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010\nR10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000\nR13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008\nFS:  0000000000000000(0000) GS:ffff88811a800000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1a1f43059afae5cc9409e0c3bc63bfc09bc8facb","https://git.kernel.org/stable/c/47dc1f425af57b71111d7b01ebd24e04e8d967ef","https://git.kernel.org/stable/c/61d0163e2be7a439cf6f82e9ad7de563ecf41e7a","https://git.kernel.org/stable/c/67e4519afba215199b6dfa39ce5d7ea673ee4138","https://git.kernel.org/stable/c/803f3176c5df3b5582c27ea690f204abb60b19b9","https://git.kernel.org/stable/c/d0db59e2f718d1e2f1d2a2d8092168fdd2f3add0"],"published_time":"2025-10-07T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53680","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL\n\nOPDESC() simply indexes into nfsd4_ops[] by the op's operation\nnumber, without range checking that value. It assumes callers are\ncareful to avoid calling it with an out-of-bounds opnum value.\n\nnfsd4_decode_compound() is not so careful, and can invoke OPDESC()\nwith opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end\nof nfsd4_ops[].","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03059,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/50827896c365e0f6c8b55ed56d444dafd87c92c5","https://git.kernel.org/stable/c/804d8e0a6e54427268790472781e03bc243f4ee3","https://git.kernel.org/stable/c/a64160124d5a078be0c380b1e8a0bad2d040d3a1","https://git.kernel.org/stable/c/f352c41fa718482979e7e6b71b4da2b718e381cc","https://git.kernel.org/stable/c/ffcbcf087581ae68ddc0a21460f7ecd4315bdd0e"],"published_time":"2025-10-07T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53681","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: Fix __bch_btree_node_alloc to make the failure behavior consistent\n\nIn some specific situations, the return value of __bch_btree_node_alloc\nmay be NULL. This may lead to a potential NULL pointer dereference in\ncaller function like a calling chain :\nbtree_split->bch_btree_node_alloc->__bch_btree_node_alloc.\n\nFix it by initializing the return value in __bch_btree_node_alloc.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4514847aee18d9391a0cf3aad75d3567c72795a4","https://git.kernel.org/stable/c/587b4e8bb5dac682f09280ab35db4632b29d5ac4","https://git.kernel.org/stable/c/7ecea5ce3dc17339c280c75b58ac93d8c8620d9f","https://git.kernel.org/stable/c/80fca8a10b604afad6c14213fdfd816c4eda3ee4","https://git.kernel.org/stable/c/a4405f6ee03323410d7b10966fd67b35f71b1944","https://git.kernel.org/stable/c/b070f29a61436f6f8a2e3abc7ea4f4be81695198","https://git.kernel.org/stable/c/f67b0e3081f2a24170280a33ac66f6b112083c03"],"published_time":"2025-10-07T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53682","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (xgene) Fix ioremap and memremap leak\n\nSmatch reports:\n\ndrivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn:\n'ctx->pcc_comm_addr' from ioremap() not released on line: 757.\n\nThis is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(),\nioremap and memremap is not released, which may cause a leak.\n\nTo fix this, ioremap and memremap is modified to devm_ioremap and\ndevm_memremap.\n\n[groeck: Fixed formatting and subject]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1773185a0a87006c1be78a978d9dd61aa7a33db8","https://git.kernel.org/stable/c/813cc94c7847ae4a17e9f744fb4dbdf7df6bd732","https://git.kernel.org/stable/c/9d482a09acd3d5f61a56aefc125d32c81994707b"],"published_time":"2025-10-07T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53683","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()\n\nsyzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), for\ncrafted filesystem image can contain bogus length. There conditions are\nnot kernel bugs that can justify kernel to panic.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.02011,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/37cab61a52d6f42b2d961c51bcf369f09e235fb5","https://git.kernel.org/stable/c/3a9d68d84b2e41ba3f2a727b36f035fad6800492","https://git.kernel.org/stable/c/48960a503fcec76d3f72347b7e679dda08ca43be","https://git.kernel.org/stable/c/61af77acd039ffd221bf7adf0dc95d0a4d377505","https://git.kernel.org/stable/c/81b21c0f0138ff5a499eafc3eb0578ad2a99622c","https://git.kernel.org/stable/c/a75d9211a07fed513c08c5d4861c4a36ac6a74fe","https://git.kernel.org/stable/c/c074913b12db3632b11588b31bbfb0fa80a0a1c9","https://git.kernel.org/stable/c/c8daee66585897a4c90d937c91e762100237bff9"],"published_time":"2025-10-07T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53684","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Zero padding when dumping algos and encap\n\nWhen copying data to user-space we should ensure that only valid\ndata is copied over.  Padding in structures may be filled with\nrandom (possibly sensitve) data and should never be given directly\nto user-space.\n\nThis patch fixes the copying of xfrm algorithms and the encap\ntemplate in xfrm_user so that padding is zeroed.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0725daaa9a879388ed312110f62dbd5ea2d75f8f","https://git.kernel.org/stable/c/1a351e26cc010d6991fbbd5701ac16581372e26f","https://git.kernel.org/stable/c/5218af4ad5d8948faac19f71583bcd786c3852df","https://git.kernel.org/stable/c/8222d5910dae08213b6d9d4bc9a7f8502855e624"],"published_time":"2025-10-07T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53685","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntun: Fix memory leak for detached NAPI queue.\n\nsyzkaller reported [0] memory leaks of sk and skb related to the TUN\ndevice with no repro, but we can reproduce it easily with:\n\n  struct ifreq ifr = {}\n  int fd_tun, fd_tmp;\n  char buf[4] = {};\n\n  fd_tun = openat(AT_FDCWD, \"/dev/net/tun\", O_WRONLY, 0);\n  ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE;\n  ioctl(fd_tun, TUNSETIFF, &ifr);\n\n  ifr.ifr_flags = IFF_DETACH_QUEUE;\n  ioctl(fd_tun, TUNSETQUEUE, &ifr);\n\n  fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0);\n  ifr.ifr_flags = IFF_UP;\n  ioctl(fd_tmp, SIOCSIFFLAGS, &ifr);\n\n  write(fd_tun, buf, sizeof(buf));\n  close(fd_tun);\n\nIf we enable NAPI and multi-queue on a TUN device, we can put skb into\ntfile->sk.sk_write_queue after the queue is detached.  We should prevent\nit by checking tfile->detached before queuing skb.\n\nNote this must be done under tfile->sk.sk_write_queue.lock because write()\nand ioctl(IFF_DETACH_QUEUE) can run concurrently.  Otherwise, there would\nbe a small race window:\n\n  write()                             ioctl(IFF_DETACH_QUEUE)\n  `- tun_get_user                     `- __tun_detach\n     |- if (tfile->detached)             |- tun_disable_queue\n     |  `-> false                        |  `- tfile->detached = tun\n     |                                   `- tun_queue_purge\n     |- spin_lock_bh(&queue->lock)\n     `- __skb_queue_tail(queue, skb)\n\nAnother solution is to call tun_queue_purge() when closing and\nreattaching the detached queue, but it could paper over another\nproblems.  Also, we do the same kind of test for IFF_NAPI_FRAGS.\n\n[0]:\nunreferenced object 0xffff88801edbc800 (size 2048):\n  comm \"syz-executor.1\", pid 33269, jiffies 4295743834 (age 18.756s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............\n  backtrace:\n    [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline]\n    [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979\n    [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline]\n    [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035\n    [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088\n    [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438\n    [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165\n    [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414\n    [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920\n    [<000000008eb24774>] do_open fs/namei.c:3636 [inline]\n    [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791\n    [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818\n    [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356\n    [<00000000057be699>] do_sys_open fs/open.c:1372 [inline]\n    [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline]\n    [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline]\n    [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383\n    [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n    [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80\n    [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nunreferenced object 0xffff88802f671700 (size 240):\n  comm \"syz-executor.1\", pid 33269, jiffies 4295743854 (age 18.736s)\n  hex dump (first 32 bytes):\n    68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff  h.......h.......\n    00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff  ..{/............\n  backtrace:\n    [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644\n    [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline]\n    [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378\n    [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729\n    [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline]\n    [<\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d20210a190f76db9ec35ee4e0fc77e6c7a148f5","https://git.kernel.org/stable/c/82b2bc279467c875ec36f8ef820f00997c2a4e8e","https://git.kernel.org/stable/c/9cae243b9ae25adfe468cd47ceca591f6725b79c"],"published_time":"2025-10-07T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53686","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/handshake: fix null-ptr-deref in handshake_nl_done_doit()\n\nWe should not call trace_handshake_cmd_done_err() if socket lookup has failed.\n\nAlso we should call trace_handshake_cmd_done_err() before releasing the file,\notherwise dereferencing sock->sk can return garbage.\n\nThis also reverts 7afc6d0a107f (\"net/handshake: Fix uninitialized local variable\")\n\nUnable to handle kernel paging request at virtual address dfff800000000003\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\nMem abort info:\nESR = 0x0000000096000005\nEC = 0x25: DABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nFSC = 0x05: level 1 translation fault\nData abort info:\nISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\nCM = 0, WnR = 0, TnD = 0, TagAccess = 0\nGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[dfff800000000003] address between user and kernel address ranges\nInternal error: Oops: 0000000096000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193\nlr : handshake_nl_done_doit+0x180/0x9c8\nsp : ffff800096e37180\nx29: ffff800096e37200 x28: 1ffff00012dc6e34 x27: dfff800000000000\nx26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8\nx23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000\nx20: ffff800096e371c0 x19: 0000000000000018 x18: 0000000000000000\nx17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001\nx14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000003\nx8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078\nx2 : 0000000000000001 x1 : 00000000ffffffa8 x0 : 0000000000000000\nCall trace:\nhandshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193\ngenl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline]\ngenl_family_rcv_msg net/netlink/genetlink.c:1050 [inline]\ngenl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067\nnetlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549\ngenl_rcv+0x38/0x50 net/netlink/genetlink.c:1078\nnetlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]\nnetlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365\nnetlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914\nsock_sendmsg_nosec net/socket.c:725 [inline]\nsock_sendmsg net/socket.c:748 [inline]\n____sys_sendmsg+0x56c/0x840 net/socket.c:2494\n___sys_sendmsg net/socket.c:2548 [inline]\n__sys_sendmsg+0x26c/0x33c net/socket.c:2577\n__do_sys_sendmsg net/socket.c:2586 [inline]\n__se_sys_sendmsg net/socket.c:2584 [inline]\n__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584\n__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\ninvoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\nel0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\ndo_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\nel0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678\nel0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\nel0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591\nCode: 12800108 b90043e8 910062b3 d343fe68 (387b6908)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/82ba0ff7bf0483d962e592017bef659ae022d754","https://git.kernel.org/stable/c/93d69f18edcca282351394c5870bec24cc99d745"],"published_time":"2025-10-07T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53671","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsrcu: Delegate work to the boot cpu if using SRCU_SIZE_SMALL\n\nCommit 994f706872e6 (\"srcu: Make Tree SRCU able to operate without\nsnp_node array\") assumes that cpu 0 is always online.  However, there\nreally are situations when some other CPU is the boot CPU, for example,\nwhen booting a kdump kernel with the maxcpus=1 boot parameter.\n\nOn PowerPC, the kdump kernel can hang as follows:\n...\n[    1.740036] systemd[1]: Hostname set to <xyz.com>\n[  243.686240] INFO: task systemd:1 blocked for more than 122 seconds.\n[  243.686264]       Not tainted 6.1.0-rc1 #1\n[  243.686272] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[  243.686281] task:systemd         state:D stack:0     pid:1     ppid:0      flags:0x00042000\n[  243.686296] Call Trace:\n[  243.686301] [c000000016657640] [c000000016657670] 0xc000000016657670 (unreliable)\n[  243.686317] [c000000016657830] [c00000001001dec0] __switch_to+0x130/0x220\n[  243.686333] [c000000016657890] [c000000010f607b8] __schedule+0x1f8/0x580\n[  243.686347] [c000000016657940] [c000000010f60bb4] schedule+0x74/0x140\n[  243.686361] [c0000000166579b0] [c000000010f699b8] schedule_timeout+0x168/0x1c0\n[  243.686374] [c000000016657a80] [c000000010f61de8] __wait_for_common+0x148/0x360\n[  243.686387] [c000000016657b20] [c000000010176bb0] __flush_work.isra.0+0x1c0/0x3d0\n[  243.686401] [c000000016657bb0] [c0000000105f2768] fsnotify_wait_marks_destroyed+0x28/0x40\n[  243.686415] [c000000016657bd0] [c0000000105f21b8] fsnotify_destroy_group+0x68/0x160\n[  243.686428] [c000000016657c40] [c0000000105f6500] inotify_release+0x30/0xa0\n[  243.686440] [c000000016657cb0] [c0000000105751a8] __fput+0xc8/0x350\n[  243.686452] [c000000016657d00] [c00000001017d524] task_work_run+0xe4/0x170\n[  243.686464] [c000000016657d50] [c000000010020e94] do_notify_resume+0x134/0x140\n[  243.686478] [c000000016657d80] [c00000001002eb18] interrupt_exit_user_prepare_main+0x198/0x270\n[  243.686493] [c000000016657de0] [c00000001002ec60] syscall_exit_prepare+0x70/0x180\n[  243.686505] [c000000016657e10] [c00000001000bf7c] system_call_vectored_common+0xfc/0x280\n[  243.686520] --- interrupt: 3000 at 0x7fffa47d5ba4\n[  243.686528] NIP:  00007fffa47d5ba4 LR: 0000000000000000 CTR: 0000000000000000\n[  243.686538] REGS: c000000016657e80 TRAP: 3000   Not tainted  (6.1.0-rc1)\n[  243.686548] MSR:  800000000000d033 <SF,EE,PR,ME,IR,DR,RI,LE>  CR: 42044440  XER: 00000000\n[  243.686572] IRQMASK: 0\n[  243.686572] GPR00: 0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000\n[  243.686572] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000001\n[  243.686572] GPR08: 000001000c172dd0 0000000000000000 0000000000000000 0000000000000000\n[  243.686572] GPR12: 0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000\n[  243.686572] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000\n[  243.686572] GPR20: 0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000\n[  243.686572] GPR24: 00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570\n[  243.686572] GPR28: 000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98\n[  243.686683] NIP [00007fffa47d5ba4] 0x7fffa47d5ba4\n[  243.686691] LR [0000000000000000] 0x0\n[  243.686698] --- interrupt: 3000\n[  243.686708] INFO: task kworker/u16:1:24 blocked for more than 122 seconds.\n[  243.686717]       Not tainted 6.1.0-rc1 #1\n[  243.686724] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[  243.686733] task:kworker/u16:1   state:D stack:0     pid:24    ppid:2      flags:0x00000800\n[  243.686747] Workqueue: events_unbound fsnotify_mark_destroy_workfn\n[  243.686758] Call Trace:\n[  243.686762] [c0000000166736e0] [c00000004fd91000] 0xc00000004fd91000 (unreliable)\n[  243.686775] [c0000000166738d0] [c00000001001dec0] __switch_to+0x130/0x220\n[  243.686788] [c000000016673930] [c000000010f607b8] __schedule+0x1f8/0x\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2c4d26dad76eadaa45a24543e311e9ce5d09f04e","https://git.kernel.org/stable/c/7f24626d6dd844bfc6d1f492d214d29c86d02550","https://git.kernel.org/stable/c/c7c0bc03fa44942fe0fdc5ac52cda6e11529c0ea"],"published_time":"2025-10-07T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53672","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: output extra debug info if we failed to find an inline backref\n\n[BUG]\nSyzbot reported several warning triggered inside\nlookup_inline_extent_backref().\n\n[CAUSE]\nAs usual, the reproducer doesn't reliably trigger locally here, but at\nleast we know the WARN_ON() is triggered when an inline backref can not\nbe found, and it can only be triggered when @insert is true. (I.e.\ninserting a new inline backref, which means the backref should already\nexist)\n\n[ENHANCEMENT]\nAfter the WARN_ON(), dump all the parameters and the extent tree\nleaf to help debug.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/28062cd6eda04035d8f6ded2001292ac8b496149","https://git.kernel.org/stable/c/376b41524b71e494514720bd6114325b0a2ed19c","https://git.kernel.org/stable/c/400e08a16604b534fdd82c5a288fa150d04f5f79","https://git.kernel.org/stable/c/6994f806c6d1ae8b59344d3700358547f3b3fe1d","https://git.kernel.org/stable/c/7afbfde45d665953b4d5a42a721e15bf0315d89b","https://git.kernel.org/stable/c/7f72f50547b7af4ddf985b07fc56600a4deba281","https://git.kernel.org/stable/c/b7c3cf2f6c42e6688b1c37215a0b1663f982f915","https://git.kernel.org/stable/c/e70ba449b04b40584bdabb383d10455397cbf177"],"published_time":"2025-10-07T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53673","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: call disconnect callback before deleting conn\n\nIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.\n\nISO, L2CAP and SCO connections refer to the hci_conn without\nhci_conn_get, so disconn_cfm must be called so they can clean up their\nconn, otherwise use-after-free occurs.\n\nISO:\n==========================================================\niso_sock_connect:880: sk 00000000eabd6557\niso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da\n...\niso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073\nhci_dev_put:1487: hci0 orig refcnt 17\n__iso_chan_add:214: conn 00000000b6251073\niso_sock_clear_timer:117: sock 00000000eabd6557 state 3\n...\nhci_rx_work:4085: hci0 Event packet\nhci_event_packet:7601: hci0: event 0x0f\nhci_cmd_status_evt:4346: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3107: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560\nhci_conn_unlink:1102: hci0: hcon 000000001696f1fd\nhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2\nhci_chan_list_flush:2780: hcon 000000001696f1fd\nhci_dev_put:1487: hci0 orig refcnt 21\nhci_dev_put:1487: hci0 orig refcnt 20\nhci_req_cmd_complete:3978: opcode 0x0406 status 0x0c\n... <no iso_* activity on sk/conn> ...\niso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557\nBUG: kernel NULL pointer dereference, address: 0000000000000668\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nRIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth\n==========================================================\n\nL2CAP:\n==================================================================\nhci_cmd_status_evt:4359: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3085: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585\nhci_conn_unlink:1102: hci0: hcon ffff88800c999000\nhci_chan_list_flush:2780: hcon ffff88800c999000\nhci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280\n...\nBUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]\nRead of size 8 at addr ffff888018ddd298 by task bluetoothd/1175\n\nCPU: 0 PID: 1175 Comm: bluetoothd Tainted: G            E      6.4.0-rc4+ #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0xf8/0x180\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n kasan_report+0xa8/0xe0\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n hci_send_acl+0x2d/0x540 [bluetooth]\n ? __pfx___lock_acquire+0x10/0x10\n l2cap_chan_send+0x1fd/0x1300 [bluetooth]\n ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]\n ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]\n ? lock_release+0x1d5/0x3c0\n ? mark_held_locks+0x1a/0x90\n l2cap_sock_sendmsg+0x100/0x170 [bluetooth]\n sock_write_iter+0x275/0x280\n ? __pfx_sock_write_iter+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n do_iter_readv_writev+0x176/0x220\n ? __pfx_do_iter_readv_writev+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? selinux_file_permission+0x13e/0x210\n do_iter_write+0xda/0x340\n vfs_writev+0x1b4/0x400\n ? __pfx_vfs_writev+0x10/0x10\n ? __seccomp_filter+0x112/0x750\n ? populate_seccomp_data+0x182/0x220\n ? __fget_light+0xdf/0x100\n ? do_writev+0x19d/0x210\n do_writev+0x19d/0x210\n ? __pfx_do_writev+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0x60/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n ? do_syscall_64+0x6c/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7ff45cb23e64\nCode: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\nRSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: \n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":7e-05,"ranking_epss":0.0051,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/093a07052406b363b1b2ab489e17dbadaf3e509b","https://git.kernel.org/stable/c/1ecf6dc2676ead4b927c50b1be0851fa4d756574","https://git.kernel.org/stable/c/59bd1e476bbc7bc6dff3c61bba787095a4839796","https://git.kernel.org/stable/c/7f7cfcb6f0825652973b780f248603e23f16ee90"],"published_time":"2025-10-07T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53674","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nclk: Fix memory leak in devm_clk_notifier_register()\n\ndevm_clk_notifier_register() allocates a devres resource for clk\nnotifier but didn't register that to the device, so the notifier didn't\nget unregistered on device detach and the allocated resource was leaked.\n\nFix the issue by registering the resource through devres_add().\n\nThis issue was found with kmemleak on a Chromebook.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/49451db71b746df990888068961f1033f7c9b734","https://git.kernel.org/stable/c/7fb933e56f77a57ef7cfc59fc34cbbf1b1fa31ff","https://git.kernel.org/stable/c/a326cf0107b197e649bbaa2a2b1355894826ce32","https://git.kernel.org/stable/c/cb1b04fd4283fc8f9acefe0ddc61ba072ed44877","https://git.kernel.org/stable/c/efbbda79b2881a04dcd0e8f28634933d79e17e49"],"published_time":"2025-10-07T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53675","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix possible desc_ptr out-of-bounds accesses\n\nSanitize possible desc_ptr out-of-bounds accesses in\nses_enclosure_data_process().","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/414418abc19fa4ccf730d273061a426c07a061d6","https://git.kernel.org/stable/c/4b8cae410472653a59e15af62c57c49b8e0a1201","https://git.kernel.org/stable/c/584892fd29a41ef424a148118a3103b16b94fb8c","https://git.kernel.org/stable/c/72021ae61a2bc6ca73cd593e255a10ed5f5dc5e7","https://git.kernel.org/stable/c/79ec5dd5fb07ecaea2f978c2d7a9f2f3526e4d19","https://git.kernel.org/stable/c/801ab13d50cf3d26170ee073ea8bb4eececb76ab","https://git.kernel.org/stable/c/c315560e3ef77c1d822249f1743e647dc9c9912a","https://git.kernel.org/stable/c/cffe09ca0555e235a42d6fa065e463c4b3d5b657"],"published_time":"2025-10-07T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53676","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()\n\nThe function lio_target_nacl_info_show() uses sprintf() in a loop to print\ndetails for every iSCSI connection in a session without checking for the\nbuffer length. With enough iSCSI connections it's possible to overflow the\nbuffer provided by configfs and corrupt the memory.\n\nThis patch replaces sprintf() with sysfs_emit_at() that checks for buffer\nboundries.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0cac6cbb9908309352a5d30c1876882771d3da50","https://git.kernel.org/stable/c/114b44dddea1f8f99576de3c0e6e9059012002fc","https://git.kernel.org/stable/c/2cbe6a88fbdd6e8aeab358eef61472e2de43d6f6","https://git.kernel.org/stable/c/4738bf8b2d3635c2944b81b2a84d97b8c8b0978d","https://git.kernel.org/stable/c/5353df78c22623b42a71d51226d228a8413097e2","https://git.kernel.org/stable/c/801f287c93ff95582b0a2d2163f12870a2f076d4","https://git.kernel.org/stable/c/bbe3ff47bf09db8956bc2eeb49d2d514d256ad2a","https://git.kernel.org/stable/c/df349e84c2cb0dd05d98c8e1189c26ab4b116083"],"published_time":"2025-10-07T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53677","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix memory leaks in i915 selftests\n\nThis patch fixes memory leaks on error escapes in function fake_get_pages\n\n(cherry picked from commit 8bfbdadce85c4c51689da10f39c805a7106d4567)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/596d7308e189a3230bf33d667b64acc73846c2d0","https://git.kernel.org/stable/c/803033c148f754f32da1b93926c49c22731ec485"],"published_time":"2025-10-07T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53678","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix system suspend without fbdev being initialized\n\nIf fbdev is not initialized for some reason - in practice on platforms\nwithout display - suspending fbdev should be skipped during system\nsuspend, fix this up. While at it add an assert that suspending fbdev\nonly happens with the display present.\n\nThis fixes the following:\n\n[   91.227923] PM: suspend entry (s2idle)\n[   91.254598] Filesystems sync: 0.025 seconds\n[   91.270518] Freezing user space processes\n[   91.272266] Freezing user space processes completed (elapsed 0.001 seconds)\n[   91.272686] OOM killer disabled.\n[   91.272872] Freezing remaining freezable tasks\n[   91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)\n[   91.659622] BUG: kernel NULL pointer dereference, address: 00000000000001c8\n[   91.659981] #PF: supervisor write access in kernel mode\n[   91.660252] #PF: error_code(0x0002) - not-present page\n[   91.660511] PGD 0 P4D 0\n[   91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[   91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54\n[   91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown\n[   91.661680] RIP: 0010:mutex_lock+0x19/0x30\n[   91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b4 0f 1f 40\n[   91.662840] RSP: 0018:ffffa1e8011ffc08 EFLAGS: 00010246\n[   91.663087] RAX: 0000000000000000 RBX: 00000000000001c8 RCX: 0000000000000000\n[   91.663440] RDX: ffff8be455eb0000 RSI: 0000000000000001 RDI: 00000000000001c8\n[   91.663802] RBP: ffff8be459440000 R08: ffff8be459441f08 R09: ffffffff8e1432c0\n[   91.664167] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001\n[   91.664532] R13: 00000000000001c8 R14: 0000000000000000 R15: ffff8be442f4fb20\n[   91.664905] FS:  00007f28ffc16740(0000) GS:ffff8be4bb900000(0000) knlGS:0000000000000000\n[   91.665334] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   91.665626] CR2: 00000000000001c8 CR3: 0000000114926006 CR4: 0000000000770ee0\n[   91.665988] PKRU: 55555554\n[   91.666131] Call Trace:\n[   91.666265]  <TASK>\n[   91.666381]  intel_fbdev_set_suspend+0x97/0x1b0 [i915]\n[   91.666738]  i915_drm_suspend+0xb9/0x100 [i915]\n[   91.667029]  pci_pm_suspend+0x78/0x170\n[   91.667234]  ? __pfx_pci_pm_suspend+0x10/0x10\n[   91.667461]  dpm_run_callback+0x47/0x150\n[   91.667673]  __device_suspend+0x10a/0x4e0\n[   91.667880]  dpm_suspend+0x134/0x270\n[   91.668069]  dpm_suspend_start+0x79/0x80\n[   91.668272]  suspend_devices_and_enter+0x11b/0x890\n[   91.668526]  pm_suspend.cold+0x270/0x2fc\n[   91.668737]  state_store+0x46/0x90\n[   91.668916]  kernfs_fop_write_iter+0x11b/0x200\n[   91.669153]  vfs_write+0x1e1/0x3a0\n[   91.669336]  ksys_write+0x53/0xd0\n[   91.669510]  do_syscall_64+0x58/0xc0\n[   91.669699]  ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0\n[   91.669980]  ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0\n[   91.670278]  ? syscall_exit_to_user_mode+0x17/0x40\n[   91.670524]  ? do_syscall_64+0x67/0xc0\n[   91.670717]  ? __irq_exit_rcu+0x3d/0x140\n[   91.670931]  entry_SYSCALL_64_after_hwframe+0x72/0xdc\n[   91.671202] RIP: 0033:0x7f28ffd14284\n\nv2: CC stable. (Jani)\n\nReferences: https://gitlab.freedesktop.org/drm/intel/-/issues/8015\n(cherry picked from commit 9542d708409a41449e99c9a464deb5e062c4bee2)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/27b5871abd5cc068c549fd23062c82e257fc0b9c","https://git.kernel.org/stable/c/8038510b1fe443ffbc0e356db5f47cbb8678a594","https://git.kernel.org/stable/c/8ed572d5a0f1509e691a75a0e3d3588050371f1e"],"published_time":"2025-10-07T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53663","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Check instead of asserting on nested TSC scaling support\n\nCheck for nested TSC scaling support on nested SVM VMRUN instead of\nasserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO\nhas diverged from KVM's default.  Userspace can trigger the WARN at will\nby writing the MSR and then updating guest CPUID to hide the feature\n(modifying guest CPUID is allowed anytime before KVM_RUN).  E.g. hacking\nKVM's state_test selftest to do\n\n\t\tvcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);\n\t\tvcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);\n\nafter restoring state in a new VM+vCPU yields an endless supply of:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699\n           nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]\n  Call Trace:\n   <TASK>\n   enter_svm_guest_mode+0x114/0x560 [kvm_amd]\n   nested_svm_vmrun+0x260/0x330 [kvm_amd]\n   vmrun_interception+0x29/0x30 [kvm_amd]\n   svm_invoke_exit_handler+0x35/0x100 [kvm_amd]\n   svm_handle_exit+0xe7/0x180 [kvm_amd]\n   kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]\n   kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]\n   __se_sys_ioctl+0x7a/0xc0\n   __x64_sys_ioctl+0x21/0x30\n   do_syscall_64+0x41/0x90\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n  RIP: 0033:0x45ca1b\n\nNote, the nested #VMEXIT path has the same flaw, but needs a different\nfix and will be handled separately.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/02b24270568f65dd607c4a848512dc8055b4491b","https://git.kernel.org/stable/c/6c1ecfea1daf6e75c46e295aad99dfbafd878897","https://git.kernel.org/stable/c/7cafe9b8e22bb3d77f130c461aedf6868c4aaf58"],"published_time":"2025-10-07T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53664","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nOPP: Fix potential null ptr dereference in dev_pm_opp_get_required_pstate()\n\n\"opp\" pointer is dereferenced before the IS_ERR_OR_NULL() check. Fix it by\nremoving the dereference to cache opp_table and dereference it directly\nwhere opp_table is used.\n\nThis fixes the following smatch warning:\n\ndrivers/opp/core.c:232 dev_pm_opp_get_required_pstate() warn: variable\ndereferenced before IS_ERR check 'opp' (see line 230)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/25130b27e0352acb83e91c467853eb9afad3b644","https://git.kernel.org/stable/c/7ddd8deb1c3c0363a7e14fafb5df26e2089a69a5"],"published_time":"2025-10-07T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53665","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmd: don't dereference mddev after export_rdev()\n\nExcept for initial reference, mddev->kobject is referenced by\nrdev->kobject, and if the last rdev is freed, there is no guarantee that\nmddev is still valid. Hence mddev should not be used anymore after\nexport_rdev().\n\nThis problem can be triggered by following test for mdadm at very\nlow rate:\n\nNew file: mdadm/tests/23rdev-lifetime\n\ndevname=${dev0##*/}\ndevt=`cat /sys/block/$devname/dev`\npid=\"\"\nruntime=2\n\nclean_up_test() {\n        pill -9 $pid\n        echo clear > /sys/block/md0/md/array_state\n}\n\ntrap 'clean_up_test' EXIT\n\nadd_by_sysfs() {\n        while true; do\n                echo $devt > /sys/block/md0/md/new_dev\n        done\n}\n\nremove_by_sysfs(){\n        while true; do\n                echo remove > /sys/block/md0/md/dev-${devname}/state\n        done\n}\n\necho md0 > /sys/module/md_mod/parameters/new_array || die \"create md0 failed\"\n\nadd_by_sysfs &\npid=\"$pid $!\"\n\nremove_by_sysfs &\npid=\"$pid $!\"\n\nsleep $runtime\nexit 0\n\nTest cmd:\n\n./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime\n\nTest result:\n\ngeneral protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP\nCPU: 0 PID: 1292 Comm: test Tainted: G      D W          6.5.0-rc2-00121-g01e55c376936 #562\nRIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]\nCall Trace:\n <TASK>\n mddev_unlock+0x1b6/0x310 [md_mod]\n rdev_attr_store+0xec/0x190 [md_mod]\n sysfs_kf_write+0x52/0x70\n kernfs_fop_write_iter+0x19a/0x2a0\n vfs_write+0x3b5/0x770\n ksys_write+0x74/0x150\n __x64_sys_write+0x22/0x30\n do_syscall_64+0x40/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nFix this problem by don't dereference mddev after export_rdev().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7deac114be5fb25a4e865212ed0feaf5f85f2a28","https://git.kernel.org/stable/c/ad430ad0669d2757377373390d68e1454fc7a344"],"published_time":"2025-10-07T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53666","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: codecs: wcd938x: fix missing mbhc init error handling\n\nMBHC initialisation can fail so add the missing error handling to avoid\ndereferencing an error pointer when later configuring the jack:\n\n    Unable to handle kernel paging request at virtual address fffffffffffffff8\n\n    pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]\n    lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]\n\n    Call trace:\n     wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]\n     wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]\n     snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]\n     qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]\n     sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]\n     snd_soc_link_init+0x28/0x90 [snd_soc_core]\n     snd_soc_bind_card+0x628/0xbfc [snd_soc_core]\n     snd_soc_register_card+0xec/0x104 [snd_soc_core]\n     devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]\n     sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/31ee704c84c4bf4df8521ef1478c161f710d0f94","https://git.kernel.org/stable/c/5a34d252052b5da743ef82591c860fc947384d4e","https://git.kernel.org/stable/c/7dfae2631bfbdebecd35fe7b472ab3cc95c9ed66","https://git.kernel.org/stable/c/bb241ae928c694e365c30c888c9eb02dcc812dfd"],"published_time":"2025-10-07T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53667","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: cdc_ncm: Deal with too low values of dwNtbOutMaxSize\n\nCurrently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than\nthe calculated \"min\" value, but greater than zero, the logic sets\ntx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in\ncdc_ncm_fill_tx_frame() where all the data is handled.\n\nFor small values of dwNtbOutMaxSize the memory allocated during\nalloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to\nhow size is aligned at alloc time:\n\tsize = SKB_DATA_ALIGN(size);\n        size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));\nThus we hit the same bug that we tried to squash with\ncommit 2be6d4d16a084 (\"net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero\")\n\nLow values of dwNtbOutMaxSize do not cause an issue presently because at\nalloc_skb() time more memory (512b) is allocated than required for the\nSKB headers alone (320b), leaving some space (512b - 320b = 192b)\nfor CDC data (172b).\n\nHowever, if more elements (for example 3 x u64 = [24b]) were added to\none of the SKB header structs, say 'struct skb_shared_info',\nincreasing its original size (320b [320b aligned]) to something larger\n(344b [384b aligned]), then suddenly the CDC data (172b) no longer\nfits in the spare SKB data area (512b - 384b = 128b).\n\nConsequently the SKB bounds checking semantics fails and panics:\n\nskbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL>\n------------[ cut here ]------------\nkernel BUG at net/core/skbuff.c:113!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN\nCPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023\nWorkqueue: mld mld_ifc_work\nRIP: 0010:skb_panic net/core/skbuff.c:113 [inline]\nRIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118\n[snip]\nCall Trace:\n <TASK>\n skb_put+0x151/0x210 net/core/skbuff.c:2047\n skb_put_zero include/linux/skbuff.h:2422 [inline]\n cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline]\n cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308\n cdc_ncm_tx_fixup+0xa3/0x100\n\nDeal with too low values of dwNtbOutMaxSize, clamp it in the range\n[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure\nenough data space is allocated to handle CDC data by making sure\ndwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02821,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2334ff0b343ba6ba7a6c0586fcc83992bbbc1776","https://git.kernel.org/stable/c/42b78c8cc774b47023d6d16d96d54cc7015e4a07","https://git.kernel.org/stable/c/6147745d43ff4e0d2c542e5b93e398ef0ee4db00","https://git.kernel.org/stable/c/72d0240b0ee4794efc683975c213e4b384fea733","https://git.kernel.org/stable/c/7e01c7f7046efc2c7c192c3619db43292b98e997","https://git.kernel.org/stable/c/9be921854e983a81a0aeeae5febcd87093086e46","https://git.kernel.org/stable/c/bf415bfe7573596ac213b4fd1da9e62cfc9a9413","https://git.kernel.org/stable/c/ff484163dfb61b58f23e4dbd007de1094427669c"],"published_time":"2025-10-07T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53668","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nring-buffer: Fix deadloop issue on reading trace_pipe\n\nSoft lockup occurs when reading file 'trace_pipe':\n\n  watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]\n  [...]\n  RIP: 0010:ring_buffer_empty_cpu+0xed/0x170\n  RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246\n  RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb\n  RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218\n  RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f\n  R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901\n  R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000\n  [...]\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   __find_next_entry+0x1a8/0x4b0\n   ? peek_next_entry+0x250/0x250\n   ? down_write+0xa5/0x120\n   ? down_write_killable+0x130/0x130\n   trace_find_next_entry_inc+0x3b/0x1d0\n   tracing_read_pipe+0x423/0xae0\n   ? tracing_splice_read_pipe+0xcb0/0xcb0\n   vfs_read+0x16b/0x490\n   ksys_read+0x105/0x210\n   ? __ia32_sys_pwrite64+0x200/0x200\n   ? switch_fpu_return+0x108/0x220\n   do_syscall_64+0x33/0x40\n   entry_SYSCALL_64_after_hwframe+0x61/0xc6\n\nThrough the vmcore, I found it's because in tracing_read_pipe(),\nring_buffer_empty_cpu() found some buffer is not empty but then it\ncannot read anything due to \"rb_num_of_entries() == 0\" always true,\nThen it infinitely loop the procedure due to user buffer not been\nfilled, see following code path:\n\n  tracing_read_pipe() {\n    ... ...\n    waitagain:\n      tracing_wait_pipe() // 1. find non-empty buffer here\n      trace_find_next_entry_inc()  // 2. loop here try to find an entry\n        __find_next_entry()\n          ring_buffer_empty_cpu();  // 3. find non-empty buffer\n          peek_next_entry()  // 4. but peek always return NULL\n            ring_buffer_peek()\n              rb_buffer_peek()\n                rb_get_reader_page()\n                  // 5. because rb_num_of_entries() == 0 always true here\n                  //    then return NULL\n      // 6. user buffer not been filled so goto 'waitgain'\n      //    and eventually leads to an deadloop in kernel!!!\n  }\n\nBy some analyzing, I found that when resetting ringbuffer, the 'entries'\nof its pages are not all cleared (see rb_reset_cpu()). Then when reducing\nthe ringbuffer, and if some reduced pages exist dirty 'entries' data, they\nwill be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which\ncause wrong 'overrun' count and eventually cause the deadloop issue.\n\nTo fix it, we need to clear every pages in rb_reset_cpu().","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0a29dae5786d263016a9aceb1e56bf3fd4cc6fa0","https://git.kernel.org/stable/c/27bdd93e44cc28dd9b94893fae146b83d4f5b31e","https://git.kernel.org/stable/c/5e68f1f3a20fe9b6bde018e353269fbfa289609c","https://git.kernel.org/stable/c/7e42907f3a7b4ce3a2d1757f6d78336984daf8f5","https://git.kernel.org/stable/c/8b0b63fdac6b70a45614e7d4b30e5bbb93deb007","https://git.kernel.org/stable/c/a55e8a3596048c2f7b574049aeb1885b5abba1cc","https://git.kernel.org/stable/c/bb14a93bccc92766b1d9302c6bcbea17d4bce306","https://git.kernel.org/stable/c/e84829522fc72bb43556b31575731de0440ac0dd"],"published_time":"2025-10-07T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53669","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix skb_copy_ubufs() vs BIG TCP\n\nDavid Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy\nusing hugepages, and skb length bigger than ~68 KB.\n\nskb_copy_ubufs() assumed it could copy all payload using up to\nMAX_SKB_FRAGS order-0 pages.\n\nThis assumption broke when BIG TCP was able to put up to 512 KB per skb.\n\nWe did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45\nand limit gso_max_size to 180000.\n\nA solution is to use higher order pages if needed.\n\nv2: add missing __GFP_COMP, or we leak memory.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3c77a377877acbaf03cd7caa21d3644a5dd16301","https://git.kernel.org/stable/c/7e692df3933628d974acb9f5b334d2b3e885e2a6","https://git.kernel.org/stable/c/7fa93e39fbb0566019c388a8038a4d58552e0910","https://git.kernel.org/stable/c/9cd62f0ba465cf647c7d8c2ca7b0d99ea0c1328f"],"published_time":"2025-10-07T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53670","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-core: fix dev_pm_qos memleak\n\nCall dev_pm_qos_hide_latency_tolerance() in the error unwind patch to\navoid following kmemleak:-\n\nblktests (master) # kmemleak-clear; ./check nvme/044;\nblktests (master) # kmemleak-scan ; kmemleak-show\nnvme/044 (Test bi-directional authentication)                [passed]\n    runtime  2.111s  ...  2.124s\nunreferenced object 0xffff888110c46240 (size 96):\n  comm \"nvme\", pid 33461, jiffies 4345365353 (age 75.586s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<0000000069ac2cec>] kmalloc_trace+0x25/0x90\n    [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100\n    [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core]\n    [<000000007df61b4b>] 0xffffffffc05e88b3\n    [<00000000d152b985>] 0xffffffffc05744cb\n    [<00000000f04a4041>] vfs_write+0xc5/0x3c0\n    [<00000000f9491baf>] ksys_write+0x5f/0xe0\n    [<000000001c46513d>] do_syscall_64+0x3b/0x90\n    [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00019,"ranking_epss":0.05109,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2ed9a89192e3192e5fea7ff6475c8722513f325e","https://git.kernel.org/stable/c/7237c26431cc78e5ec3259f4350f3dd58f6a4319","https://git.kernel.org/stable/c/7ed5cf8e6d9bfb6a78d0471317edff14f0f2b4dd","https://git.kernel.org/stable/c/e1379e067b9485e5af03399fe3f0d39bccb023ad"],"published_time":"2025-10-07T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53655","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed\n\nRegistering a kprobe on __rcu_irq_enter_check_tick() can cause kernel\nstack overflow as shown below. This issue can be reproduced by enabling\nCONFIG_NO_HZ_FULL and booting the kernel with argument \"nohz_full=\",\nand then giving the following commands at the shell prompt:\n\n  # cd /sys/kernel/tracing/\n  # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events\n  # echo 1 > events/kprobes/enable\n\nThis commit therefore adds __rcu_irq_enter_check_tick() to the kprobes\nblacklist using NOKPROBE_SYMBOL().\n\nInsufficient stack space to handle exception!\nESR: 0x00000000f2000004 -- BRK (AArch64)\nFAR: 0x0000ffffccf3e510\nTask stack:     [0xffff80000ad30000..0xffff80000ad38000]\nIRQ stack:      [0xffff800008050000..0xffff800008058000]\nOverflow stack: [0xffff089c36f9f310..0xffff089c36fa0310]\nCPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19\nHardware name: linux,dummy-virt (DT)\npstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __rcu_irq_enter_check_tick+0x0/0x1b8\nlr : ct_nmi_enter+0x11c/0x138\nsp : ffff80000ad30080\nx29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000\nx26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000\nx23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148\nx20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c\nx14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809\nx11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000\nx8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001\nx5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4\nx2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000\nKernel panic - not syncing: kernel stack overflow\nCPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19\nHardware name: linux,dummy-virt (DT)\nCall trace:\n dump_backtrace+0xf8/0x108\n show_stack+0x20/0x30\n dump_stack_lvl+0x68/0x84\n dump_stack+0x1c/0x38\n panic+0x214/0x404\n add_taint+0x0/0xf8\n panic_bad_stack+0x144/0x160\n handle_bad_stack+0x38/0x58\n __bad_stack+0x78/0x7c\n __rcu_irq_enter_check_tick+0x0/0x1b8\n arm64_enter_el1_dbg.isra.0+0x14/0x20\n el1_dbg+0x2c/0x90\n el1h_64_sync_handler+0xcc/0xe8\n el1h_64_sync+0x64/0x68\n __rcu_irq_enter_check_tick+0x0/0x1b8\n arm64_enter_el1_dbg.isra.0+0x14/0x20\n el1_dbg+0x2c/0x90\n el1h_64_sync_handler+0xcc/0xe8\n el1h_64_sync+0x64/0x68\n __rcu_irq_enter_check_tick+0x0/0x1b8\n arm64_enter_el1_dbg.isra.0+0x14/0x20\n el1_dbg+0x2c/0x90\n el1h_64_sync_handler+0xcc/0xe8\n el1h_64_sync+0x64/0x68\n __rcu_irq_enter_check_tick+0x0/0x1b8\n [...]\n el1_dbg+0x2c/0x90\n el1h_64_sync_handler+0xcc/0xe8\n el1h_64_sync+0x64/0x68\n __rcu_irq_enter_check_tick+0x0/0x1b8\n arm64_enter_el1_dbg.isra.0+0x14/0x20\n el1_dbg+0x2c/0x90\n el1h_64_sync_handler+0xcc/0xe8\n el1h_64_sync+0x64/0x68\n __rcu_irq_enter_check_tick+0x0/0x1b8\n arm64_enter_el1_dbg.isra.0+0x14/0x20\n el1_dbg+0x2c/0x90\n el1h_64_sync_handler+0xcc/0xe8\n el1h_64_sync+0x64/0x68\n __rcu_irq_enter_check_tick+0x0/0x1b8\n el1_interrupt+0x28/0x60\n el1h_64_irq_handler+0x18/0x28\n el1h_64_irq+0x64/0x68\n __ftrace_set_clr_event_nolock+0x98/0x198\n __ftrace_set_clr_event+0x58/0x80\n system_enable_write+0x144/0x178\n vfs_write+0x174/0x738\n ksys_write+0xd0/0x188\n __arm64_sys_write+0x4c/0x60\n invoke_syscall+0x64/0x180\n el0_svc_common.constprop.0+0x84/0x160\n do_el0_svc+0x48/0xe8\n el0_svc+0x34/0xd0\n el0t_64_sync_handler+0xb8/0xc0\n el0t_64_sync+0x190/0x194\nSMP: stopping secondary CPUs\nKernel Offset: 0x28da86000000 from 0xffff800008000000\nPHYS_OFFSET: 0xfffff76600000000\nCPU features: 0x00000,01a00100,0000421b\nMemory Limit: none","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.02011,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4c3d1a6720aefb02403ddfebe85db521d3af2c3b","https://git.kernel.org/stable/c/7a29fb4a4771124bc61de397dbfc1554dbbcc19c","https://git.kernel.org/stable/c/7b5a97333e920b69356e097f185bdc51d61e66ee","https://git.kernel.org/stable/c/93b6295f677d96b73cfcb703532f6c7369a60d96","https://git.kernel.org/stable/c/c8a3341b339285495cf7c8d061d659465f2311e0","https://git.kernel.org/stable/c/eb18bc5a8678f431c500e6da1b8b5f34478d5bc1"],"published_time":"2025-10-07T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53656","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/perf: hisi: Don't migrate perf to the CPU going to teardown\n\nThe driver needs to migrate the perf context if the current using CPU going\nto teardown. By the time calling the cpuhp::teardown() callback the\ncpu_online_mask() hasn't updated yet and still includes the CPU going to\nteardown. In current driver's implementation we may migrate the context\nto the teardown CPU and leads to the below calltrace:\n\n...\n[  368.104662][  T932] task:cpuhp/0         state:D stack:    0 pid:   15 ppid:     2 flags:0x00000008\n[  368.113699][  T932] Call trace:\n[  368.116834][  T932]  __switch_to+0x7c/0xbc\n[  368.120924][  T932]  __schedule+0x338/0x6f0\n[  368.125098][  T932]  schedule+0x50/0xe0\n[  368.128926][  T932]  schedule_preempt_disabled+0x18/0x24\n[  368.134229][  T932]  __mutex_lock.constprop.0+0x1d4/0x5dc\n[  368.139617][  T932]  __mutex_lock_slowpath+0x1c/0x30\n[  368.144573][  T932]  mutex_lock+0x50/0x60\n[  368.148579][  T932]  perf_pmu_migrate_context+0x84/0x2b0\n[  368.153884][  T932]  hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]\n[  368.160579][  T932]  cpuhp_invoke_callback+0x2a0/0x650\n[  368.165707][  T932]  cpuhp_thread_fun+0xe4/0x190\n[  368.170316][  T932]  smpboot_thread_fn+0x15c/0x1a0\n[  368.175099][  T932]  kthread+0x108/0x13c\n[  368.179012][  T932]  ret_from_fork+0x10/0x18\n...\n\nUse function cpumask_any_but() to find one correct active cpu to fixes\nthis issue.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7a6a9f1c5a0a875a421db798d4b2ee022dc1ee1a","https://git.kernel.org/stable/c/b64569897d86b611befbb895d815280fea94e1ed","https://git.kernel.org/stable/c/be9c8c9c84b6d25a7b7d39954030aba6f759feb6","https://git.kernel.org/stable/c/f564e543a43d0f1cabac791672c8a6fc78ce12d0"],"published_time":"2025-10-07T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53657","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nice: Don't tx before switchdev is fully configured\n\nThere is possibility that ice_eswitch_port_start_xmit might be\ncalled while some resources are still not allocated which might\ncause NULL pointer dereference. Fix this by checking if switchdev\nconfiguration was finished.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5760a72b3060150b587eff3e879648c7470efddd","https://git.kernel.org/stable/c/63ff5a94649837d980e3b9ef535c793ec8cb0ca7","https://git.kernel.org/stable/c/7aa529a69e92b9aff585e569d5003f7c15d8d60b"],"published_time":"2025-10-07T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53658","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nspi: bcm-qspi: return error if neither hif_mspi nor mspi is available\n\nIf neither a \"hif_mspi\" nor \"mspi\" resource is present, the driver will\njust early exit in probe but still return success. Apart from not doing\nanything meaningful, this would then also lead to a null pointer access\non removal, as platform_get_drvdata() would return NULL, which it would\nthen try to dereference when trying to unregister the spi master.\n\nFix this by unconditionally calling devm_ioremap_resource(), as it can\nhandle a NULL res and will then return a viable ERR_PTR() if we get one.\n\nThe \"return 0;\" was previously a \"goto qspi_resource_err;\" where then\nret was returned, but since ret was still initialized to 0 at this place\nthis was a valid conversion in 63c5395bb7a9 (\"spi: bcm-qspi: Fix\nuse-after-free on unbind\"). The issue was not introduced by this commit,\nonly made more obvious.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/217b6ea8cf7b819477bca597a6ae2d43d38ba283","https://git.kernel.org/stable/c/22ae32d80ef590d12a2364e4621f90f7c58445c7","https://git.kernel.org/stable/c/32b9c8f7892c19f7f5c9fed5fb410b9fd5990bb6","https://git.kernel.org/stable/c/398e6a015877d44327f754aeb48ff3354945c78c","https://git.kernel.org/stable/c/7c1f23ad34fcdace50275a6aa1e1969b41c6233f","https://git.kernel.org/stable/c/a91c34357afcfaa5307e254f22a8452550a07b34","https://git.kernel.org/stable/c/d20db3c58a7f9361e370a7850ceb60dbdf62eea3","https://git.kernel.org/stable/c/d3dcdb43c872a3b967345144151a2c9bb9124c9b"],"published_time":"2025-10-07T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53659","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix out-of-bounds when setting channels on remove\n\nIf we set channels greater during iavf_remove(), and waiting reset done\nwould be timeout, then returned with error but changed num_active_queues\ndirectly, that will lead to OOB like the following logs. Because the\nnum_active_queues is greater than tx/rx_rings[] allocated actually.\n\nReproducer:\n\n  [root@host ~]# cat repro.sh\n  #!/bin/bash\n\n  pf_dbsf=\"0000:41:00.0\"\n  vf0_dbsf=\"0000:41:02.0\"\n  g_pids=()\n\n  function do_set_numvf()\n  {\n      echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs\n      sleep $((RANDOM%3+1))\n      echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs\n      sleep $((RANDOM%3+1))\n  }\n\n  function do_set_channel()\n  {\n      local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)\n      [ -z \"$nic\" ] && { sleep $((RANDOM%3)) ; return 1; }\n      ifconfig $nic 192.168.18.5 netmask 255.255.255.0\n      ifconfig $nic up\n      ethtool -L $nic combined 1\n      ethtool -L $nic combined 4\n      sleep $((RANDOM%3))\n  }\n\n  function on_exit()\n  {\n      local pid\n      for pid in \"${g_pids[@]}\"; do\n          kill -0 \"$pid\" &>/dev/null && kill \"$pid\" &>/dev/null\n      done\n      g_pids=()\n  }\n\n  trap \"on_exit; exit\" EXIT\n\n  while :; do do_set_numvf ; done &\n  g_pids+=($!)\n  while :; do do_set_channel ; done &\n  g_pids+=($!)\n\n  wait\n\nResult:\n\n[ 3506.152887] iavf 0000:41:02.0: Removing device\n[ 3510.400799] ==================================================================\n[ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf]\n[ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536\n[ 3510.400823]\n[ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G           O     --------- -t - 4.18.0 #1\n[ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021\n[ 3510.400835] Call Trace:\n[ 3510.400851]  dump_stack+0x71/0xab\n[ 3510.400860]  print_address_description+0x6b/0x290\n[ 3510.400865]  ? iavf_free_all_tx_resources+0x156/0x160 [iavf]\n[ 3510.400868]  kasan_report+0x14a/0x2b0\n[ 3510.400873]  iavf_free_all_tx_resources+0x156/0x160 [iavf]\n[ 3510.400880]  iavf_remove+0x2b6/0xc70 [iavf]\n[ 3510.400884]  ? iavf_free_all_rx_resources+0x160/0x160 [iavf]\n[ 3510.400891]  ? wait_woken+0x1d0/0x1d0\n[ 3510.400895]  ? notifier_call_chain+0xc1/0x130\n[ 3510.400903]  pci_device_remove+0xa8/0x1f0\n[ 3510.400910]  device_release_driver_internal+0x1c6/0x460\n[ 3510.400916]  pci_stop_bus_device+0x101/0x150\n[ 3510.400919]  pci_stop_and_remove_bus_device+0xe/0x20\n[ 3510.400924]  pci_iov_remove_virtfn+0x187/0x420\n[ 3510.400927]  ? pci_iov_add_virtfn+0xe10/0xe10\n[ 3510.400929]  ? pci_get_subsys+0x90/0x90\n[ 3510.400932]  sriov_disable+0xed/0x3e0\n[ 3510.400936]  ? bus_find_device+0x12d/0x1a0\n[ 3510.400953]  i40e_free_vfs+0x754/0x1210 [i40e]\n[ 3510.400966]  ? i40e_reset_all_vfs+0x880/0x880 [i40e]\n[ 3510.400968]  ? pci_get_device+0x7c/0x90\n[ 3510.400970]  ? pci_get_subsys+0x90/0x90\n[ 3510.400982]  ? pci_vfs_assigned.part.7+0x144/0x210\n[ 3510.400987]  ? __mutex_lock_slowpath+0x10/0x10\n[ 3510.400996]  i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]\n[ 3510.401001]  sriov_numvfs_store+0x214/0x290\n[ 3510.401005]  ? sriov_totalvfs_show+0x30/0x30\n[ 3510.401007]  ? __mutex_lock_slowpath+0x10/0x10\n[ 3510.401011]  ? __check_object_size+0x15a/0x350\n[ 3510.401018]  kernfs_fop_write+0x280/0x3f0\n[ 3510.401022]  vfs_write+0x145/0x440\n[ 3510.401025]  ksys_write+0xab/0x160\n[ 3510.401028]  ? __ia32_sys_read+0xb0/0xb0\n[ 3510.401031]  ? fput_many+0x1a/0x120\n[ 3510.401032]  ? filp_close+0xf0/0x130\n[ 3510.401038]  do_syscall_64+0xa0/0x370\n[ 3510.401041]  ? page_fault+0x8/0x30\n[ 3510.401043]  entry_SYSCALL_64_after_hwframe+0x65/0xca\n[ 3510.401073] RIP: 0033:0x7f3a9bb842c0\n[ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d \n---truncated---","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.03059,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0fb37ce6c01e17839e26d03222f0b44e6a3ed2b9","https://git.kernel.org/stable/c/65ecebc9ac09427b2c65f271cd5e5bd536c3fe38","https://git.kernel.org/stable/c/6e1d8f1332076a002e6d910d255aa5903d341c56","https://git.kernel.org/stable/c/7c4bced3caa749ce468b0c5de711c98476b23a52","https://git.kernel.org/stable/c/b92defe4e8ee86996c16417ad8c804cb4395fddd"],"published_time":"2025-10-07T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53660","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, cpumap: Handle skb as well when clean up ptr_ring\n\nThe following warning was reported when running xdp_redirect_cpu with\nboth skb-mode and stress-mode enabled:\n\n  ------------[ cut here ]------------\n  Incorrect XDP memory type (-2128176192) usage\n  WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405\n  Modules linked in:\n  CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G  6.5.0-rc2+ #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n  Workqueue: events __cpu_map_entry_free\n  RIP: 0010:__xdp_return+0x1e4/0x4a0\n  ......\n  Call Trace:\n   <TASK>\n   ? show_regs+0x65/0x70\n   ? __warn+0xa5/0x240\n   ? __xdp_return+0x1e4/0x4a0\n   ......\n   xdp_return_frame+0x4d/0x150\n   __cpu_map_entry_free+0xf9/0x230\n   process_one_work+0x6b0/0xb80\n   worker_thread+0x96/0x720\n   kthread+0x1a5/0x1f0\n   ret_from_fork+0x3a/0x70\n   ret_from_fork_asm+0x1b/0x30\n   </TASK>\n\nThe reason for the warning is twofold. One is due to the kthread\ncpu_map_kthread_run() is stopped prematurely. Another one is\n__cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in\nptr_ring as XDP frames.\n\nPrematurely-stopped kthread will be fixed by the preceding patch and\nptr_ring will be empty when __cpu_map_ring_cleanup() is called. But\nas the comments in __cpu_map_ring_cleanup() said, handling and freeing\nskbs in ptr_ring as well to \"catch any broken behaviour gracefully\".","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7c62b75cd1a792e14b037fa4f61f9b18914e7de1","https://git.kernel.org/stable/c/937345720d18f1ad006ba3d5dcb3fa121037b8a2","https://git.kernel.org/stable/c/b58d34068fd9f96bfc7d389988dfaf9a92a8fe00","https://git.kernel.org/stable/c/cbd000451885801e9bbfd9cf7a7946806a85cb5e"],"published_time":"2025-10-07T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53661","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt: avoid overflow in bnxt_get_nvram_directory()\n\nThe value of an arithmetic expression is subject\nof possible overflow due to a failure to cast operands to a larger data\ntype before performing arithmetic. Used macro for multiplication instead\noperator for avoiding overflow.\n\nFound by Security Code and Linux Verification\nCenter (linuxtesting.org) with SVACE.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/17e0453a7523ad7a25bb47af941b150a6c66d7b6","https://git.kernel.org/stable/c/7c6dddc239abe660598c49ec95ea0ed6399a4b2a","https://git.kernel.org/stable/c/d5eaf2a6b077f32a477feb1e9e1c1f60605b460e","https://git.kernel.org/stable/c/efb1a257513438d43f4335f09b2f684e8167cad2"],"published_time":"2025-10-07T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53662","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}\n\nIf the filename casefolding fails, we'll be leaking memory from the\nfscrypt_name struct, namely from the 'crypto_buf.name' member.\n\nMake sure we free it in the error path on both ext4_fname_setup_filename()\nand ext4_fname_prepare_lookup() functions.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00016,"ranking_epss":0.03835,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1fb3f1bbfdb511034b0360dbeb0f6a8424ed2a5c","https://git.kernel.org/stable/c/36daf050be3f6f067631dc52054de2d3b7cc849f","https://git.kernel.org/stable/c/7ca4b085f430f3774c3838b3da569ceccd6a0177","https://git.kernel.org/stable/c/98fc9c2cc45cfcb56961a73de3ec69b474063fc0"],"published_time":"2025-10-07T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53646","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/perf: add sentinel to xehp_oa_b_counters\n\nArrays passed to reg_in_range_table should end with empty record.\n\nThe patch solves KASAN detected bug with signature:\nBUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]\nRead of size 4 at addr ffffffffa1555d90 by task perf/1518\n\nCPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1\nHardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023\nCall Trace:\n<TASK>\n...\nxehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]\n\n(cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798)","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/21d92025e80629fd5c25cd6751f8cf38c784dd4a","https://git.kernel.org/stable/c/785b3f667b4bf98804cad135005e964df0c750de"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53647","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nDrivers: hv: vmbus: Don't dereference ACPI root object handle\n\nSince the commit referenced in the Fixes: tag below the VMBus client driver\nis walking the ACPI namespace up from the VMBus ACPI device to the ACPI\nnamespace root object trying to find Hyper-V MMIO ranges.\n\nHowever, if it is not able to find them it ends trying to walk resources of\nthe ACPI namespace root object itself.\nThis object has all-ones handle, which causes a NULL pointer dereference\nin the ACPI code (from dereferencing this pointer with an offset).\n\nThis in turn causes an oops on boot with VMBus host implementations that do\nnot provide Hyper-V MMIO ranges in their VMBus ACPI device or its\nancestors.\nThe QEMU VMBus implementation is an example of such implementation.\n\nI guess providing these ranges is optional, since all tested Windows\nversions seem to be able to use VMBus devices without them.\n\nFix this by explicitly terminating the lookup at the ACPI namespace root\nobject.\n\nNote that Linux guests under KVM/QEMU do not use the Hyper-V PV interface\nby default - they only do so if the KVM PV interface is missing or\ndisabled.\n\nExample stack trace of such oops:\n[ 3.710827] ? __die+0x1f/0x60\n[ 3.715030] ? page_fault_oops+0x159/0x460\n[ 3.716008] ? exc_page_fault+0x73/0x170\n[ 3.716959] ? asm_exc_page_fault+0x22/0x30\n[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0\n[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0\n[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0\n[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200\n[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0\n[ 3.723559] ? down_timeout+0x3a/0x60\n[ 3.724455] ? acpi_ns_get_node+0x3a/0x60\n[ 3.725412] acpi_ns_get_node+0x3a/0x60\n[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0\n[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0\n[ 3.728400] acpi_rs_get_method_data+0x2b/0x70\n[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]\n[ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]\n[ 3.732411] acpi_walk_resources+0x78/0xd0\n[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]\n[ 3.734802] platform_probe+0x3d/0x90\n[ 3.735684] really_probe+0x19b/0x400\n[ 3.736570] ? __device_attach_driver+0x100/0x100\n[ 3.737697] __driver_probe_device+0x78/0x160\n[ 3.738746] driver_probe_device+0x1f/0x90\n[ 3.739743] __driver_attach+0xc2/0x1b0\n[ 3.740671] bus_for_each_dev+0x70/0xc0\n[ 3.741601] bus_add_driver+0x10e/0x210\n[ 3.742527] driver_register+0x55/0xf0\n[ 3.744412] ? 0xffffffffc039a000\n[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/64f09d45e94547fbf219f36d1d02ac42742c028c","https://git.kernel.org/stable/c/78e04bbff849b51b56f5925b1945db2c6e128b61","https://git.kernel.org/stable/c/96db43aced395844a7abc9a0a5cc702513e3534a","https://git.kernel.org/stable/c/9fc162c59edc841032a3553eb2334320abab0784"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53648","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer\n\nsmatch error:\nsound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:\nwe previously assumed 'rac97' could be null (see line 2072)\n\nremove redundant assignment, return error if rac97 is NULL.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00029,"ranking_epss":0.08328,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/09baf460dfba79ee6a0c72e68ccdbbba84d894df","https://git.kernel.org/stable/c/228da1fa124470606ac19783e551f9d51a1e01b0","https://git.kernel.org/stable/c/300e26e3e64880de5013eac8831cf44387ef752c","https://git.kernel.org/stable/c/5f13d67027fa782096e6aee0db5dce61c4aeb613","https://git.kernel.org/stable/c/79597c8bf64ca99eab385115743131d260339da5","https://git.kernel.org/stable/c/809af7bb4219bdeef0dbb8b2ed700d6516d13fe9","https://git.kernel.org/stable/c/d28b83252e150155b8b8c65b612c555e93c8b45f","https://git.kernel.org/stable/c/e4cccff1e7ab6ea30995b6fbbb007d02647e025c","https://git.kernel.org/stable/c/f923a582217b198b557756809ffe42ac0fad6adb"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53649","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nperf trace: Really free the evsel->priv area\n\nIn 3cb4d5e00e037c70 (\"perf trace: Free syscall tp fields in\nevsel->priv\") it only was freeing if strcmp(evsel->tp_format->system,\n\"syscalls\") returned zero, while the corresponding initialization of\nevsel->priv was being performed if it was _not_ zero, i.e. if the tp\nsystem wasn't 'syscalls'.\n\nJust stop looking for that and free it if evsel->priv was set, which\nshould be equivalent.\n\nAlso use the pre-existing evsel_trace__delete() function.\n\nThis resolves these leaks, detected with:\n\n  $ make EXTRA_CFLAGS=\"-fsanitize=address\" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin\n\n  =================================================================\n  ==481565==ERROR: LeakSanitizer: detected memory leaks\n\n  Direct leak of 40 byte(s) in 1 object(s) allocated from:\n      #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)\n      #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)\n      #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307\n      #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333\n      #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458\n      #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480\n      #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212\n      #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891\n      #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156\n      #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323\n      #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377\n      #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421\n      #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537\n      #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)\n\n  Direct leak of 40 byte(s) in 1 object(s) allocated from:\n      #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)\n      #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)\n      #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307\n      #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333\n      #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458\n      #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480\n      #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205\n      #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891\n      #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156\n      #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323\n      #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377\n      #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421\n      #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537\n      #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)\n\n  SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).\n  [root@quaco ~]#\n\nWith this we plug all leaks with \"perf trace sleep 1\".","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/27f396f64537b1ae48d0644d7cbf0d250b3c0b33","https://git.kernel.org/stable/c/62dd514c34be63d3d5cae1f52a7e8b96c6dd6630","https://git.kernel.org/stable/c/7962ef13651a9163f07b530607392ea123482e8a","https://git.kernel.org/stable/c/c3bc668581e71e7c3bc7eb1d647f25f8db222163"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53650","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()\n\nIf 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00029,"ranking_epss":0.08328,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/09ea1ae4a2ec17774892cfcff50f6d33dfa1e06f","https://git.kernel.org/stable/c/3b4c21804076e461a6453ee4d09872172336aa1d","https://git.kernel.org/stable/c/716efd08985e3104031d1b655930b1f1c45fa8a7","https://git.kernel.org/stable/c/79a3908d1ea6c35157a6d907b1a9d8ec06015e7a","https://git.kernel.org/stable/c/7a8f9293bee51183023c5e37e7ebf0543cd2a134","https://git.kernel.org/stable/c/7cca0af3167dd9603da5fa6fff3392f8338e97e1","https://git.kernel.org/stable/c/9e3858f82e3ced1e990ef7116c3a16c84e62093e","https://git.kernel.org/stable/c/ce6e0434e502abdf966164b7c72523fb5fe54635","https://git.kernel.org/stable/c/d97840bf5a388c6cbf6e46216887bf17be62acc2"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53651","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nInput: exc3000 - properly stop timer on shutdown\n\nWe need to stop the timer on driver unbind or probe failures, otherwise\nwe get UAF/Oops.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00026,"ranking_epss":0.07057,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/526a177ac6353d65057eadb5d6edafc168f64484","https://git.kernel.org/stable/c/79c81d137d36f9635bbcbc3916c0cccb418a61dd","https://git.kernel.org/stable/c/bee57c20fc0ca5ef9b9a53a0335eab2ac9e9cae1"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53652","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nvdpa: Add features attr to vdpa_nl_policy for nlattr length check\n\nThe vdpa_nl_policy structure is used to validate the nlattr when parsing\nthe incoming nlmsg. It will ensure the attribute being described produces\na valid nlattr pointer in info->attrs before entering into each handler\nin vdpa_nl_ops.\n\nThat is to say, the missing part in vdpa_nl_policy may lead to illegal\nnlattr after parsing, which could lead to OOB read just like CVE-2023-3773.\n\nThis patch adds the missing nla_policy for vdpa features attr to avoid\nsuch bugs.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00012,"ranking_epss":0.01866,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/44b508cc96889e61799cc0fc6c00766a54f3ab5a","https://git.kernel.org/stable/c/645d17e06c502e71b880b2b854930e5a64014640","https://git.kernel.org/stable/c/79c8651587504ba263d2fd67fd4406240fb21f69"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53653","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: amphion: fix REVERSE_INULL issues reported by coverity\n\nnull-checking of a pointor is suggested before dereferencing it","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/79d3bafaecc13bccab1ebbd28a15e669c5a4cdaf","https://git.kernel.org/stable/c/bddd678fd2864b435d00d51a4d3808a0d89c79de","https://git.kernel.org/stable/c/e59d0cd8f414592187ead97b5832600ff7a0dd61","https://git.kernel.org/stable/c/ef56b2db216f130c4240aed907d1c5272c2d298d"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53654","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-af: Add validation before accessing cgx and lmac\n\nwith the addition of new MAC blocks like CN10K RPM and CN10KB\nRPM_USX, LMACs are noncontiguous and CGX blocks are also\nnoncontiguous. But during RVU driver initialization, the driver\nis assuming they are contiguous and trying to access\ncgx or lmac with their id which is resulting in kernel panic.\n\nThis patch fixes the issue by adding proper checks.\n\n[   23.219150] pc : cgx_lmac_read+0x38/0x70\n[   23.219154] lr : rvu_program_channels+0x3f0/0x498\n[   23.223852] sp : ffff000100d6fc80\n[   23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:\n000000000000005a\n[   23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:\nfffffffffff0f000","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/79ebb53772c95d3a6ae51b3c65f9985fdd430df6","https://git.kernel.org/stable/c/a5485a943193e55c79150382e6461e8ea759e96e","https://git.kernel.org/stable/c/b04872e15f3df62cb2fd530950f769626e1ef489","https://git.kernel.org/stable/c/e425e2ba933618ee5ec8e4f3eb341efeb6c9ddef"],"published_time":"2025-10-07T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53638","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: cancel queued works in probe error path\n\nIf it fails to get the devices's MAC address, octep_probe exits while\nleaving the delayed work intr_poll_task queued. When the work later\nruns, it's a use after free.\n\nMove the cancelation of intr_poll_task from octep_remove into\noctep_device_cleanup. This does not change anything in the octep_remove\nflow, but octep_device_cleanup is called also in the octep_probe error\npath, where the cancelation is needed.\n\nNote that the cancelation of ctrl_mbox_task has to follow\nintr_poll_task's, because the ctrl_mbox_task may be queued by\nintr_poll_task.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/62312e2f6466b5f0a120542a38b410d88a34ed00","https://git.kernel.org/stable/c/758c91078165ae641b698750a72eafe7968b3756"],"published_time":"2025-10-07T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53639","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath6kl: reduce WARN to dev_dbg() in callback\n\nThe warn is triggered on a known race condition, documented in the code above\nthe test, that is correctly handled.  Using WARN() hinders automated testing.\nReducing severity.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d1792c98351b7c8ebdc53d052918e77d1e512c3","https://git.kernel.org/stable/c/1300517e371e4d0acdb0f1237477e1ed223c3a9a","https://git.kernel.org/stable/c/484d95c69fc1143f09e4c2e3b89019d68d190a92","https://git.kernel.org/stable/c/644df7e865e76ab7a62c67c25cbbc093c944d0ef","https://git.kernel.org/stable/c/6f93154d61b345acbc405c6dee16afb845eb298e","https://git.kernel.org/stable/c/75c4a8154cb6c7239fb55d5550f481f6765fb83c","https://git.kernel.org/stable/c/cbec770521ebc455c9811a23222faf8911422d4a","https://git.kernel.org/stable/c/e7865f84adaf75cee1a4bbf79680329eca92b4e1","https://git.kernel.org/stable/c/f2a429e6da37e32438a9adc250cc176a889c16a4"],"published_time":"2025-10-07T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53640","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: lpass: Fix for KASAN use_after_free out of bounds\n\nWhen we run syzkaller we get below Out of Bounds error.\n\n\"KASAN: slab-out-of-bounds Read in regcache_flat_read\"\n\nBelow is the backtrace of the issue:\n\nBUG: KASAN: slab-out-of-bounds in regcache_flat_read+0x10c/0x110\nRead of size 4 at addr ffffff8088fbf714 by task syz-executor.4/14144\nCPU: 6 PID: 14144 Comm: syz-executor.4 Tainted: G        W\nHardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)\nCall trace:\ndump_backtrace+0x0/0x4ec\nshow_stack+0x34/0x50\ndump_stack_lvl+0xdc/0x11c\nprint_address_description+0x30/0x2d8\nkasan_report+0x178/0x1e4\n__asan_report_load4_noabort+0x44/0x50\nregcache_flat_read+0x10c/0x110\nregcache_read+0xf8/0x5a0\n_regmap_read+0x45c/0x86c\n_regmap_update_bits+0x128/0x290\nregmap_update_bits_base+0xc0/0x15c\nsnd_soc_component_update_bits+0xa8/0x22c\nsnd_soc_component_write_field+0x68/0xd4\ntx_macro_put_dec_enum+0x1d0/0x268\nsnd_ctl_elem_write+0x288/0x474\n\nBy Error checking and checking valid values issue gets rectifies.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00016,"ranking_epss":0.03471,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/75e5fab7db0cecb6e16b22c34608f0b40a4c7cd1","https://git.kernel.org/stable/c/8d81d3b0ed3610d24191d24f8e9e20f6775f0cc5","https://git.kernel.org/stable/c/8f1512d78b5de928f4616a871e77b58fd546e651","https://git.kernel.org/stable/c/f5e61e3fe799ba2fda4320af23d26d28c3302045"],"published_time":"2025-10-07T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53641","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: hif_usb: fix memory leak of remain_skbs\n\nhif_dev->remain_skb is allocated and used exclusively in\nath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is\nprocessed and subsequently freed (in error paths) only during the next\ncall of ath9k_hif_usb_rx_stream().\n\nSo, if the urbs are deallocated between those two calls due to the device\ndeinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()\nis not called next time and the allocated remain_skb is leaked. Our local\nSyzkaller instance was able to trigger that.\n\nremain_skb makes sense when receiving two consecutive urbs which are\nlogically linked together, i.e. a specific data field from the first skb\nindicates a cached skb to be allocated, memcpy'd with some data and\nsubsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs\ndeallocation supposedly makes that link irrelevant so we need to free the\ncached skb in those cases.\n\nFix the leak by introducing a function to explicitly free remain_skb (if\nit is not NULL) when the rx urbs have been deallocated. remain_skb is NULL\nwhen it has not been allocated at all (hif_dev struct is kzalloced) or\nwhen it has been processed in next call to ath9k_hif_usb_rx_stream().\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02821,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/320d760a35273aa815d58b57e4fd9ba5279a3489","https://git.kernel.org/stable/c/59073060fe0950c6ecbe12bdc06469dcac62128d","https://git.kernel.org/stable/c/6719e3797ec52cd144c8a5ba8aaab36674800585","https://git.kernel.org/stable/c/7654cc03eb699297130b693ec34e25f77b17c947","https://git.kernel.org/stable/c/8f02d538878c9b1501f624595eb22ee4e5e0ff84","https://git.kernel.org/stable/c/9b9356a3014123f0ce4b50d9278c1265173150ab","https://git.kernel.org/stable/c/d9899318660791141ea6002fda5577b2c5d7386e","https://git.kernel.org/stable/c/f0931fc8f4b6847c72e170d2326861c0a081d680"],"published_time":"2025-10-07T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53642","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86: fix clear_user_rep_good() exception handling annotation\n\nThis code no longer exists in mainline, because it was removed in\ncommit d2c95f9d6802 (\"x86: don't use REP_GOOD or ERMS for user memory\nclearing\") upstream.\n\nHowever, rather than backport the full range of x86 memory clearing and\ncopying cleanups, fix the exception table annotation placement for the\nfinal 'rep movsb' in clear_user_rep_good(): rather than pointing at the\nactual instruction that did the user space access, it pointed to the\nregister move just before it.\n\nThat made sense from a code flow standpoint, but not from an actual\nusage standpoint: it means that if user access takes an exception, the\nexception handler won't actually find the instruction in the exception\ntables.\n\nAs a result, rather than fixing it up and returning -EFAULT, it would\nthen turn it into a kernel oops report instead, something like:\n\n    BUG: unable to handle page fault for address: 0000000020081000\n    #PF: supervisor write access in kernel mode\n    #PF: error_code(0x0002) - not-present page\n    ...\n    RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147\n    ...\n    Call Trace:\n      __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]\n      clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]\n      iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800\n      iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]\n      iomap_dio_iter fs/iomap/direct-io.c:440 [inline]\n      __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601\n      iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689\n      ext4_dio_read_iter fs/ext4/file.c:94 [inline]\n      ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145\n      call_read_iter include/linux/fs.h:2183 [inline]\n      do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733\n      do_iter_read+0x2f2/0x750 fs/read_write.c:796\n      vfs_readv+0xe5/0x150 fs/read_write.c:916\n      do_preadv+0x1b6/0x270 fs/read_write.c:1008\n      __do_sys_preadv2 fs/read_write.c:1070 [inline]\n      __se_sys_preadv2 fs/read_write.c:1061 [inline]\n      __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061\n      do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n      do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n      entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nwhich then looks like a filesystem bug rather than the incorrect\nexception annotation that it is.\n\n[ The alternative to this one-liner fix is to take the upstream series\n  that cleans this all up:\n\n    68674f94ffc9 (\"x86: don't use REP_GOOD or ERMS for small memory copies\")\n    20f3337d350c (\"x86: don't use REP_GOOD or ERMS for small memory clearing\")\n    adfcf4231b8c (\"x86: don't use REP_GOOD or ERMS for user memory copies\")\n  * d2c95f9d6802 (\"x86: don't use REP_GOOD or ERMS for user memory clearing\")\n    3639a535587d (\"x86: move stac/clac from user copy routines into callers\")\n    577e6a7fd50d (\"x86: inline the 'rep movs' in user copies for the FSRM case\")\n    8c9b6a88b7e2 (\"x86: improve on the non-rep 'clear_user' function\")\n    427fda2c8a49 (\"x86: improve on the non-rep 'copy_user' function\")\n  * e046fe5a36a9 (\"x86: set FSRS automatically on AMD CPUs that have FSRM\")\n    e1f2750edc4a (\"x86: remove 'zerorest' argument from __copy_user_nocache()\")\n    034ff37d3407 (\"x86: rewrite '__copy_user_nocache' function\")\n\n  with either the whole series or at a minimum the two marked commits\n  being needed to fix this issue ]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/76ce32682635fe907e0f8e64e039e773e5c7508f","https://git.kernel.org/stable/c/90510aed20a26e1a4dede4ef6b640e6a4122f38f","https://git.kernel.org/stable/c/b805d212c394f291f116b12c53401e7ba0c4d408","https://git.kernel.org/stable/c/e046fe5a36a970bc14fbfbcb2074a48776f6b671"],"published_time":"2025-10-07T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53643","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: don't access released socket during error recovery\n\nWhile the error recovery work is temporarily failing reconnect attempts,\nrunning the 'nvme list' command causes a kernel NULL pointer dereference\nby calling getsockname() with a released socket.\n\nDuring error recovery work, the nvme tcp socket is released and a new one\ncreated, so it is not safe to access the socket without proper check.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/76d54bf20cdcc1ed7569a89885e09636e9a8d71d","https://git.kernel.org/stable/c/d82f762db4776fa11de88018f0f5de2d5db72a72","https://git.kernel.org/stable/c/fe2d9e54165dadaa0d0cc3355c0be9c3e129fa0d"],"published_time":"2025-10-07T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53644","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: radio-shark: Add endpoint checks\n\nThe syzbot fuzzer was able to provoke a WARNING from the radio-shark2\ndriver:\n\n------------[ cut here ]------------\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504\nModules linked in:\nCPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504\nCode: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7\nRSP: 0018:ffffc90003876dd0 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000\nRDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac\nRBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001\nR13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200\nFS:  0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58\n usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387\n shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88\n...\n\nThe problem was caused by the fact that the driver does not check\nwhether the endpoints it uses are actually present and have the\nappropriate types.  This can be fixed by adding a simple check of\nthese endpoints (and similarly for the radio-shark driver).","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2b580d0f03c4fc00013cd08f9ed96b87a08fd0d9","https://git.kernel.org/stable/c/3ed6a312ac1e7278f92b1b3d95377b335ae21e89","https://git.kernel.org/stable/c/4c3057a1927fa0b9ed8948b6f3b56b4ff9fa63d3","https://git.kernel.org/stable/c/53764a17f5d8f0d00b13297d06b5e65fa844288b","https://git.kernel.org/stable/c/76e31045ba030e94e72105c01b2e98f543d175ac","https://git.kernel.org/stable/c/8a30dce9d7f70f8438956f6a01142b926c301334","https://git.kernel.org/stable/c/afd72825b4fcb7ae4015e1c93b054f4c37a25684","https://git.kernel.org/stable/c/b1bde4b4360c3d8a35504443efabd3243b802805"],"published_time":"2025-10-07T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53645","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Make bpf_refcount_acquire fallible for non-owning refs\n\nThis patch fixes an incorrect assumption made in the original\nbpf_refcount series [0], specifically that the BPF program calling\nbpf_refcount_acquire on some node can always guarantee that the node is\nalive. In that series, the patch adding failure behavior to rbtree_add\nand list_push_{front, back} breaks this assumption for non-owning\nreferences.\n\nConsider the following program:\n\n  n = bpf_kptr_xchg(&mapval, NULL);\n  /* skip error checking */\n\n  bpf_spin_lock(&l);\n  if(bpf_rbtree_add(&t, &n->rb, less)) {\n    bpf_refcount_acquire(n);\n    /* Failed to add, do something else with the node */\n  }\n  bpf_spin_unlock(&l);\n\nIt's incorrect to assume that bpf_refcount_acquire will always succeed in this\nscenario. bpf_refcount_acquire is being called in a critical section\nhere, but the lock being held is associated with rbtree t, which isn't\nnecessarily the lock associated with the tree that the node is already\nin. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop\nin it, the program has no ownership of the node's lifetime. Therefore\nthe node's refcount can be decr'd to 0 at any time after the failing\nrbtree_add. If this happens before the refcount_acquire above, the node\nmight be free'd, and regardless refcount_acquire will be incrementing a\n0 refcount.\n\nLater patches in the series exercise this scenario, resulting in the\nexpected complaint from the kernel (without this patch's changes):\n\n  refcount_t: addition on 0; use-after-free.\n  WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110\n  Modules linked in: bpf_testmod(O)\n  CPU: 1 PID: 207 Comm: test_progs Tainted: G           O       6.3.0-rc7-02231-g723de1a718a2-dirty #371\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:refcount_warn_saturate+0xbc/0x110\n  Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff <0f> 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7\n  RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082\n  RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000\n  RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680\n  RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7\n  R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388\n  R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048\n  FS:  00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n   <TASK>\n   bpf_refcount_acquire_impl+0xb5/0xc0\n\n  (rest of output snipped)\n\nThe patch addresses this by changing bpf_refcount_acquire_impl to use\nrefcount_inc_not_zero instead of refcount_inc and marking\nbpf_refcount_acquire KF_RET_NULL.\n\nFor owning references, though, we know the above scenario is not possible\nand thus that bpf_refcount_acquire will always succeed. Some verifier\nbookkeeping is added to track \"is input owning ref?\" for bpf_refcount_acquire\ncalls and return false from is_kfunc_ret_null for bpf_refcount_acquire on\nowning refs despite it being marked KF_RET_NULL.\n\nExisting selftests using bpf_refcount_acquire are modified where\nnecessary to NULL-check its return value.\n\n  [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7793fc3babe9fea908e57f7c187ea819f9fd7e95","https://git.kernel.org/stable/c/d906d1b940b9dbf0a3e821d6b32a51c369273d91"],"published_time":"2025-10-07T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53630","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Fix unpinning of pages when an access is present\n\nsyzkaller found that the calculation of batch_last_index should use\n'start_index' since at input to this function the batch is either empty or\nit has already been adjusted to cross any accesses so it will start at the\npoint we are unmapping from.\n\nGetting this wrong causes the unmap to run over the end of the pages\nwhich corrupts pages that were never mapped. In most cases this triggers\nthe num pinned debugging:\n\n  WARNING: CPU: 0 PID: 557 at drivers/iommu/iommufd/pages.c:294 __iopt_area_unfill_domain+0x152/0x560\n  Modules linked in:\n  CPU: 0 PID: 557 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755 #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:__iopt_area_unfill_domain+0x152/0x560\n  Code: d2 0f ff 44 8b 64 24 54 48 8b 44 24 48 31 ff 44 89 e6 48 89 44 24 38 e8 fc d3 0f ff 45 85 e4 0f 85 eb 01 00 00 e8 0e d2 0f ff <0f> 0b e8 07 d2 0f ff 48 8b 44 24 38 89 5c 24 58 89 18 8b 44 24 54\n  RSP: 0018:ffffc9000108baf0 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: 00000000ffffffff RCX: ffffffff821e3f85\n  RDX: 0000000000000000 RSI: ffff88800faf0000 RDI: 0000000000000002\n  RBP: ffffc9000108bd18 R08: 000000000003ca25 R09: 0000000000000014\n  R10: 000000000003ca00 R11: 0000000000000024 R12: 0000000000000004\n  R13: 0000000000000801 R14: 00000000000007ff R15: 0000000000000800\n  FS:  00007f3499ce1740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000020000243 CR3: 00000000179c2001 CR4: 0000000000770ef0\n  PKRU: 55555554\n  Call Trace:\n   <TASK>\n   iopt_area_unfill_domain+0x32/0x40\n   iopt_table_remove_domain+0x23f/0x4c0\n   iommufd_device_selftest_detach+0x3a/0x90\n   iommufd_selftest_destroy+0x55/0x70\n   iommufd_object_destroy_user+0xce/0x130\n   iommufd_destroy+0xa2/0xc0\n   iommufd_fops_ioctl+0x206/0x330\n   __x64_sys_ioctl+0x10e/0x160\n   do_syscall_64+0x3b/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nAlso add some useful WARN_ON sanity checks.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/70726ce4d898db57bfc4ae30ecd7da63b0dd0aa4","https://git.kernel.org/stable/c/727c28c1cef2bc013d2c8bb6c50e410a3882a04e"],"published_time":"2025-10-07T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53631","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: dell-sysman: Fix reference leak\n\nIf a duplicate attribute is found using kset_find_obj(),\na reference to that attribute is returned. This means\nthat we need to dispose it accordingly. Use kobject_put()\nto dispose the duplicate attribute in such a case.\n\nCompile-tested only.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6ced15ff1746006476f1407fe722911a45a7874d","https://git.kernel.org/stable/c/7295a996fdab7bf83dc3d4078fa8b139b8e0a1bf","https://git.kernel.org/stable/c/9d9e03bec147407826266580e7d6ec427241d859","https://git.kernel.org/stable/c/c5402011992bcc2b5614fe7fef24f9cdaec7473b","https://git.kernel.org/stable/c/d079a3e1ccdd183b75db4f5289be347980b45284"],"published_time":"2025-10-07T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53632","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Take RTNL lock when needed before calling xdp_set_features()\n\nHold RTNL lock when calling xdp_set_features() with a registered netdev,\nas the call triggers the netdev notifiers. This could happen when\nswitching from uplink rep to nic profile for example.\n\nThis resolves the following call trace:\n\nRTNL: assertion failed at net/core/dev.c (1953)\nWARNING: CPU: 6 PID: 112670 at net/core/dev.c:1953 call_netdevice_notifiers_info+0x7c/0x80\nModules linked in: sch_mqprio sch_mqprio_lib act_tunnel_key act_mirred act_skbedit cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress bonding ib_umad ip_gre rdma_ucm mlx5_vfio_pci ipip tunnel4 ip6_gre gre mlx5_ib vfio_pci vfio_pci_core vfio_iommu_type1 ib_uverbs vfio mlx5_core ib_ipoib geneve nf_tables ip6_tunnel tunnel6 iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs]\nCPU: 6 PID: 112670 Comm: devlink Not tainted 6.4.0-rc7_for_upstream_min_debug_2023_06_28_17_02 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:call_netdevice_notifiers_info+0x7c/0x80\nCode: 90 ff 80 3d 2d 6b f7 00 00 75 c5 ba a1 07 00 00 48 c7 c6 e4 ce 0b 82 48 c7 c7 c8 f4 04 82 c6 05 11 6b f7 00 01 e8 a4 7c 8e ff <0f> 0b eb a2 0f 1f 44 00 00 55 48 89 e5 41 54 48 83 e4 f0 48 83 ec\nRSP: 0018:ffff8882a21c3948 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffffffff82e6f880 RCX: 0000000000000027\nRDX: ffff88885f99b5c8 RSI: 0000000000000001 RDI: ffff88885f99b5c0\nRBP: 0000000000000028 R08: ffff88887ffabaa8 R09: 0000000000000003\nR10: ffff88887fecbac0 R11: ffff88887ff7bac0 R12: ffff8882a21c3968\nR13: ffff88811c018940 R14: 0000000000000000 R15: ffff8881274401a0\nFS:  00007fe141c81800(0000) GS:ffff88885f980000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f787c28b948 CR3: 000000014bcf3005 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ? __warn+0x79/0x120\n ? call_netdevice_notifiers_info+0x7c/0x80\n ? report_bug+0x17c/0x190\n ? handle_bug+0x3c/0x60\n ? exc_invalid_op+0x14/0x70\n ? asm_exc_invalid_op+0x16/0x20\n ? call_netdevice_notifiers_info+0x7c/0x80\n ? call_netdevice_notifiers_info+0x7c/0x80\n call_netdevice_notifiers+0x2e/0x50\n mlx5e_set_xdp_feature+0x21/0x50 [mlx5_core]\n mlx5e_nic_init+0xf1/0x1a0 [mlx5_core]\n mlx5e_netdev_init_profile+0x76/0x110 [mlx5_core]\n mlx5e_netdev_attach_profile+0x1f/0x90 [mlx5_core]\n mlx5e_netdev_change_profile+0x92/0x160 [mlx5_core]\n mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core]\n mlx5e_vport_rep_unload+0xaa/0xc0 [mlx5_core]\n __esw_offloads_unload_rep+0x52/0x60 [mlx5_core]\n mlx5_esw_offloads_rep_unload+0x52/0x70 [mlx5_core]\n esw_offloads_unload_rep+0x34/0x70 [mlx5_core]\n esw_offloads_disable+0x2b/0x90 [mlx5_core]\n mlx5_eswitch_disable_locked+0x1b9/0x210 [mlx5_core]\n mlx5_devlink_eswitch_mode_set+0xf5/0x630 [mlx5_core]\n ? devlink_get_from_attrs_lock+0x9e/0x110\n devlink_nl_cmd_eswitch_set_doit+0x60/0xe0\n genl_family_rcv_msg_doit.isra.0+0xc2/0x110\n genl_rcv_msg+0x17d/0x2b0\n ? devlink_get_from_attrs_lock+0x110/0x110\n ? devlink_nl_cmd_eswitch_get_doit+0x290/0x290\n ? devlink_pernet_pre_exit+0xf0/0xf0\n ? genl_family_rcv_msg_doit.isra.0+0x110/0x110\n netlink_rcv_skb+0x54/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x1f6/0x2c0\n netlink_sendmsg+0x232/0x4a0\n sock_sendmsg+0x38/0x60\n ? _copy_from_user+0x2a/0x60\n __sys_sendto+0x110/0x160\n ? __count_memcg_events+0x48/0x90\n ? handle_mm_fault+0x161/0x260\n ? do_user_addr_fault+0x278/0x6e0\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/16b7775ae4389dd1e885732ea610321c64284e5f","https://git.kernel.org/stable/c/72cc654970658e88a1cdea08f06b11c218efa4da"],"published_time":"2025-10-07T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53633","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\naccel/qaic: Fix a leak in map_user_pages()\n\nIf get_user_pages_fast() allocates some pages but not as many as we\nwanted, then the current code leaks those pages.  Call put_page() on\nthe pages before returning.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/73274c33d961f4aa0f968f763e2c9f4210b4f4a3","https://git.kernel.org/stable/c/cdcba752a3d48fbe6f05cf2c91ab9497c8daad0c"],"published_time":"2025-10-07T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53634","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, arm64: Fixed a BTI error on returning to patched function\n\nWhen BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump\nback to the instruction next to call site to call the patched function.\nFor BTI-enabled kernel, the instruction next to call site is usually\nPACIASP, in this case, it's safe to jump back with BLR. But when\nthe call site is not followed by a PACIASP or bti, a BTI exception\nis triggered.\n\nHere is a fault log:\n\n Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI\n CPU: 0 PID: 263 Comm: test_progs Tainted: GF\n Hardware name: linux,dummy-virt (DT)\n pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c)\n pc : bpf_fentry_test1+0xc/0x30\n lr : bpf_trampoline_6442573892_0+0x48/0x1000\n sp : ffff80000c0c3a50\n x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000\n x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050\n x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a\n x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101\n x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001\n x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001\n Kernel panic - not syncing: Unhandled exception\n CPU: 0 PID: 263 Comm: test_progs Tainted: GF\n Hardware name: linux,dummy-virt (DT)\n Call trace:\n  dump_backtrace+0xec/0x144\n  show_stack+0x24/0x7c\n  dump_stack_lvl+0x8c/0xb8\n  dump_stack+0x18/0x34\n  panic+0x1cc/0x3ec\n  __el0_error_handler_common+0x0/0x130\n  el1h_64_sync_handler+0x60/0xd0\n  el1h_64_sync+0x78/0x7c\n  bpf_fentry_test1+0xc/0x30\n  bpf_fentry_test1+0xc/0x30\n  bpf_prog_test_run_tracing+0xdc/0x2a0\n  __sys_bpf+0x438/0x22a0\n  __arm64_sys_bpf+0x30/0x54\n  invoke_syscall+0x78/0x110\n  el0_svc_common.constprop.0+0x6c/0x1d0\n  do_el0_svc+0x38/0xe0\n  el0_svc+0x30/0xd0\n  el0t_64_sync_handler+0x1ac/0x1b0\n  el0t_64_sync+0x1a0/0x1a4\n Kernel Offset: disabled\n CPU features: 0x0000,00034c24,f994fdab\n Memory Limit: none\n\nAnd the instruction next to call site of bpf_fentry_test1 is ADD,\nnot PACIASP:\n\n<bpf_fentry_test1>:\n\tbti     c\n\tnop\n\tnop\n\tadd     w0, w0, #0x1\n\tpaciasp\n\nFor BPF prog, JIT always puts a PACIASP after call site for BTI-enabled\nkernel, so there is no problem. To fix it, replace BLR with RET to bypass\nthe branch target check.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/738a96c4a8c36950803fdd27e7c30aca92dccefd","https://git.kernel.org/stable/c/8b9c64942ada229f52fe6f1b537a50f88b3c2673","https://git.kernel.org/stable/c/eabc166919d169e105263974991f52b0351e431a"],"published_time":"2025-10-07T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53635","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: fix wrong ct->timeout value\n\n(struct nf_conn)->timeout is an interval before the conntrack\nconfirmed.  After confirmed, it becomes a timestamp.\n\nIt is observed that timeout of an unconfirmed conntrack:\n- Set by calling ctnetlink_change_timeout(). As a result,\n  `nfct_time_stamp` was wrongly added to `ct->timeout` twice.\n- Get by calling ctnetlink_dump_timeout(). As a result,\n  `nfct_time_stamp` was wrongly subtracted.\n\nCall Trace:\n <TASK>\n dump_stack_lvl\n ctnetlink_dump_timeout\n __ctnetlink_glue_build\n ctnetlink_glue_build\n __nfqnl_enqueue_packet\n nf_queue\n nf_hook_slow\n ip_mc_output\n ? __pfx_ip_finish_output\n ip_send_skb\n ? __pfx_dst_output\n udp_send_skb\n udp_sendmsg\n ? __pfx_ip_generic_getfrag\n sock_sendmsg\n\nSeparate the 2 cases in:\n- Setting `ct->timeout` in __nf_ct_set_timeout().\n- Getting `ct->timeout` in ctnetlink_dump_timeout().\n\nPablo appends:\n\nUpdate ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag is\nset on, otherwise conntrack creation via ctnetlink breaks.\n\nNote that the problem described in this patch occurs since the\nintroduction of the nfnetlink_queue conntrack support, select a\nsufficiently old Fixes: tag for -stable kernel to pick up this fix.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/73db1b8f2bb6725b7391e85aab41fdf592b3c0c1","https://git.kernel.org/stable/c/80c5ba0078e20d926d11d0778f9a43902664ebf0","https://git.kernel.org/stable/c/f612ae1ab4793701caf39386fb3b7f4b3ef44e48","https://git.kernel.org/stable/c/ff5e4ac8dd7be7f1faba955c5779a68571eeb0f8"],"published_time":"2025-10-07T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53636","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nclk: microchip: fix potential UAF in auxdev release callback\n\nSimilar to commit 1c11289b34ab (\"peci: cpu: Fix use-after-free in\nadev_release()\"), the auxiliary device is not torn down in the correct\norder. If auxiliary_device_add() fails, the release callback will be\ncalled twice, resulting in a UAF. Due to timing, the auxdev code in this\ndriver \"took inspiration\" from the aforementioned commit, and thus its\nbugs too!\n\nMoving auxiliary_device_uninit() to the unregister callback instead\navoids the issue.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00016,"ranking_epss":0.03471,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5b4052aa956e11bcd19e50ca559eb38dcb46201b","https://git.kernel.org/stable/c/7455b7007b9e93bcc2bc9c1c6c73a228e3152069","https://git.kernel.org/stable/c/934406b2d42eaf3fc57f5546cc68ff7ab9680bb3","https://git.kernel.org/stable/c/d7d6dacf39ed102d7667721ca1700022c9c8b11a"],"published_time":"2025-10-07T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53637","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: ov772x: Fix memleak in ov772x_probe()\n\nA memory leak was reported when testing ov772x with bpf mock device:\n\nAssertionError: unreferenced object 0xffff888109afa7a8 (size 8):\n  comm \"python3\", pid 279, jiffies 4294805921 (age 20.681s)\n  hex dump (first 8 bytes):\n    80 22 88 15 81 88 ff ff                          .\"......\n  backtrace:\n    [<000000009990b438>] __kmalloc_node+0x44/0x1b0\n    [<000000009e32f7d7>] kvmalloc_node+0x34/0x180\n    [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev]\n    [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x]\n    [<000000003f0d225e>] i2c_device_probe+0x28d/0x680\n    [<00000000e0b6db89>] really_probe+0x17c/0x3f0\n    [<000000001b19fcee>] __driver_probe_device+0xe3/0x170\n    [<0000000048370519>] driver_probe_device+0x49/0x120\n    [<000000005ead07a0>] __device_attach_driver+0xf7/0x150\n    [<0000000043f452b8>] bus_for_each_drv+0x114/0x180\n    [<00000000358e5596>] __device_attach+0x1e5/0x2d0\n    [<0000000043f83c5d>] bus_probe_device+0x126/0x140\n    [<00000000ee0f3046>] device_add+0x810/0x1130\n    [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0\n    [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110\n    [<00000000a9f2159d>] of_i2c_notify+0x100/0x160\nunreferenced object 0xffff888119825c00 (size 256):\n  comm \"python3\", pid 279, jiffies 4294805921 (age 20.681s)\n  hex dump (first 32 bytes):\n    00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff  .........^......\n    10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff  .\\.......\\......\n  backtrace:\n    [<000000009990b438>] __kmalloc_node+0x44/0x1b0\n    [<000000009e32f7d7>] kvmalloc_node+0x34/0x180\n    [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev]\n    [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev]\n    [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x]\n    [<000000003f0d225e>] i2c_device_probe+0x28d/0x680\n    [<00000000e0b6db89>] really_probe+0x17c/0x3f0\n    [<000000001b19fcee>] __driver_probe_device+0xe3/0x170\n    [<0000000048370519>] driver_probe_device+0x49/0x120\n    [<000000005ead07a0>] __device_attach_driver+0xf7/0x150\n    [<0000000043f452b8>] bus_for_each_drv+0x114/0x180\n    [<00000000358e5596>] __device_attach+0x1e5/0x2d0\n    [<0000000043f83c5d>] bus_probe_device+0x126/0x140\n    [<00000000ee0f3046>] device_add+0x810/0x1130\n    [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0\n    [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110\n\nThe reason is that if priv->hdl.error is set, ov772x_probe() jumps to the\nerror_mutex_destroy without doing v4l2_ctrl_handler_free(), and all\nresources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std()\nare leaked.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1da495101ef7507eb4f4b1dbec2874d740eff251","https://git.kernel.org/stable/c/448ce1cd50387b1345ec14eb191ef05f7afc2a26","https://git.kernel.org/stable/c/7485edb2b6ca5960205c0a49bedfd09bba30e521","https://git.kernel.org/stable/c/ac93f8ac66e60227bed42d5a023f0e6c15b52c0a","https://git.kernel.org/stable/c/c86d760c1c6855a6131e78d0ddacc48c79324ac3","https://git.kernel.org/stable/c/cc3b6011d7a9f149489eb9420c6305a779162c57","https://git.kernel.org/stable/c/dfaafeb8e9537969e8dba75491f732478c7fa9d6"],"published_time":"2025-10-07T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53623","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/swap: fix swap_info_struct race between swapoff and get_swap_pages()\n\nThe si->lock must be held when deleting the si from the available list. \nOtherwise, another thread can re-add the si to the available list, which\ncan lead to memory corruption.  The only place we have found where this\nhappens is in the swapoff path.  This case can be described as below:\n\ncore 0                       core 1\nswapoff\n\ndel_from_avail_list(si)      waiting\n\ntry lock si->lock            acquire swap_avail_lock\n                             and re-add si into\n                             swap_avail_head\n\nacquire si->lock but missing si already being added again, and continuing\nto clear SWP_WRITEOK, etc.\n\nIt can be easily found that a massive warning messages can be triggered\ninside get_swap_pages() by some special cases, for example, we call\nmadvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,\nrun much swapon-swapoff operations (e.g.  stress-ng-swap).\n\nHowever, in the worst case, panic can be caused by the above scene.  In\nswapoff(), the memory used by si could be kept in swap_info[] after\nturning off a swap.  This means memory corruption will not be caused\nimmediately until allocated and reset for a new swap in the swapon path. \nA panic message caused: (with CONFIG_PLIST_DEBUG enabled)\n\n------------[ cut here ]------------\ntop: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a\nprev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d\nnext: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a\nWARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70\nModules linked in: rfkill(E) crct10dif_ce(E)...\nCPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+\nHardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015\npstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)\npc : plist_check_prev_next_node+0x50/0x70\nlr : plist_check_prev_next_node+0x50/0x70\nsp : ffff0018009d3c30\nx29: ffff0018009d3c40 x28: ffff800011b32a98\nx27: 0000000000000000 x26: ffff001803908000\nx25: ffff8000128ea088 x24: ffff800011b32a48\nx23: 0000000000000028 x22: ffff001800875c00\nx21: ffff800010f9e520 x20: ffff001800875c00\nx19: ffff001800fdc6e0 x18: 0000000000000030\nx17: 0000000000000000 x16: 0000000000000000\nx15: 0736076307640766 x14: 0730073007380731\nx13: 0736076307640766 x12: 0730073007380731\nx11: 000000000004058d x10: 0000000085a85b76\nx9 : ffff8000101436e4 x8 : ffff800011c8ce08\nx7 : 0000000000000000 x6 : 0000000000000001\nx5 : ffff0017df9ed338 x4 : 0000000000000001\nx3 : ffff8017ce62a000 x2 : ffff0017df9ed340\nx1 : 0000000000000000 x0 : 0000000000000000\nCall trace:\n plist_check_prev_next_node+0x50/0x70\n plist_check_head+0x80/0xf0\n plist_add+0x28/0x140\n add_to_avail_list+0x9c/0xf0\n _enable_swap_info+0x78/0xb4\n __do_sys_swapon+0x918/0xa10\n __arm64_sys_swapon+0x20/0x30\n el0_svc_common+0x8c/0x220\n do_el0_svc+0x2c/0x90\n el0_svc+0x1c/0x30\n el0_sync_handler+0xa8/0xb0\n el0_sync+0x148/0x180\nirq event stamp: 2082270\n\nNow, si->lock locked before calling 'del_from_avail_list()' to make sure\nother thread see the si had been deleted and SWP_WRITEOK cleared together,\nwill not reinsert again.\n\nThis problem exists in versions after stable 5.10.y.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00014,"ranking_epss":0.02335,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/111a79d9b92f0a679fe300ccd3119ae9741f3d54","https://git.kernel.org/stable/c/4bdf1514b4268d29360ba9e43becdd49955bc7ae","https://git.kernel.org/stable/c/6fe7d6b992113719e96744d974212df3fcddc76c","https://git.kernel.org/stable/c/85cc118ce6f1a627901b6db50c9d01f2ad78cdbf","https://git.kernel.org/stable/c/a55f268abdb74ac5633b75a09fefb58458e9d2a2","https://git.kernel.org/stable/c/b9927d3a60ca9ed35625470888629c074e687ba0","https://git.kernel.org/stable/c/e7bba7ddb4318d5ea939c8db747c2c2780ab66f4","https://git.kernel.org/stable/c/ea8c42b3b6d95ced3a4f555f04686d00ef0bb206"],"published_time":"2025-10-07T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53624","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_fq: fix integer overflow of \"credit\"\n\nif sch_fq is configured with \"initial quantum\" having values greater than\nINT_MAX, the first assignment of \"credit\" does signed integer overflow to\na very negative value.\nIn this situation, the syzkaller script provided by Cristoph triggers the\nCPU soft-lockup warning even with few sockets. It's not an infinite loop,\nbut \"credit\" wasn't probably meant to be minus 2Gb for each new flow.\nCapping \"initial quantum\" to INT_MAX proved to fix the issue.\n\nv2: validation of \"initial quantum\" is done in fq_policy, instead of open\n    coding in fq_change() _ suggested by Jakub Kicinski","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2322462d6f9ad4874f4e3c63df3b5cc00cb1acbd","https://git.kernel.org/stable/c/4b8a05e3801661a0438fcd0cdef181030d966a5a","https://git.kernel.org/stable/c/4fbefeab88c6e79753a25099d455d3d59d2946b4","https://git.kernel.org/stable/c/7041101ff6c3073fd8f2e99920f535b111c929cb","https://git.kernel.org/stable/c/85f24cb2f10b2b0f2882e5786a09b4790bb3a0ad","https://git.kernel.org/stable/c/d0b43125ec892aeb1b03e5df5aab595097da225a"],"published_time":"2025-10-07T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53625","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gvt: fix vgpu debugfs clean in remove\n\nCheck carefully on root debugfs available when destroying vgpu,\ne.g in remove case drm minor's debugfs root might already be destroyed,\nwhich led to kernel oops like below.\n\nConsole: switching to colour dummy device 80x25\ni915 0000:00:02.0: MDEV: Unregistering\nintel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14\nBUG: kernel NULL pointer dereference, address: 0000000000000150\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6\nHardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022\nRIP: 0010:__lock_acquire+0x5e2/0x1f90\nCode: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0\nRSP: 0018:ffff9f770274f948 EFLAGS: 00010046\nRAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000\nR13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n lock_acquire+0xbf/0x2b0\n ? simple_recursive_removal+0xa5/0x2b0\n ? lock_release+0x13d/0x2d0\n down_write+0x2a/0xd0\n ? simple_recursive_removal+0xa5/0x2b0\n simple_recursive_removal+0xa5/0x2b0\n ? start_creating.part.0+0x110/0x110\n ? _raw_spin_unlock+0x29/0x40\n debugfs_remove+0x40/0x60\n intel_gvt_debugfs_remove_vgpu+0x15/0x30 [kvmgt]\n intel_gvt_destroy_vgpu+0x60/0x100 [kvmgt]\n intel_vgpu_release_dev+0xe/0x20 [kvmgt]\n device_release+0x30/0x80\n kobject_put+0x79/0x1b0\n device_release_driver_internal+0x1b8/0x230\n bus_remove_device+0xec/0x160\n device_del+0x189/0x400\n ? up_write+0x9c/0x1b0\n ? mdev_device_remove_common+0x60/0x60 [mdev]\n mdev_device_remove_common+0x22/0x60 [mdev]\n mdev_device_remove_cb+0x17/0x20 [mdev]\n device_for_each_child+0x56/0x80\n mdev_unregister_parent+0x5a/0x81 [mdev]\n intel_gvt_clean_device+0x2d/0xe0 [kvmgt]\n intel_gvt_driver_remove+0x2e/0xb0 [i915]\n i915_driver_remove+0xac/0x100 [i915]\n i915_pci_remove+0x1a/0x30 [i915]\n pci_device_remove+0x31/0xa0\n device_release_driver_internal+0x1b8/0x230\n unbind_store+0xd8/0x100\n kernfs_fop_write_iter+0x156/0x210\n vfs_write+0x236/0x4a0\n ksys_write+0x61/0xd0\n do_syscall_64+0x55/0x80\n ? find_held_lock+0x2b/0x80\n ? lock_release+0x13d/0x2d0\n ? up_read+0x17/0x20\n ? lock_is_held_type+0xe3/0x140\n ? asm_exc_page_fault+0x22/0x30\n ? lockdep_hardirqs_on+0x7d/0x100\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033:0x7fc9b2c9e0c4\nCode: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48\nRSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc9b2c9e0c4\nRDX: 000000000000000d RSI: 0000559f8b5f48a0 RDI: 0000000000000001\nRBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30\nR10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d\nR13: 00007fc9b2d77780 R14: 000000000000000d R15: 00007fc9b2d72a00\n </TASK>\nModules linked in: sunrpc intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ee1004 igbvf rapl vfat fat intel_cstate intel_uncore pktcdvd i2c_i801 pcspkr wmi_bmof i2c_smbus acpi_pad vfio_pci vfio_pci_core vfio_virqfd zram fuse dm\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/44c0e07e3972e3f2609d69ad873d4f342f8a68ec","https://git.kernel.org/stable/c/704f3384f322b40ba24d958473edfb1c9750c8fd","https://git.kernel.org/stable/c/af90f8b36d78544433a48a3eda6a5faeafacd0a1","https://git.kernel.org/stable/c/f5a9bbf962e2c4b1d9addbfaf16d7ffcc2f63bde","https://git.kernel.org/stable/c/ffa83fba2a2ce8010eb106c779378cb3013362c7"],"published_time":"2025-10-07T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53626","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix possible double unlock when moving a directory","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/020166bc6669ca9fb267ebd96bd88c4fb64a5d46","https://git.kernel.org/stable/c/1c93c42c7bb23057bde8a0a2ab834927ff64d20c","https://git.kernel.org/stable/c/43ce288ab5d7274a4a141d7f5e3ed2ab7b41f8a2","https://git.kernel.org/stable/c/70e42feab2e20618ddd0cbfc4ab4b08628236ecd","https://git.kernel.org/stable/c/c16cbd8233d6c58fc488545393e49b5d55729990","https://git.kernel.org/stable/c/e71eb4dca41f0f36823724ced0406bb2dbdd5506"],"published_time":"2025-10-07T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53627","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.list\n\nWhen freeing slots in function slot_complete_v3_hw(), it is possible that\nsas_dev.list is being traversed elsewhere, and it may trigger a NULL\npointer exception, such as follows:\n\n==>cq thread                    ==>scsi_eh_6\n\n                                ==>scsi_error_handler()\n\t\t\t\t  ==>sas_eh_handle_sas_errors()\n\t\t\t\t    ==>sas_scsi_find_task()\n\t\t\t\t      ==>lldd_abort_task()\n==>slot_complete_v3_hw()              ==>hisi_sas_abort_task()\n  ==>hisi_sas_slot_task_free()\t        ==>dereg_device_v3_hw()\n    ==>list_del_init()        \t\t  ==>list_for_each_entry_safe()\n\n[ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32\n[ 7165.434926] sas: trying to find task 0x00000000769b5ba5\n[ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5\n[ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted\n[ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored\n[ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored\n[ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored\n[ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored\n[ 7165.434976] Mem abort info:\n[ 7165.434982]   ESR = 0x96000004\n[ 7165.434991]   Exception class = DABT (current EL), IL = 32 bits\n[ 7165.434992]   SET = 0, FnV = 0\n[ 7165.434993]   EA = 0, S1PTW = 0\n[ 7165.434994] Data abort info:\n[ 7165.434994]   ISV = 0, ISS = 0x00000004\n[ 7165.434995]   CM = 0, WnR = 0\n[ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2\n[ 7165.434998] [0000000000000000] pgd=0000000000000000\n[ 7165.435003] Internal error: Oops: 96000004 [#1] SMP\n[ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5)\n[ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO)\n[ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw]\n[ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw]\n[ 7165.485247] sp : ffff00001d623bc0\n[ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508\n[ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8\n[ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8\n[ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00\n[ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8\n[ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff\n[ 7165.520276] x17: 0000000000000000 x16: 0000000000000000\n[ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8\n[ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067\n[ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0\n[ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00\n[ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00\n[ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e\n[ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000\n[ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e\n[ 7165.567872] Call trace:\n[ 7165.570309]  dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw]\n[ 7165.575775]  hisi_sas_abort_task+0x248/0x358 [hisi_sas_main]\n[ 7165.581415]  sas_eh_handle_sas_errors+0x258/0x8e0 [libsas]\n[ 7165.586876]  sas_scsi_recover_host+0x134/0x458 [libsas]\n[ 7165.592082]  scsi_error_handler+0xb4/0x488\n[ 7165.596163]  kthread+0x134/0x138\n[ 7165.599380]  ret_from_fork+0x10/0x18\n[ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021)\n[ 7165.609004] kernel fault(0x1) notification starting on CPU 75\n[ 7165.700728] ---[ end trace fc042cbbea224efc ]---\n[ 7165.705326] Kernel panic - not syncing: Fatal exception\n\nTo fix the issue, grab sas_dev lock when traversing the members of\nsas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoid\nconcurrency of adding and deleting member. When \n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6e2a40b3a332ea84079983be21c944de8ddbc4f3","https://git.kernel.org/stable/c/71fb36b5ff113a7674710b9d6063241eada84ff7"],"published_time":"2025-10-07T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53628","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: drop gfx_v11_0_cp_ecc_error_irq_funcs\n\nThe gfx.cp_ecc_error_irq is retired in gfx11. In gfx_v11_0_hw_fini still\nuse amdgpu_irq_put to disable this interrupt, which caused the call trace\nin this function.\n\n[  102.873958] Call Trace:\n[  102.873959]  <TASK>\n[  102.873961]  gfx_v11_0_hw_fini+0x23/0x1e0 [amdgpu]\n[  102.874019]  gfx_v11_0_suspend+0xe/0x20 [amdgpu]\n[  102.874072]  amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu]\n[  102.874122]  amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]\n[  102.874172]  amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu]\n[  102.874223]  amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu]\n[  102.874321]  amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]\n[  102.874375]  process_one_work+0x21f/0x3f0\n[  102.874377]  worker_thread+0x200/0x3e0\n[  102.874378]  ? process_one_work+0x3f0/0x3f0\n[  102.874379]  kthread+0xfd/0x130\n[  102.874380]  ? kthread_complete_and_exit+0x20/0x20\n[  102.874381]  ret_from_fork+0x22/0x30\n\nv2:\n- Handle umc and gfx ras cases in separated patch\n- Retired the gfx_v11_0_cp_ecc_error_irq_funcs in gfx11\n\nv3:\n- Improve the subject and code comments\n- Add judgment on gfx11 in the function of amdgpu_gfx_ras_late_init\n\nv4:\n- Drop the define of CP_ME1_PIPE_INST_ADDR_INTERVAL and\nSET_ECC_ME_PIPE_STATE which using in gfx_v11_0_set_cp_ecc_error_state\n- Check cp_ecc_error_irq.funcs rather than ip version for a more\nsustainable life\n\nv5:\n- Simplify judgment conditions","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/31b07aec4a2bdcab00770ea3a18efe49734ce153","https://git.kernel.org/stable/c/720b47229a5b24061d1c2e29ddb6043a59178d79"],"published_time":"2025-10-07T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53629","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs: dlm: fix use after free in midcomms commit\n\nWhile working on processing dlm message in softirq context I experienced\nthe following KASAN use-after-free warning:\n\n[  151.760477] ==================================================================\n[  151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0\n[  151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347\n\n[  151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828\n[  151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014\n[  151.768726] Call Trace:\n[  151.769277]  <TASK>\n[  151.769748]  dump_stack_lvl+0x5b/0x86\n[  151.770556]  print_report+0x180/0x4c8\n[  151.771378]  ? kasan_complete_mode_report_info+0x7c/0x1e0\n[  151.772241]  ? dlm_midcomms_commit_mhandle+0x19d/0x4b0\n[  151.773069]  kasan_report+0x93/0x1a0\n[  151.773668]  ? dlm_midcomms_commit_mhandle+0x19d/0x4b0\n[  151.774514]  __asan_load4+0x7e/0xa0\n[  151.775089]  dlm_midcomms_commit_mhandle+0x19d/0x4b0\n[  151.775890]  ? create_message.isra.29.constprop.64+0x57/0xc0\n[  151.776770]  send_common+0x19f/0x1b0\n[  151.777342]  ? remove_from_waiters+0x60/0x60\n[  151.778017]  ? lock_downgrade+0x410/0x410\n[  151.778648]  ? __this_cpu_preempt_check+0x13/0x20\n[  151.779421]  ? rcu_lockdep_current_cpu_online+0x88/0xc0\n[  151.780292]  _convert_lock+0x46/0x150\n[  151.780893]  convert_lock+0x7b/0xc0\n[  151.781459]  dlm_lock+0x3ac/0x580\n[  151.781993]  ? 0xffffffffc0540000\n[  151.782522]  ? torture_stop+0x120/0x120 [dlm_locktorture]\n[  151.783379]  ? dlm_scan_rsbs+0xa70/0xa70\n[  151.784003]  ? preempt_count_sub+0xd6/0x130\n[  151.784661]  ? is_module_address+0x47/0x70\n[  151.785309]  ? torture_stop+0x120/0x120 [dlm_locktorture]\n[  151.786166]  ? 0xffffffffc0540000\n[  151.786693]  ? lockdep_init_map_type+0xc3/0x360\n[  151.787414]  ? 0xffffffffc0540000\n[  151.787947]  torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture]\n[  151.789004]  ? torture_stop+0x120/0x120 [dlm_locktorture]\n[  151.789858]  ? 0xffffffffc0540000\n[  151.790392]  ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture]\n[  151.791347]  ? delay_tsc+0x94/0xc0\n[  151.791898]  torture_ex_iter+0xc3/0xea [dlm_locktorture]\n[  151.792735]  ? torture_start+0x30/0x30 [dlm_locktorture]\n[  151.793606]  lock_torture+0x177/0x270 [dlm_locktorture]\n[  151.794448]  ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture]\n[  151.795539]  ? lock_torture_stats+0x80/0x80 [dlm_locktorture]\n[  151.796476]  ? do_raw_spin_lock+0x11e/0x1e0\n[  151.797152]  ? mark_held_locks+0x34/0xb0\n[  151.797784]  ? _raw_spin_unlock_irqrestore+0x30/0x70\n[  151.798581]  ? __kthread_parkme+0x79/0x110\n[  151.799246]  ? trace_preempt_on+0x2a/0xf0\n[  151.799902]  ? __kthread_parkme+0x79/0x110\n[  151.800579]  ? preempt_count_sub+0xd6/0x130\n[  151.801271]  ? __kasan_check_read+0x11/0x20\n[  151.801963]  ? __kthread_parkme+0xec/0x110\n[  151.802630]  ? lock_torture_stats+0x80/0x80 [dlm_locktorture]\n[  151.803569]  kthread+0x192/0x1d0\n[  151.804104]  ? kthread_complete_and_exit+0x30/0x30\n[  151.804881]  ret_from_fork+0x1f/0x30\n[  151.805480]  </TASK>\n\n[  151.806111] Allocated by task 1347:\n[  151.806681]  kasan_save_stack+0x26/0x50\n[  151.807308]  kasan_set_track+0x25/0x30\n[  151.807920]  kasan_save_alloc_info+0x1e/0x30\n[  151.808609]  __kasan_slab_alloc+0x63/0x80\n[  151.809263]  kmem_cache_alloc+0x1ad/0x830\n[  151.809916]  dlm_allocate_mhandle+0x17/0x20\n[  151.810590]  dlm_midcomms_get_mhandle+0x96/0x260\n[  151.811344]  _create_message+0x95/0x180\n[  151.811994]  create_message.isra.29.constprop.64+0x57/0xc0\n[  151.812880]  send_common+0x129/0x1b0\n[  151.813467]  _convert_lock+0x46/0x150\n[  151.814074]  convert_lock+0x7b/0xc0\n[  151.814648]  dlm_lock+0x3ac/0x580\n[  151.815199]  torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture]\n[  151.816258]  torture_ex_iter+0xc3/0xea [dlm_locktorture]\n[  151.817129]  lock_t\n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00012,"ranking_epss":0.01866,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/724b6bab0d75f1dc01fdfbf7fe8d4217a5cb90ba","https://git.kernel.org/stable/c/a2de9f9b686c71b4fa3663ae374f5f643c46a446","https://git.kernel.org/stable/c/a3b0e9ac3c2447008db942d51f593841d8329e99"],"published_time":"2025-10-07T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53617","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: aspeed: socinfo: Add kfree for kstrdup\n\nAdd kfree() in the later error handling in order to avoid memory leak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6e6d847a8ce18ab2fbec4f579f682486a82d2c6b","https://git.kernel.org/stable/c/b662856b71343d9e731c1cd4bbe54758c7791abb","https://git.kernel.org/stable/c/d9a5ad4477d2a11e9b03f00c52694451e9332228","https://git.kernel.org/stable/c/dfb9676ed25be25ca7cd198d0f0e093b76b7bc7f"],"published_time":"2025-10-07T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53618","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject invalid reloc tree root keys with stack dump\n\n[BUG]\nSyzbot reported a crash that an ASSERT() got triggered inside\nprepare_to_merge().\n\nThat ASSERT() makes sure the reloc tree is properly pointed back by its\nsubvolume tree.\n\n[CAUSE]\nAfter more debugging output, it turns out we had an invalid reloc tree:\n\n  BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17\n\nNote the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,\nQUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.\n\nBut reloc trees can only exist for subvolumes, as for non-subvolume\ntrees, we just COW the involved tree block, no need to create a reloc\ntree since those tree blocks won't be shared with other trees.\n\nOnly subvolumes tree can share tree blocks with other trees (thus they\nhave BTRFS_ROOT_SHAREABLE flag).\n\nThus this new debug output proves my previous assumption that corrupted\non-disk data can trigger that ASSERT().\n\n[FIX]\nBesides the dedicated fix and the graceful exit, also let tree-checker to\ncheck such root keys, to make sure reloc trees can only exist for subvolumes.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/314135b7bae9618a317874ae195272682cf2d5d4","https://git.kernel.org/stable/c/3ae93b316ca4b8b3c33798ef1d210355f2fb9318","https://git.kernel.org/stable/c/6ebcd021c92b8e4b904552e4d87283032100796d","https://git.kernel.org/stable/c/84256e00eeca73c529fc6196e478cc89b8098157"],"published_time":"2025-10-07T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53619","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: Avoid nf_ct_helper_hash uses after free\n\nIf nf_conntrack_init_start() fails (for example due to a\nregister_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()\nclean-up path frees the nf_ct_helper_hash map.\n\nWhen built with NF_CONNTRACK=y, further netfilter modules (e.g:\nnetfilter_conntrack_ftp) can still be loaded and call\nnf_conntrack_helpers_register(), independently of whether nf_conntrack\ninitialized correctly. This accesses the nf_ct_helper_hash dangling\npointer and causes a uaf, possibly leading to random memory corruption.\n\nThis patch guards nf_conntrack_helper_register() from accessing a freed\nor uninitialized nf_ct_helper_hash pointer and fixes possible\nuses-after-free when loading a conntrack module.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04358,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/00716f25f9697d02a0d9bd622575c7c7321ba3d0","https://git.kernel.org/stable/c/05561f822f27b9fa88fa5504ddec34bf38833034","https://git.kernel.org/stable/c/4ee69c91cb8f9ca144bc0861969e5a1a3c6152a7","https://git.kernel.org/stable/c/61c7a5256543ae7d24cd9d21853d514c8632e1e9","https://git.kernel.org/stable/c/6eef7a2b933885a17679eb8ed0796ddf0ee5309b","https://git.kernel.org/stable/c/6f03ce2f1abcb9f9d0511e3659ca6eb60e39f566","https://git.kernel.org/stable/c/8289d422f5e484efe4a565fe18e862ecd621c175","https://git.kernel.org/stable/c/fce5cc7cbd4b92f979bf02c9ec5fb69aaeba92d7"],"published_time":"2025-10-07T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53620","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix soft lockup in status_resync\n\nstatus_resync() will calculate 'curr_resync - recovery_active' to show\nuser a progress bar like following:\n\n[============>........]  resync = 61.4%\n\n'curr_resync' and 'recovery_active' is updated in md_do_sync(), and\nstatus_resync() can read them concurrently, hence it's possible that\n'curr_resync - recovery_active' can overflow to a huge number. In this\ncase status_resync() will be stuck in the loop to print a large amount\nof '=', which will end up soft lockup.\n\nFix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,\nthis way resync in progress will be reported to user.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0001,"ranking_epss":0.01008,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/23309704e90859af2662bedc44101e6d1d2ece7e","https://git.kernel.org/stable/c/6efddf1e32e2a264694766ca485a4f5e04ee82a7","https://git.kernel.org/stable/c/b4acb6c3ede88d6b7d33742a09e63cfce5e7fb69"],"published_time":"2025-10-07T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53621","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmemcontrol: ensure memcg acquired by id is properly set up\n\nIn the eviction recency check, we attempt to retrieve the memcg to which\nthe folio belonged when it was evicted, by the memcg id stored in the\nshadow entry.  However, there is a chance that the retrieved memcg is not\nthe original memcg that has been killed, but a new one which happens to\nhave the same id.\n\nThis is a somewhat unfortunate, but acceptable and rare inaccuracy in the\nheuristics.  However, if we retrieve this new memcg between its allocation\nand when it is properly attached to the memcg hierarchy, we could run into\nthe following NULL pointer exception during the memcg hierarchy traversal\ndone in mem_cgroup_get_nr_swap_pages():\n\n[ 155757.793456] BUG: kernel NULL pointer dereference, address: 00000000000000c0\n[ 155757.807568] #PF: supervisor read access in kernel mode\n[ 155757.818024] #PF: error_code(0x0000) - not-present page\n[ 155757.828482] PGD 401f77067 P4D 401f77067 PUD 401f76067 PMD 0\n[ 155757.839985] Oops: 0000 [#1] SMP\n[ 155757.887870] RIP: 0010:mem_cgroup_get_nr_swap_pages+0x3d/0xb0\n[ 155757.899377] Code: 29 19 4a 02 48 39 f9 74 63 48 8b 97 c0 00 00 00 48 8b b7 58 02 00 00 48 2b b7 c0 01 00 00 48 39 f0 48 0f 4d c6 48 39 d1 74 42 <48> 8b b2 c0 00 00 00 48 8b ba 58 02 00 00 48 2b ba c0 01 00 00 48\n[ 155757.937125] RSP: 0018:ffffc9002ecdfbc8 EFLAGS: 00010286\n[ 155757.947755] RAX: 00000000003a3b1c RBX: 000007ffffffffff RCX: ffff888280183000\n[ 155757.962202] RDX: 0000000000000000 RSI: 0007ffffffffffff RDI: ffff888bbc2d1000\n[ 155757.976648] RBP: 0000000000000001 R08: 000000000000000b R09: ffff888ad9cedba0\n[ 155757.991094] R10: ffffea0039c07900 R11: 0000000000000010 R12: ffff888b23a7b000\n[ 155758.005540] R13: 0000000000000000 R14: ffff888bbc2d1000 R15: 000007ffffc71354\n[ 155758.019991] FS:  00007f6234c68640(0000) GS:ffff88903f9c0000(0000) knlGS:0000000000000000\n[ 155758.036356] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 155758.048023] CR2: 00000000000000c0 CR3: 0000000a83eb8004 CR4: 00000000007706e0\n[ 155758.062473] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 155758.076924] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 155758.091376] PKRU: 55555554\n[ 155758.096957] Call Trace:\n[ 155758.102016]  <TASK>\n[ 155758.106502]  ? __die+0x78/0xc0\n[ 155758.112793]  ? page_fault_oops+0x286/0x380\n[ 155758.121175]  ? exc_page_fault+0x5d/0x110\n[ 155758.129209]  ? asm_exc_page_fault+0x22/0x30\n[ 155758.137763]  ? mem_cgroup_get_nr_swap_pages+0x3d/0xb0\n[ 155758.148060]  workingset_test_recent+0xda/0x1b0\n[ 155758.157133]  workingset_refault+0xca/0x1e0\n[ 155758.165508]  filemap_add_folio+0x4d/0x70\n[ 155758.173538]  page_cache_ra_unbounded+0xed/0x190\n[ 155758.182919]  page_cache_sync_ra+0xd6/0x1e0\n[ 155758.191738]  filemap_read+0x68d/0xdf0\n[ 155758.199495]  ? mlx5e_napi_poll+0x123/0x940\n[ 155758.207981]  ? __napi_schedule+0x55/0x90\n[ 155758.216095]  __x64_sys_pread64+0x1d6/0x2c0\n[ 155758.224601]  do_syscall_64+0x3d/0x80\n[ 155758.232058]  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 155758.242473] RIP: 0033:0x7f62c29153b5\n[ 155758.249938] Code: e8 48 89 75 f0 89 7d f8 48 89 4d e0 e8 b4 e6 f7 ff 41 89 c0 4c 8b 55 e0 48 8b 55 e8 48 8b 75 f0 8b 7d f8 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 45 f8 e8 e7 e6 f7 ff 48 8b\n[ 155758.288005] RSP: 002b:00007f6234c5ffd0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011\n[ 155758.303474] RAX: ffffffffffffffda RBX: 00007f628c4e70c0 RCX: 00007f62c29153b5\n[ 155758.318075] RDX: 000000000003c041 RSI: 00007f61d2986000 RDI: 0000000000000076\n[ 155758.332678] RBP: 00007f6234c5fff0 R08: 0000000000000000 R09: 0000000064d5230c\n[ 155758.347452] R10: 000000000027d450 R11: 0000000000000293 R12: 000000000003c041\n[ 155758.362044] R13: 00007f61d2986000 R14: 00007f629e11b060 R15: 000000000027d450\n[ 155758.376661]  </TASK>\n\nThis patch fixes the issue by moving the memcg's id publication from the\nalloc stage to \n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6f0df8e16eb543167f2929cb756e695709a3551d","https://git.kernel.org/stable/c/b9d30c38ee859d833a51131b5b4b864c7a6219d0"],"published_time":"2025-10-07T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53622","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix possible data races in gfs2_show_options()\n\nSome fields such as gt_logd_secs of the struct gfs2_tune are accessed\nwithout holding the lock gt_spin in gfs2_show_options():\n\n  val = sdp->sd_tune.gt_logd_secs;\n  if (val != 30)\n    seq_printf(s, \",commit=%d\", val);\n\nAnd thus can cause data races when gfs2_show_options() and other functions\nsuch as gfs2_reconfigure() are concurrently executed:\n\n  spin_lock(&gt->gt_spin);\n  gt->gt_logd_secs = newargs->ar_commit;\n\nTo fix these possible data races, the lock sdp->sd_tune.gt_spin is\nacquired before accessing the fields of gfs2_tune and released after these\naccesses.\n\nFurther changes by Andreas:\n\n- Don't hold the spin lock over the seq_printf operations.","cvss":7.0,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.0,"epss":0.00012,"ranking_epss":0.01555,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/235a5ae73cea29109a3e06f100493f17857e6a93","https://git.kernel.org/stable/c/42077d4de49e4d9c773c97c42d5383b4899a8f9d","https://git.kernel.org/stable/c/6fa0a72cbbe45db4ed967a51f9e6f4e3afe61d20","https://git.kernel.org/stable/c/7c5b2649f6a37d45bfb7abf34c9b71d08677139f","https://git.kernel.org/stable/c/7e5bbeb7eb813bb2568e1d5d02587df943272e57","https://git.kernel.org/stable/c/85e888150075cb221270b64bf772341fc6bd11d9","https://git.kernel.org/stable/c/a4f71523ed2123d63b431cc0cea4e9f363a0f054","https://git.kernel.org/stable/c/b4a7ab57effbed42624842f2ab2a49b177c21a47"],"published_time":"2025-10-07T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50554","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: avoid double ->queue_rq() because of early timeout\n\nDavid Jeffery found one double ->queue_rq() issue, so far it can\nbe triggered in VM use case because of long vmexit latency or preempt\nlatency of vCPU pthread or long page fault in vCPU pthread, then block\nIO req could be timed out before queuing the request to hardware but after\ncalling blk_mq_start_request() during ->queue_rq(), then timeout handler\nmay handle it by requeue, then double ->queue_rq() is caused, and kernel\npanic.\n\nSo far, it is driver's responsibility to cover the race between timeout\nand completion, so it seems supposed to be solved in driver in theory,\ngiven driver has enough knowledge.\n\nBut it is really one common problem, lots of driver could have similar\nissue, and could be hard to fix all affected drivers, even it isn't easy\nfor driver to handle the race. So David suggests this patch by draining\nin-progress ->queue_rq() for solving this issue.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7a73c54a3750895888ab586896736c9434e062a1","https://git.kernel.org/stable/c/82c229476b8f6afd7e09bc4dc77d89dc19ff7688","https://git.kernel.org/stable/c/8b3d6b029a552d2978bbac275303d11419826a69"],"published_time":"2025-10-07T16:15:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50555","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix a null-ptr-deref in tipc_topsrv_accept\n\nsyzbot found a crash in tipc_topsrv_accept:\n\n  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n  Workqueue: tipc_rcv tipc_topsrv_accept\n  RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487\n  Call Trace:\n   <TASK>\n   tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460\n   process_one_work+0x991/0x1610 kernel/workqueue.c:2289\n   worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n   kthread+0x2e4/0x3a0 kernel/kthread.c:376\n   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n\nIt was caused by srv->listener that might be set to null by\ntipc_topsrv_stop() in net .exit whereas it's still used in\ntipc_topsrv_accept() worker.\n\nsrv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add\na check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to\navoid the null-ptr-deref. To ensure the lsock is not released during the\ntipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()\nwhere it's waiting until the tipc_topsrv_accept worker to be done.\n\nNote that sk_callback_lock is used to protect sk->sk_user_data instead of\nsrv->listener, and it should check srv in tipc_topsrv_listener_data_ready()\ninstead. This also ensures that no more tipc_topsrv_accept worker will be\nstarted after tipc_conn_close() is called in tipc_topsrv_stop() where it\nsets sk->sk_user_data to null.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/24b129aed8730e48f47d852d58d76825ab6f407c","https://git.kernel.org/stable/c/32a3d4660b34ce49ac0162338ebe362098e2f5df","https://git.kernel.org/stable/c/7a939503fc32bff4ed60800b73ff7fbb4aea2142","https://git.kernel.org/stable/c/82cb4e4612c633a9ce320e1773114875604a3cce","https://git.kernel.org/stable/c/ce69bdac2310152bb70845024d5d704c52aabfc3","https://git.kernel.org/stable/c/cedb41664e27b2cae7e21487f1bee22dcd84037d"],"published_time":"2025-10-07T16:15:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50553","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'\n\nWhen generate a synthetic event with many params and then create a trace\naction for it [1], kernel panic happened [2].\n\nIt is because that in trace_action_create() 'data->n_params' is up to\nSYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'\nkeeps indices into array 'hist_data->var_refs' for each synthetic event\nparam, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX\n(current value is 16), so out-of-bound write happened when 'data->n_params'\nmore than 16. In this case, 'data->match_data.event' is overwritten and\neventually cause the panic.\n\nTo solve the issue, adjust the length of 'data->var_ref_idx' to be\nSYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.\n\n[1]\n # cd /sys/kernel/tracing/\n # echo \"my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\\\nint v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\\\nint v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\\\nint v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\\\nint v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\\\nint v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\\\nint v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\\\nint v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\\\nint v63\" >> synthetic_events\n # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm==\"bash\"' >> \\\nevents/sched/sched_waking/trigger\n # echo \"hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\\\npid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\\\npid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\\\npid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\\\npid,pid,pid,pid,pid,pid,pid,pid,pid)\" >> events/sched/sched_switch/trigger\n\n[2]\nBUG: unable to handle page fault for address: ffff91c900000000\nPGD 61001067 P4D 61001067 PUD 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 2 PID: 322 Comm: bash Tainted: G        W          6.1.0-rc8+ #229\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:strcmp+0xc/0x30\nCode: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee\nc3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14\n07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3\nRSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246\nRAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000\nRDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000\nRBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000\nR10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580\nR13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538\nFS:  00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0\nCall Trace:\n <TASK>\n __find_event_file+0x55/0x90\n action_create+0x76c/0x1060\n event_hist_trigger_parse+0x146d/0x2060\n ? event_trigger_write+0x31/0xd0\n trigger_process_regex+0xbb/0x110\n event_trigger_write+0x6b/0xd0\n vfs_write+0xc8/0x3e0\n ? alloc_fd+0xc0/0x160\n ? preempt_count_add+0x4d/0xa0\n ? preempt_count_add+0x70/0xa0\n ksys_write+0x5f/0xe0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f1d1d0cf077\nCode: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e\nfa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00\nf0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74\nRSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077\nRDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001\nRBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142\nR\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/04241956ce8825ff06e06e4083e7b692e9d5f712","https://git.kernel.org/stable/c/0cb31bd88361edb96cfc622648717ba348f0f4dc","https://git.kernel.org/stable/c/15697f653399253f9be4ed2a1e03d795f3cfee94","https://git.kernel.org/stable/c/82470f7d9044842618c847a7166de2b7458157a7","https://git.kernel.org/stable/c/b4efdc219fb8cfa066c7042e636ab8ad6d7e7494","https://git.kernel.org/stable/c/cf79d5410a569dad1d4112b5c3c02383cca8213a"],"published_time":"2025-10-07T16:15:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50551","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()\n\nThis patch fixes a shift-out-of-bounds in brcmfmac that occurs in\nBIT(chiprev) when a 'chiprev' provided by the device is too large.\nIt should also not be equal to or greater than BITS_PER_TYPE(u32)\nas we do bitwise AND with a u32 variable and BIT(chiprev). The patch\nadds a check that makes the function return NULL if that is the case.\nNote that the NULL case is later handled by the bus-specific caller,\nbrcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.\n\nFound by a modified version of syzkaller.\n\nUBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c\nshift exponent 151055786 is too large for 64-bit type 'long unsigned int'\nCPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n dump_stack_lvl+0x57/0x7d\n ubsan_epilogue+0x5/0x40\n __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb\n ? lock_chain_count+0x20/0x20\n brcmf_fw_alloc_request.cold+0x19/0x3ea\n ? brcmf_fw_get_firmwares+0x250/0x250\n ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0\n brcmf_usb_get_fwname+0x114/0x1a0\n ? brcmf_usb_reset_resume+0x120/0x120\n ? number+0x6c4/0x9a0\n brcmf_c_process_clm_blob+0x168/0x590\n ? put_dec+0x90/0x90\n ? enable_ptr_key_workfn+0x20/0x20\n ? brcmf_common_pd_remove+0x50/0x50\n ? rcu_read_lock_sched_held+0xa1/0xd0\n brcmf_c_preinit_dcmds+0x673/0xc40\n ? brcmf_c_set_joinpref_default+0x100/0x100\n ? rcu_read_lock_sched_held+0xa1/0xd0\n ? rcu_read_lock_bh_held+0xb0/0xb0\n ? lock_acquire+0x19d/0x4e0\n ? find_held_lock+0x2d/0x110\n ? brcmf_usb_deq+0x1cc/0x260\n ? mark_held_locks+0x9f/0xe0\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? _raw_spin_unlock_irqrestore+0x47/0x50\n ? trace_hardirqs_on+0x1c/0x120\n ? brcmf_usb_deq+0x1a7/0x260\n ? brcmf_usb_rx_fill_all+0x5a/0xf0\n brcmf_attach+0x246/0xd40\n ? wiphy_new_nm+0x1476/0x1d50\n ? kmemdup+0x30/0x40\n brcmf_usb_probe+0x12de/0x1690\n ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n usb_probe_interface+0x25f/0x710\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n ? usb_match_id.part.0+0x88/0xc0\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n ? driver_allows_async_probing+0x120/0x120\n bus_for_each_drv+0x123/0x1a0\n ? bus_rescan_devices+0x20/0x20\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? trace_hardirqs_on+0x1c/0x120\n __device_attach+0x207/0x330\n ? device_bind_driver+0xb0/0xb0\n ? kobject_uevent_env+0x230/0x12c0\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n ? __mutex_unlock_slowpath+0xe7/0x660\n ? __fw_devlink_link_to_suppliers+0x550/0x550\n usb_set_configuration+0x984/0x1770\n ? kernfs_create_link+0x175/0x230\n usb_generic_driver_probe+0x69/0x90\n usb_probe_device+0x9c/0x220\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n ? driver_allows_async_probing+0x120/0x120\n bus_for_each_drv+0x123/0x1a0\n ? bus_rescan_devices+0x20/0x20\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? trace_hardirqs_on+0x1c/0x120\n __device_attach+0x207/0x330\n ? device_bind_driver+0xb0/0xb0\n ? kobject_uevent_env+0x230/0x12c0\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n ? __fw_devlink_link_to_suppliers+0x550/0x550\n usb_new_device.cold+0x463/0xf66\n ? hub_disconnect+0x400/0x400\n ? _raw_spin_unlock_irq+0x24/0x30\n hub_event+0x10d5/0x3330\n ? hub_port_debounce+0x280/0x280\n ? __lock_acquire+0x1671/0x5790\n ? wq_calc_node_cpumask+0x170/0x2a0\n ? lock_release+0x640/0x640\n ? rcu_read_lock_sched_held+0xa1/0xd0\n ? rcu_read_lock_bh_held+0xb0/0xb0\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n process_one_work+0x873/0x13e0\n ? lock_release+0x640/0x640\n ? pwq_dec_nr_in_flight+0x320/0x320\n ? rwlock_bug.part.0+0x90/0x90\n worker_thread+0x8b/0xd10\n ? __kthread_parkme+0xd9/0x1d0\n ? pr\n---truncated---","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00014,"ranking_epss":0.02714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0b12d2aa264bac35bff9b5399bb162262b2b8949","https://git.kernel.org/stable/c/1db036d13e10809943c2dce553e2fa7fc9c6cd80","https://git.kernel.org/stable/c/4c8fc44c44b97854623c56363c359f711fc0b887","https://git.kernel.org/stable/c/579c9b9838e8a73f6e93ddece07972c241514dcc","https://git.kernel.org/stable/c/5b06a8a25eba07628313aa3c5496522eff97be53","https://git.kernel.org/stable/c/81d17f6f3331f03c8eafdacea68ab773426c1e3c","https://git.kernel.org/stable/c/87792567d9ed93fd336d2c3b8d7870f44e141e6d","https://git.kernel.org/stable/c/9d2f70fa2c7cc6c73a420ff15682454782d3d6f6","https://git.kernel.org/stable/c/bc45aa1911bf699b9905f12414e3c1879d6b784f","https://git.kernel.org/stable/c/ffb589963df103caaf062081a32db0b9e1798660"],"published_time":"2025-10-07T16:15:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50552","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: use quiesced elevator switch when reinitializing queues\n\nThe hctx's run_work may be racing with the elevator switch when\nreinitializing hardware queues. The queue is merely frozen in this\ncontext, but that only prevents requests from allocating and doesn't\nstop the hctx work from running. The work may get an elevator pointer\nthat's being torn down, and can result in use-after-free errors and\nkernel panics (example below). Use the quiesced elevator switch instead,\nand make the previous one static since it is now only used locally.\n\n  nvme nvme0: resetting controller\n  nvme nvme0: 32/0/0 default/read/poll queues\n  BUG: kernel NULL pointer dereference, address: 0000000000000008\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0\n  Oops: 0000 [#1] SMP PTI\n  Workqueue: kblockd blk_mq_run_work_fn\n  RIP: 0010:kyber_has_work+0x29/0x70\n\n...\n\n  Call Trace:\n   __blk_mq_do_dispatch_sched+0x83/0x2b0\n   __blk_mq_sched_dispatch_requests+0x12e/0x170\n   blk_mq_sched_dispatch_requests+0x30/0x60\n   __blk_mq_run_hw_queue+0x2b/0x50\n   process_one_work+0x1ef/0x380\n   worker_thread+0x2d/0x3e0","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00012,"ranking_epss":0.01866,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/63a681bcc32a43528ce0f690569f7f48e59c3963","https://git.kernel.org/stable/c/8237c01f1696bc53c470493bf1fe092a107648a6","https://git.kernel.org/stable/c/c478b3b2900f1834cf9eda5bfef0d5696099505d"],"published_time":"2025-10-07T16:15:41","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50550","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nblk-iolatency: Fix memory leak on add_disk() failures\n\nWhen a gendisk is successfully initialized but add_disk() fails such as when\na loop device has invalid number of minor device numbers specified,\nblkcg_init_disk() is called during init and then blkcg_exit_disk() during\nerror handling. Unfortunately, iolatency gets initialized in the former but\ndoesn't get cleaned up in the latter.\n\nThis is because, in non-error cases, the cleanup is performed by\ndel_gendisk() calling rq_qos_exit(), the assumption being that rq_qos\npolicies, iolatency being one of them, can only be activated once the disk\nis fully registered and visible. That assumption is true for wbt and iocost,\nbut not so for iolatency as it gets initialized before add_disk() is called.\n\nIt is desirable to lazy-init rq_qos policies because they are optional\nfeatures and add to hot path overhead once initialized - each IO has to walk\nall the registered rq_qos policies. So, we want to switch iolatency to lazy\ninit too. However, that's a bigger change. As a fix for the immediate\nproblem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk().\nThis is safe because duplicate calls to rq_qos_exit() become noop's.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/215f9437dda09531bcb80605298a24219f01cec5","https://git.kernel.org/stable/c/2a126e1db5553ce4498290df019866952f858954","https://git.kernel.org/stable/c/813e693023ba10da9e75067780f8378465bf27cc"],"published_time":"2025-10-07T16:15:40","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50546","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix uninititialized value in 'ext4_evict_inode'\n\nSyzbot found the following issue:\n=====================================================\nBUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180\n ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180\n evict+0x365/0x9a0 fs/inode.c:664\n iput_final fs/inode.c:1747 [inline]\n iput+0x985/0xdd0 fs/inode.c:1773\n __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361\n ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844\n vfs_mknod+0x79d/0x830 fs/namei.c:3914\n do_mknodat+0x47d/0xaa0\n __do_sys_mknodat fs/namei.c:3992 [inline]\n __se_sys_mknodat fs/namei.c:3989 [inline]\n __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\nUninit was created at:\n __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578\n alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285\n alloc_slab_page mm/slub.c:1794 [inline]\n allocate_slab+0x1b5/0x1010 mm/slub.c:1939\n new_slab mm/slub.c:1992 [inline]\n ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180\n __slab_alloc mm/slub.c:3279 [inline]\n slab_alloc_node mm/slub.c:3364 [inline]\n slab_alloc mm/slub.c:3406 [inline]\n __kmem_cache_alloc_lru mm/slub.c:3413 [inline]\n kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429\n alloc_inode_sb include/linux/fs.h:3117 [inline]\n ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321\n alloc_inode+0x83/0x440 fs/inode.c:259\n new_inode_pseudo fs/inode.c:1018 [inline]\n new_inode+0x3b/0x430 fs/inode.c:1046\n __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959\n ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992\n vfs_mkdir+0x62a/0x870 fs/namei.c:4035\n do_mkdirat+0x466/0x7b0 fs/namei.c:4060\n __do_sys_mkdirat fs/namei.c:4075 [inline]\n __se_sys_mkdirat fs/namei.c:4073 [inline]\n __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\nCPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\n=====================================================\n\nNow, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed\nbefore set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after\n6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' which\nwill lead to access uninit-value.\nTo solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/091f85db4c3fb1734a6d7fb4777a2b2831da6631","https://git.kernel.org/stable/c/3c31d8d3ad95aef8cc17a4fcf317e46217148439","https://git.kernel.org/stable/c/56491d60ddca9c697d885394cb0173675b9ab81f","https://git.kernel.org/stable/c/7ea71af94eaaaf6d9aed24bc94a05b977a741cb9","https://git.kernel.org/stable/c/9f966e021c20caae639dd0e404c8761e8281a2c4","https://git.kernel.org/stable/c/e431b4fb1fb8c2654b808086e9747a000adb9655","https://git.kernel.org/stable/c/f0bffdcc7cb14598af2aa706f1e0f2a9054154ba"],"published_time":"2025-10-07T16:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50547","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: solo6x10: fix possible memory leak in solo_sysfs_init()\n\nIf device_register() returns error in solo_sysfs_init(), the\nname allocated by dev_set_name() need be freed. As comment of\ndevice_register() says, it should use put_device() to give up\nthe reference in the error path. So fix this by calling\nput_device(), then the name can be freed in kobject_cleanup().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00029,"ranking_epss":0.08328,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/49060c0da57a381563e482e331dc9d4c3725b41b","https://git.kernel.org/stable/c/7b02c50d3978840781808e13bc13137fb81286b5","https://git.kernel.org/stable/c/7cf71bbe5d2ee12613f6e278888f5fc9c5c0cc2b","https://git.kernel.org/stable/c/7f5866dd96d95b74e439f6ee17b8abd8195179fb","https://git.kernel.org/stable/c/83d4b1ae98a47a739fa5241300b86eb1110d5d63","https://git.kernel.org/stable/c/9416861170ba0da8ddb0f4fd2d28334f0ed3b9c2","https://git.kernel.org/stable/c/963729538674be4cb8fa292529ecf32de0d6c6dd","https://git.kernel.org/stable/c/b61509093e1af69e336a094d439b8e1137cb40d8","https://git.kernel.org/stable/c/d6db105bcfbdbbbd484e788a0ddf8140a4a8c486"],"published_time":"2025-10-07T16:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50548","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: hi846: Fix memory leak in hi846_parse_dt()\n\nIf any of the checks related to the supported link frequencies fail, then\nthe V4L2 fwnode resources don't get released before returning, which leads\nto a memleak. Fix this by properly freeing the V4L2 fwnode data in a\ndesignated label.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4368730678412a8fa71960dbda81e122dafa70f7","https://git.kernel.org/stable/c/80113026d415e27483669db7a88b548d1ec3d3d1","https://git.kernel.org/stable/c/a05a9ae9ef3fffc9bc7ec2bc432a249a01155f6e"],"published_time":"2025-10-07T16:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50549","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata\n\nFollowing concurrent processes:\n\n          P1(drop cache)                P2(kworker)\ndrop_caches_sysctl_handler\n drop_slab\n  shrink_slab\n   down_read(&shrinker_rwsem)  - LOCK A\n   do_shrink_slab\n    super_cache_scan\n     prune_icache_sb\n      dispose_list\n       evict\n        ext4_evict_inode\n\t ext4_clear_inode\n\t  ext4_discard_preallocations\n\t   ext4_mb_load_buddy_gfp\n\t    ext4_mb_init_cache\n\t     ext4_read_block_bitmap_nowait\n\t      ext4_read_bh_nowait\n\t       submit_bh\n\t        dm_submit_bio\n\t\t                 do_worker\n\t\t\t\t  process_deferred_bios\n\t\t\t\t   commit\n\t\t\t\t    metadata_operation_failed\n\t\t\t\t     dm_pool_abort_metadata\n\t\t\t\t      down_write(&pmd->root_lock) - LOCK B\n\t\t                      __destroy_persistent_data_objects\n\t\t\t\t       dm_block_manager_destroy\n\t\t\t\t        dm_bufio_client_destroy\n\t\t\t\t         unregister_shrinker\n\t\t\t\t\t  down_write(&shrinker_rwsem)\n\t\t thin_map                            |\n\t\t  dm_thin_find_block                 ↓\n\t\t   down_read(&pmd->root_lock) --> ABBA deadlock\n\n, which triggers hung task:\n\n[   76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.\n[   76.976019]       Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910\n[   76.978521] task:kworker/u4:3    state:D stack:0     pid:63    ppid:2\n[   76.978534] Workqueue: dm-thin do_worker\n[   76.978552] Call Trace:\n[   76.978564]  __schedule+0x6ba/0x10f0\n[   76.978582]  schedule+0x9d/0x1e0\n[   76.978588]  rwsem_down_write_slowpath+0x587/0xdf0\n[   76.978600]  down_write+0xec/0x110\n[   76.978607]  unregister_shrinker+0x2c/0xf0\n[   76.978616]  dm_bufio_client_destroy+0x116/0x3d0\n[   76.978625]  dm_block_manager_destroy+0x19/0x40\n[   76.978629]  __destroy_persistent_data_objects+0x5e/0x70\n[   76.978636]  dm_pool_abort_metadata+0x8e/0x100\n[   76.978643]  metadata_operation_failed+0x86/0x110\n[   76.978649]  commit+0x6a/0x230\n[   76.978655]  do_worker+0xc6e/0xd90\n[   76.978702]  process_one_work+0x269/0x630\n[   76.978714]  worker_thread+0x266/0x630\n[   76.978730]  kthread+0x151/0x1b0\n[   76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.\n[   76.979756]       Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910\n[   76.982111] task:test.sh         state:D stack:0     pid:2646  ppid:2459\n[   76.982128] Call Trace:\n[   76.982139]  __schedule+0x6ba/0x10f0\n[   76.982155]  schedule+0x9d/0x1e0\n[   76.982159]  rwsem_down_read_slowpath+0x4f4/0x910\n[   76.982173]  down_read+0x84/0x170\n[   76.982177]  dm_thin_find_block+0x4c/0xd0\n[   76.982183]  thin_map+0x201/0x3d0\n[   76.982188]  __map_bio+0x5b/0x350\n[   76.982195]  dm_submit_bio+0x2b6/0x930\n[   76.982202]  __submit_bio+0x123/0x2d0\n[   76.982209]  submit_bio_noacct_nocheck+0x101/0x3e0\n[   76.982222]  submit_bio_noacct+0x389/0x770\n[   76.982227]  submit_bio+0x50/0xc0\n[   76.982232]  submit_bh_wbc+0x15e/0x230\n[   76.982238]  submit_bh+0x14/0x20\n[   76.982241]  ext4_read_bh_nowait+0xc5/0x130\n[   76.982247]  ext4_read_block_bitmap_nowait+0x340/0xc60\n[   76.982254]  ext4_mb_init_cache+0x1ce/0xdc0\n[   76.982259]  ext4_mb_load_buddy_gfp+0x987/0xfa0\n[   76.982263]  ext4_discard_preallocations+0x45d/0x830\n[   76.982274]  ext4_clear_inode+0x48/0xf0\n[   76.982280]  ext4_evict_inode+0xcf/0xc70\n[   76.982285]  evict+0x119/0x2b0\n[   76.982290]  dispose_list+0x43/0xa0\n[   76.982294]  prune_icache_sb+0x64/0x90\n[   76.982298]  super_cache_scan+0x155/0x210\n[   76.982303]  do_shrink_slab+0x19e/0x4e0\n[   76.982310]  shrink_slab+0x2bd/0x450\n[   76.982317]  drop_slab+0xcc/0x1a0\n[   76.982323]  drop_caches_sysctl_handler+0xb7/0xe0\n[   76.982327]  proc_sys_call_handler+0x1bc/0x300\n[   76.982331]  proc_sys_write+0x17/0x20\n[   76.982334]  vfs_write+0x3d3/0x570\n[   76.982342]  ksys_write+0x73/0x160\n[   76.982347]  __x64_sys_write+0x1e/0x30\n[   76.982352]  do_syscall_64+0x35/0x80\n[   76.982357]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nFunct\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01473,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/200aa33b5d781e7c0fa6c0c7db9dbcc3f574ce8f","https://git.kernel.org/stable/c/2d891cc5a1706b6908bceb56af7176a463ee6d62","https://git.kernel.org/stable/c/7e37578069737b04955c71dd85db8a3bc2709eff","https://git.kernel.org/stable/c/8111964f1b8524c4bb56b02cd9c7a37725ea21fd","https://git.kernel.org/stable/c/cdf7a39bcc427febbfe3c3b9fe829825ead96c27","https://git.kernel.org/stable/c/f8c26c33fef588ee54852cffa7cbb9f9d9869405"],"published_time":"2025-10-07T16:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50538","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nvme: Fix error not catched in fake_init()\n\nIn fake_init(), __root_device_register() is possible to fail but it's\nignored, which can cause unregistering vme_root fail when exit.\n\n general protection fault,\n probably for non-canonical address 0xdffffc000000008c\n KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467]\n RIP: 0010:root_device_unregister+0x26/0x60\n Call Trace:\n  <TASK>\n  __x64_sys_delete_module+0x34f/0x540\n  do_syscall_64+0x38/0x90\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nReturn error when __root_device_register() fails.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/09be0e7ac5f9374b6f8de72c89ed67129af71f65","https://git.kernel.org/stable/c/37d3de40c1ffb6a5e626bf46ff5ef5766c824e2c","https://git.kernel.org/stable/c/4bc217b25ea81034fad8e33fd33e4659f086421d","https://git.kernel.org/stable/c/60ff9bd4ffc87bace581e235a6728f5ac8e5071f","https://git.kernel.org/stable/c/69b43937f14bdc3594f57f1a507a14f3d1187136","https://git.kernel.org/stable/c/7bef797d707f1744f71156b21d41e3b8c946631f","https://git.kernel.org/stable/c/a2a93546d414c7fe4862b87183fb737d1300d9d2","https://git.kernel.org/stable/c/e831fdd60e5863ee03173baf5a0f7c5450b44381","https://git.kernel.org/stable/c/f3f65c4177846c483bf009f8c512ab04b3c62466"],"published_time":"2025-10-07T16:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50539","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nARM: OMAP2+: omap4-common: Fix refcount leak bug\n\nIn omap4_sram_init(), of_find_compatible_node() will return a node\npointer with refcount incremented. We should use of_node_put() when\nit is not used anymore.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/049875b76660bbdc4873a915afb294f954eb7320","https://git.kernel.org/stable/c/1d9452ae3bdb830f9309cf10a2f65977999cb14e","https://git.kernel.org/stable/c/7c32919a378782c95c72bc028b5c30dfe8c11f82"],"published_time":"2025-10-07T16:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50540","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: qcom-adm: fix wrong sizeof config in slave_config\n\nFix broken slave_config function that uncorrectly compare the\nperipheral_size with the size of the config pointer instead of the size\nof the config struct. This cause the crci value to be ignored and cause\na kernel panic on any slave that use adm driver.\n\nTo fix this, compare to the size of the struct and NOT the size of the\npointer.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7490274b41a432824f7df5071ace3df2ab59caa7","https://git.kernel.org/stable/c/7c8765308371be30f50c1b5b97618b731514b207","https://git.kernel.org/stable/c/f1dd45a6585a1689e1e8906b3f9e302b9d40c715"],"published_time":"2025-10-07T16:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50541","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow\n\nUDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics.\nThese registers are 32-bit hardware counters and the driver uses these\ncounters to monitor the operational progress status for a channel, when\ntransferring more than 4GB of data it was observed that these counters\noverflow and completion calculation of a operation gets affected and the\ntransfer hangs indefinitely.\n\nThis commit adds changes to decrease the byte count for every complete\ntransaction so that these registers never overflow and the proper byte\ncount statistics is maintained for ongoing transaction by the RT counters.\n\nEarlier uc->bcnt used to maintain a count of the completed bytes at driver\nside, since the RT counters maintain the statistics of current transaction\nnow, the maintenance of uc->bcnt is not necessary.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7c94dcfa8fcff2dba53915f1dabfee49a3df8b88","https://git.kernel.org/stable/c/a065657643a62a24b4435ddcaea45f1e9378749e","https://git.kernel.org/stable/c/d68da10b0cceb4177b653833e794b2923a4ffbd7","https://git.kernel.org/stable/c/e0b16bfbd3a4a8d09614046335f4482313e7c0c4"],"published_time":"2025-10-07T16:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50542","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: si470x: Fix use-after-free in si470x_int_in_callback()\n\nsyzbot reported use-after-free in si470x_int_in_callback() [1].  This\nindicates that urb->context, which contains struct si470x_device\nobject, is freed when si470x_int_in_callback() is called.\n\nThe cause of this issue is that si470x_int_in_callback() is called for\nfreed urb.\n\nsi470x_usb_driver_probe() calls si470x_start_usb(), which then calls\nusb_submit_urb() and si470x_start().  If si470x_start_usb() fails,\nsi470x_usb_driver_probe() doesn't kill urb, but it just frees struct\nsi470x_device object, as depicted below:\n\nsi470x_usb_driver_probe()\n  ...\n  si470x_start_usb()\n    ...\n    usb_submit_urb()\n    retval = si470x_start()\n    return retval\n  if (retval < 0)\n    free struct si470x_device object, but don't kill urb\n\nThis patch fixes this issue by killing urb when si470x_start_usb()\nfails and urb is submitted.  If si470x_start_usb() fails and urb is\nnot submitted, i.e. submitting usb fails, it just frees struct\nsi470x_device object.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0ca298d548461d29615f9a2b1309e8dcf4a352c6","https://git.kernel.org/stable/c/146bd005ebb01ae190c22af050cb98623958c373","https://git.kernel.org/stable/c/1c6447d0fc68650e51586dde79b5090d9d77f13a","https://git.kernel.org/stable/c/52f54fe78cca24850a30865037250f63eb3d5bf7","https://git.kernel.org/stable/c/63648a7bd1a7599bcc2040a6d1792363ae4c2e1b","https://git.kernel.org/stable/c/6c8aee0c8fcc6dda94315f7908e8fa9bc75abe75","https://git.kernel.org/stable/c/7d21e0b1b41b21d628bf2afce777727bd4479aa5","https://git.kernel.org/stable/c/8c6151b8e8dd2d98ad2cd725d26d1e103d989891","https://git.kernel.org/stable/c/92b0888398e4ba51d93b618a6506781f4e3879c9"],"published_time":"2025-10-07T16:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50543","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix mr->map double free\n\nrxe_mr_cleanup() which tries to free mr->map again will be called when\nrxe_mr_init_user() fails:\n\n   CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25\n   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n   Call Trace:\n    <TASK>\n    dump_stack_lvl+0x45/0x5d\n    panic+0x19e/0x349\n    end_report.part.0+0x54/0x7c\n    kasan_report.cold+0xa/0xf\n    rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe]\n    __rxe_cleanup+0x10a/0x1e0 [rdma_rxe]\n    rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe]\n    ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs]\n    ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs]\n    ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs]\n\nThis issue was firstly exposed since commit b18c7da63fcb (\"RDMA/rxe: Fix\nmemory leak in error path code\") and then we fixed it in commit\n8ff5f5d9d8cf (\"RDMA/rxe: Prevent double freeing rxe_map_set()\") but this\nfix was reverted together at last by commit 1e75550648da (Revert\n\"RDMA/rxe: Create duplicate mapping tables for FMRs\")\n\nSimply let rxe_mr_cleanup() always handle freeing the mr->map once it is\nsuccessfully allocated.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00012,"ranking_epss":0.01866,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/06f73568f553b5be6ba7f6fe274d333ea29fc46d","https://git.kernel.org/stable/c/6ce577f09013206e36e674cd27da3707b2278268","https://git.kernel.org/stable/c/7d984dac8f6bf4ebd3398af82b357e1d181ecaac"],"published_time":"2025-10-07T16:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50544","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nusb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()\n\nxhci_alloc_stream_info() allocates stream context array for stream_info\n->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,\nstream_info->stream_ctx_array is not released, which will lead to a\nmemory leak.\n\nWe can fix it by releasing the stream_info->stream_ctx_array with\nxhci_free_stream_ctx() on the error path to avoid the potential memory\nleak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/782c873f8e7686f5b3c47e8b099f7e08c3dd1fdc","https://git.kernel.org/stable/c/7e271f42a5cc3768cd2622b929ba66859ae21f97","https://git.kernel.org/stable/c/7fc6bab3413e6a42bb1264ff7c9149808c93a4c7","https://git.kernel.org/stable/c/91271a3e772e180bbb8afb114c72fd294a02f93d","https://git.kernel.org/stable/c/9fa81cbd2dd300aa8fe9bac70e068b9a11cbb144","https://git.kernel.org/stable/c/a40ad475236022f3432880e3091c380e46e71a71","https://git.kernel.org/stable/c/ddab9fe76296840aad686c66888a9c1dfdbff5ff","https://git.kernel.org/stable/c/e702de2f5c893bf2cdb0152191f99a6ad1411823","https://git.kernel.org/stable/c/fcd594da0b5955119d9707e4e0a8d0fb1c969101"],"published_time":"2025-10-07T16:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50545","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nr6040: Fix kmemleak in probe and remove\n\nThere is a memory leaks reported by kmemleak:\n\n  unreferenced object 0xffff888116111000 (size 2048):\n    comm \"modprobe\", pid 817, jiffies 4294759745 (age 76.502s)\n    hex dump (first 32 bytes):\n      00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff  ................\n      08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60\n      [<ffffffff827e20ee>] phy_device_create+0x4e/0x90\n      [<ffffffff827e6072>] get_phy_device+0xd2/0x220\n      [<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0\n      [<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0\n      [<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040]\n      ...\n\nThe problem occurs in probe process as follows:\n  r6040_init_one:\n    mdiobus_register\n      mdiobus_scan    <- alloc and register phy_device,\n                         the reference count of phy_device is 3\n    r6040_mii_probe\n      phy_connect     <- connect to the first phy_device,\n                         so the reference count of the first\n                         phy_device is 4, others are 3\n    register_netdev   <- fault inject succeeded, goto error handling path\n\n    // error handling path\n    err_out_mdio_unregister:\n      mdiobus_unregister(lp->mii_bus);\n    err_out_mdio:\n      mdiobus_free(lp->mii_bus);    <- the reference count of the first\n                                       phy_device is 1, it is not released\n                                       and other phy_devices are released\n  // similarly, the remove process also has the same problem\n\nThe root cause is traced to the phy_device is not disconnected when\nremoves one r6040 device in r6040_remove_one() or on error handling path\nafter r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet\ndevice is connected to the first PHY device of mii_bus, in order to\nnotify the connected driver when the link status changes, which is the\ndefault behavior of the PHY infrastructure to handle everything.\nTherefore the phy_device should be disconnected when removes one r6040\ndevice or on error handling path.\n\nFix it by adding phy_disconnect() when removes one r6040 device or on\nerror handling path after r6040_mii probed successfully.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d","https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269","https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44","https://git.kernel.org/stable/c/7e43039a49c2da45edc1d9d7c9ede4003ab45a5f","https://git.kernel.org/stable/c/9b5b50329e2e966831a7237dd6949e7b5362a49a","https://git.kernel.org/stable/c/a04707f4596952049da05756c27398c34d9a1d36","https://git.kernel.org/stable/c/ad2c8f25457ca9a81e7e958148cbc26600ce3071","https://git.kernel.org/stable/c/b0a61359026b57a287a48fbb4ba1d097023eca3e","https://git.kernel.org/stable/c/b4448816e6a565e08236a6009c6bf48c6836cdfd"],"published_time":"2025-10-07T16:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50530","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()\n\nOur syzkaller report a null pointer dereference, root cause is\nfollowing:\n\n__blk_mq_alloc_map_and_rqs\n set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs\n  blk_mq_alloc_map_and_rqs\n   blk_mq_alloc_rqs\n    // failed due to oom\n    alloc_pages_node\n    // set->tags[hctx_idx] is still NULL\n    blk_mq_free_rqs\n     drv_tags = set->tags[hctx_idx];\n     // null pointer dereference is triggered\n     blk_mq_clear_rq_mapping(drv_tags, ...)\n\nThis is because commit 63064be150e4 (\"blk-mq:\nAdd blk_mq_alloc_map_and_rqs()\") merged the two steps:\n\n1) set->tags[hctx_idx] = blk_mq_alloc_rq_map()\n2) blk_mq_alloc_rqs(..., set->tags[hctx_idx])\n\ninto one step:\n\nset->tags[hctx_idx] = blk_mq_alloc_map_and_rqs()\n\nSince tags is not initialized yet in this case, fix the problem by\nchecking if tags is NULL pointer in blk_mq_clear_rq_mapping().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6a440e6d04431e774dc084abe88c106e2a474c1a","https://git.kernel.org/stable/c/76dd298094f484c6250ebd076fa53287477b2328"],"published_time":"2025-10-07T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50531","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix an information leak in tipc_topsrv_kern_subscr\n\nUse a 8-byte write to initialize sub.usr_handle in\ntipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized\nwhen issuing setsockopt(..., SOL_TIPC, ...).\nThis resulted in an infoleak reported by KMSAN when the packet was\nreceived:\n\n  =====================================================\n  BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169\n   instrument_copy_to_user ./include/linux/instrumented.h:121\n   copyout+0xbc/0x100 lib/iov_iter.c:169\n   _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527\n   copy_to_iter ./include/linux/uio.h:176\n   simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513\n   __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419\n   skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527\n   skb_copy_datagram_msg ./include/linux/skbuff.h:3903\n   packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469\n   ____sys_recvmsg+0x2c4/0x810 net/socket.c:?\n   ___sys_recvmsg+0x217/0x840 net/socket.c:2743\n   __sys_recvmsg net/socket.c:2773\n   __do_sys_recvmsg net/socket.c:2783\n   __se_sys_recvmsg net/socket.c:2780\n   __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780\n   do_syscall_x64 arch/x86/entry/common.c:50\n   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120\n\n  ...\n\n  Uninit was stored to memory at:\n   tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156\n   tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375\n   tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579\n   tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190\n   tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084\n   tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201\n   __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252\n   __do_sys_setsockopt net/socket.c:2263\n   __se_sys_setsockopt net/socket.c:2260\n   __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260\n   do_syscall_x64 arch/x86/entry/common.c:50\n   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120\n\n  Local variable sub created at:\n   tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562\n   tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190\n\n  Bytes 84-87 of 88 are uninitialized\n  Memory access of size 88 starts at ffff88801ed57cd0\n  Data copied to user address 0000000020000400\n  ...\n  =====================================================","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0001,"ranking_epss":0.00994,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3d1b83ff7b6575a4e41283203e6b2e25ea700cd7","https://git.kernel.org/stable/c/567f8de358b61015dcfb8878a1f06c5369a45f54","https://git.kernel.org/stable/c/777ecaabd614d47c482a5c9031579e66da13989a","https://git.kernel.org/stable/c/dbc01c0a4e202a7e925dad1d4b7c1d6eb0c81154","https://git.kernel.org/stable/c/e558e148938442dd49628cd7ef61c360832bef31","https://git.kernel.org/stable/c/fef70f978bc289642501d88d2a3f5e841bd31a67"],"published_time":"2025-10-07T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50532","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()\n\nIn mpt3sas_transport_port_add(), if sas_rphy_add() returns error,\nsas_rphy_free() needs be called to free the resource allocated in\nsas_end_device_alloc(). Otherwise a kernel crash will happen:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000108\nCPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G        W          6.1.0-rc1+ #189\npstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x54/0x3d0\nlr : device_del+0x37c/0x3d0\nCall trace:\n device_del+0x54/0x3d0\n attribute_container_class_device_del+0x28/0x38\n transport_remove_classdev+0x6c/0x80\n attribute_container_device_trigger+0x108/0x110\n transport_remove_device+0x28/0x38\n sas_rphy_remove+0x50/0x78 [scsi_transport_sas]\n sas_port_delete+0x30/0x148 [scsi_transport_sas]\n do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]\n device_for_each_child+0x68/0xb0\n sas_remove_children+0x30/0x50 [scsi_transport_sas]\n sas_rphy_remove+0x38/0x78 [scsi_transport_sas]\n sas_port_delete+0x30/0x148 [scsi_transport_sas]\n do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]\n device_for_each_child+0x68/0xb0\n sas_remove_children+0x30/0x50 [scsi_transport_sas]\n sas_remove_host+0x20/0x38 [scsi_transport_sas]\n scsih_remove+0xd8/0x420 [mpt3sas]\n\nBecause transport_add_device() is not called when sas_rphy_add() fails, the\ndevice is not added. When sas_rphy_remove() is subsequently called to\nremove the device in the remove() path, a NULL pointer dereference happens.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6a92129c8f999ff5b122c100ce7f625eb3e98c4b","https://git.kernel.org/stable/c/6f6768e2fc8638fabdd8802c2ef693d7aef01db1","https://git.kernel.org/stable/c/78316e9dfc24906dd474630928ed1d3c562b568e","https://git.kernel.org/stable/c/ce1a69cc85006b494353911b35171da195d79e25","https://git.kernel.org/stable/c/d17bca3ddfe507874cb826d32721552da12e741f","https://git.kernel.org/stable/c/d60000cb1195a464080b0efb4949daf7594e0020"],"published_time":"2025-10-07T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50533","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: mlme: fix null-ptr deref on failed assoc\n\nIf association to an AP without a link 0 fails, then we crash in\ntracing because it assumes that either ap_mld_addr or link 0 BSS\nis valid, since we clear sdata->vif.valid_links and then don't\nadd the ap_mld_addr to the struct.\n\nSince we clear also sdata->vif.cfg.ap_addr, keep a local copy of\nit and assign it earlier, before clearing valid_links, to fix\nthis.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/78a6a43aaf87180ec7425a2a90468e1b4d09a1ec","https://git.kernel.org/stable/c/bb7743955a929e44b308cc3f63f8cc03873c1bee","https://git.kernel.org/stable/c/c695dfba8dfb82dc7ace4f22be088916cbf621ca"],"published_time":"2025-10-07T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50534","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: Use last transaction's pmd->root when commit failed\n\nRecently we found a softlock up problem in dm thin pool btree lookup\ncode due to corrupted metadata:\n\n Kernel panic - not syncing: softlockup: hung tasks\n CPU: 7 PID: 2669225 Comm: kworker/u16:3\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n Workqueue: dm-thin do_worker [dm_thin_pool]\n Call Trace:\n   <IRQ>\n   dump_stack+0x9c/0xd3\n   panic+0x35d/0x6b9\n   watchdog_timer_fn.cold+0x16/0x25\n   __run_hrtimer+0xa2/0x2d0\n   </IRQ>\n   RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio]\n   __bufio_new+0x11f/0x4f0 [dm_bufio]\n   new_read+0xa3/0x1e0 [dm_bufio]\n   dm_bm_read_lock+0x33/0xd0 [dm_persistent_data]\n   ro_step+0x63/0x100 [dm_persistent_data]\n   btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data]\n   dm_btree_lookup+0x16f/0x210 [dm_persistent_data]\n   dm_thin_find_block+0x12c/0x210 [dm_thin_pool]\n   __process_bio_read_only+0xc5/0x400 [dm_thin_pool]\n   process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool]\n   process_one_work+0x3c5/0x730\n\nFollowing process may generate a broken btree mixed with fresh and\nstale btree nodes, which could get dm thin trapped in an infinite loop\nwhile looking up data block:\n Transaction 1: pmd->root = A, A->B->C   // One path in btree\n                pmd->root = X, X->Y->Z   // Copy-up\n Transaction 2: X,Z is updated on disk, Y write failed.\n                // Commit failed, dm thin becomes read-only.\n                process_bio_read_only\n\t\t dm_thin_find_block\n\t\t  __find_block\n\t\t   dm_btree_lookup(pmd->root)\nThe pmd->root points to a broken btree, Y may contain stale node\npointing to any block, for example X, which gets dm thin trapped into\na dead loop while looking up Z.\n\nFix this by setting pmd->root in __open_metadata(), so that dm thin\nwill use the last transaction's pmd->root if commit failed.\n\nFetch a reproducer in [Link].\n\nLinke: https://bugzilla.kernel.org/show_bug.cgi?id=216790","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3db757ffdd87ed8d7118b2250236a496502a660f","https://git.kernel.org/stable/c/4b710e8481ade7c9200e94d3018e99dc42a0a0e8","https://git.kernel.org/stable/c/7991dbff6849f67e823b7cc0c15e5a90b0549b9f","https://git.kernel.org/stable/c/87d69b8824ca9b090f5a8ed47f758e8f6eecb871","https://git.kernel.org/stable/c/94f01ecc2aa0be992865acc80ebb6701f731f955","https://git.kernel.org/stable/c/a63ce4eca86fd207e3db07c00fb7ccf4adf1b230","https://git.kernel.org/stable/c/b35a22760aa5008d82533e59b0f0b5eb1b02d4e5","https://git.kernel.org/stable/c/b91f481300e3a10eaf66b94fc39b740928762aaf","https://git.kernel.org/stable/c/f758987ff0af3a4b5ee69e95cab6a5294e4367b0"],"published_time":"2025-10-07T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50535","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix potential null-deref in dm_resume\n\n[Why]\nFixing smatch error:\ndm_resume() error: we previously assumed 'aconnector->dc_link' could be null\n\n[How]\nCheck if dc_link null at the beginning of the loop,\nso further checks can be dropped.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/00b655fa96b4e941351cc4bf5ca755a65ae94a8e","https://git.kernel.org/stable/c/7a7175a2cd84b7874bebbf8e59f134557a34161b","https://git.kernel.org/stable/c/8e365f1bd672cc9320a936f6ae6f8087aa40e9bc","https://git.kernel.org/stable/c/9f73793b81637c60ccc83cc508645310b8ab7d80","https://git.kernel.org/stable/c/bb9a5562beb982aa5ebb73c521c49596ff8b8030","https://git.kernel.org/stable/c/d236103782de25736996a45bd36ac2a89bdc93c6","https://git.kernel.org/stable/c/fd79b61af2782f8875c78f50cdb8630ec43e2990"],"published_time":"2025-10-07T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50536","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix repeated calls to sock_put() when msg has more_data\n\nIn tcp_bpf_send_verdict() redirection, the eval variable is assigned to\n__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,\nsock_put() will be called multiple times.\n\nWe should reset the eval variable to __SK_NONE every time more_data\nstarts.\n\nThis causes:\n\nIPv4: Attempt to release TCP socket in state 1 00000000b4c925d7\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110\nModules linked in:\nCPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1\nHardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014\nCall Trace:\n <TASK>\n __tcp_transmit_skb+0xa1b/0xb90\n ? __alloc_skb+0x8c/0x1a0\n ? __kmalloc_node_track_caller+0x184/0x320\n tcp_write_xmit+0x22a/0x1110\n __tcp_push_pending_frames+0x32/0xf0\n do_tcp_sendpages+0x62d/0x640\n tcp_bpf_push+0xae/0x2c0\n tcp_bpf_sendmsg_redir+0x260/0x410\n ? preempt_count_add+0x70/0xa0\n tcp_bpf_send_verdict+0x386/0x4b0\n tcp_bpf_sendmsg+0x21b/0x3b0\n sock_sendmsg+0x58/0x70\n __sys_sendto+0xfa/0x170\n ? xfd_validate_state+0x1d/0x80\n ? switch_fpu_return+0x59/0xe0\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x37/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/113236e8f49f262f318c00ebb14b15f4834e87c1","https://git.kernel.org/stable/c/28e4a763cd4a2b1a78852216ef4bd7df3a05cec6","https://git.kernel.org/stable/c/578a7628b838a3ac8ad61deaab5a816ff032ac13","https://git.kernel.org/stable/c/7508b9f4daac4ec7dfe0b6fb2d688b1c1c105e10","https://git.kernel.org/stable/c/7a9841ca025275b5b0edfb0b618934abb6ceec15","https://git.kernel.org/stable/c/8786bde11a4f31b63b3036731df0b47337a7a245"],"published_time":"2025-10-07T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50537","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()\n\nIn rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will\nnot be freed through rpi_firmware_delete(), fix this leak by calling\nkfree() in the error path.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0002,"ranking_epss":0.05261,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/62ac943eb2a9d655e431b9bc98ff6d7bd51a0e49","https://git.kernel.org/stable/c/6757dd2193fe18c5c5fe3050e7f2ff9dcbd1ff34","https://git.kernel.org/stable/c/71d2abab374f707ab8ac8dcef191fd2b3b67b8bd","https://git.kernel.org/stable/c/7b51161696e803fd5f9ad55b20a64c2df313f95c","https://git.kernel.org/stable/c/b308fdedef095aac14569f810d46edf773ea7d1e","https://git.kernel.org/stable/c/d34742245e4366579f9a80f8cfe4a63248e838e0"],"published_time":"2025-10-07T16:15:37","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50522","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmcb: mcb-parse: fix error handing in chameleon_parse_gdd()\n\nIf mcb_device_register() returns error in chameleon_parse_gdd(), the refcount\nof bus and device name are leaked. Fix this by calling put_device() to give up\nthe reference, so they can be released in mcb_release_dev() and kobject_cleanup().","cvss":3.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":3.3,"epss":0.00015,"ranking_epss":0.03007,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/110dc34c9fa33d37f55b394b1199ea6c0ad1ee84","https://git.kernel.org/stable/c/43bfc7c2402a22d3b4eb08c040f274ba2b76461a","https://git.kernel.org/stable/c/4a9f1a8b3af287581ffb690d0e1593c681729ddb","https://git.kernel.org/stable/c/728ac3389296caf68638628c987aeae6c8851e2d","https://git.kernel.org/stable/c/7b289b791a59386dc23a00d3cf17a0db984b40d3","https://git.kernel.org/stable/c/891f606ae0765bc9ca99f5276735be4d338f0255","https://git.kernel.org/stable/c/b948baa29394ec5f4e6ec28486e7d06a76caee91","https://git.kernel.org/stable/c/cf6e70c0ced50b52415ac0c88eba1fb09c500a5a","https://git.kernel.org/stable/c/fd85ece416fd7edb945203e59d4cd94952f77e7c"],"published_time":"2025-10-07T16:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50523","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nclk: rockchip: Fix memory leak in rockchip_clk_register_pll()\n\nIf clk_register() fails, @pll->rate_table may have allocated memory by\nkmemdup(), so it needs to be freed, otherwise will cause memory leak\nissue, this patch fixes it.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/20201c3a0a32f127fa4bdf379d6ac01c2978702d","https://git.kernel.org/stable/c/26b94635f1c84d7f6cb482179125cb17e59c90a5","https://git.kernel.org/stable/c/5b0a1f1247cd42ac5e0d369f8dbb58762692edee","https://git.kernel.org/stable/c/739a6a6bbdb793bd57938cb24aa5a6df89983546","https://git.kernel.org/stable/c/86e1e080ad14c5fb6c14a5f0eb530b1b38cbc968","https://git.kernel.org/stable/c/dcd4ba068b194c6ef0071491aa3f12bec8c14d5b","https://git.kernel.org/stable/c/f02c1d8dc8d880cbaaf9094b4f396fe868ee23ff","https://git.kernel.org/stable/c/f2ffb8653ea85ae39ce44347751fcc4c3e41f6bb","https://git.kernel.org/stable/c/f4d70c139d313948e02360304a6cbcd3a4f5deb5"],"published_time":"2025-10-07T16:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50524","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/mediatek: Check return value after calling platform_get_resource()\n\nplatform_get_resource() may return NULL pointer, we need check its\nreturn value to avoid null-ptr-deref in resource_size().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/73b6924cdebc899de9b719e1319aa86c6bed4acf","https://git.kernel.org/stable/c/bfebf05883cdcf9ac983033987fae869bd59ca53","https://git.kernel.org/stable/c/feca904412483b2e0a903dd1f2e2843afd445f8c"],"published_time":"2025-10-07T16:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50525","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/fsl_pamu: Fix resource leak in fsl_pamu_probe()\n\nThe fsl_pamu_probe() returns directly when create_csd() failed, leaving\nirq and memories unreleased.\nFix by jumping to error if create_csd() returns error.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d240ac0e4c35d3f64fc782c11433138c1bd016e","https://git.kernel.org/stable/c/17fd440594961c5e2ea0f58591bc1bdba0629c75","https://git.kernel.org/stable/c/73f5fc5f884ad0c5f7d57f66303af64f9f002526","https://git.kernel.org/stable/c/9238b687fd62cde14c6e2e8576a40e4246de7ebe","https://git.kernel.org/stable/c/9fbccdf2fefa3944dd8ba8c6a808b387787f3917","https://git.kernel.org/stable/c/a305d0e4d0ce3166e31d7dbcb4c98b09cad6d49a","https://git.kernel.org/stable/c/c93983230562883e0b5f122040efbb3d478c36d4","https://git.kernel.org/stable/c/de7eb55009796687fc0a1670e0b944fa8ed54e9b","https://git.kernel.org/stable/c/e42b543d08052c3b223bcfb48f05cbaf0b767f86"],"published_time":"2025-10-07T16:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50526","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: fix memory corruption with too many bridges\n\nAdd the missing sanity check on the bridge counter to avoid corrupting\ndata beyond the fixed-sized bridge array in case there are ever more\nthan eight bridges.\n\nPatchwork: https://patchwork.freedesktop.org/patch/502664/","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00022,"ranking_epss":0.05811,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/74466e46e7543c7f74f1502181e9ba93f7521374","https://git.kernel.org/stable/c/b312fcab461bd9484c61409007a6fe059f9c2074"],"published_time":"2025-10-07T16:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50527","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix size validation for non-exclusive domains (v4)\n\nFix amdgpu_bo_validate_size() to check whether the TTM domain manager for the\nrequested memory exists, else we get a kernel oops when dereferencing \"man\".\n\nv2: Make the patch standalone, i.e. not dependent on local patches.\nv3: Preserve old behaviour and just check that the manager pointer is not\n    NULL.\nv4: Complain if GTT domain requested and it is uninitialized--most likely a\n    bug.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7554886daa31eacc8e7fac9e15bbce67d10b8f1f","https://git.kernel.org/stable/c/80546eef216854a7bd47e39e828f04b406c00599","https://git.kernel.org/stable/c/8ba7c55e112f4ffd2a95b99be1cb1c891ef08ba1"],"published_time":"2025-10-07T16:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50528","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix memory leakage\n\nThis patch fixes potential memory leakage and seg fault\nin  _gpuvm_import_dmabuf() function","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/7356d8e367d0e025a568e369c4cf575722cac60f","https://git.kernel.org/stable/c/75818afff631e1ea785a82c3e8bb82eb0dee539c","https://git.kernel.org/stable/c/8876793e56ec69b3be2a883b4bc440df3dbb1865","https://git.kernel.org/stable/c/c65564790048fa416ccd26a8945c7ec0cf9ef0b7"],"published_time":"2025-10-07T16:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50529","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntest_firmware: fix memory leak in test_firmware_init()\n\nWhen misc_register() failed in test_firmware_init(), the memory pointed\nby test_fw_config->name is not released. The memory leak information is\nas follows:\nunreferenced object 0xffff88810a34cb00 (size 32):\n  comm \"insmod\", pid 7952, jiffies 4294948236 (age 49.060s)\n  hex dump (first 32 bytes):\n    74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69  test-firmware.bi\n    6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  n...............\n  backtrace:\n    [<ffffffff81b21fcb>] __kmalloc_node_track_caller+0x4b/0xc0\n    [<ffffffff81affb96>] kstrndup+0x46/0xc0\n    [<ffffffffa0403a49>] __test_firmware_config_init+0x29/0x380 [test_firmware]\n    [<ffffffffa040f068>] 0xffffffffa040f068\n    [<ffffffff81002c41>] do_one_initcall+0x141/0x780\n    [<ffffffff816a72c3>] do_init_module+0x1c3/0x630\n    [<ffffffff816adb9e>] load_module+0x623e/0x76a0\n    [<ffffffff816af471>] __do_sys_finit_module+0x181/0x240\n    [<ffffffff89978f99>] do_syscall_64+0x39/0xb0\n    [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/04dd47a2e169f2d4489636afa07ff0469aab49ab","https://git.kernel.org/stable/c/0b5a89e8bce1ea43687742b4de8e216189ff94ac","https://git.kernel.org/stable/c/357379d504c0c8b0834e206ad8c49e4b3c98ed4d","https://git.kernel.org/stable/c/628de998a3abfffb3f9677d2fb39a1d5dcb32fdb","https://git.kernel.org/stable/c/6dd5fbd243f19f087dc79481acb7d69fb57fea2c","https://git.kernel.org/stable/c/7610615e8cdb3f6f5bbd9d8e7a5d8a63e3cabf2e","https://git.kernel.org/stable/c/8d8c1d6a430f0aadb80036e2b1bc0a05f9fad247","https://git.kernel.org/stable/c/ed5cbafaf7ce8b86f19998c00eb020c8d49b017f"],"published_time":"2025-10-07T16:15:36","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50515","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue()\n\nIf construction of the array of work queues to handle hpd_rx_irq offload\nwork fails, we need to unwind. Destroy all the created workqueues and\nthe allocated memory for the hpd_rx_irq_offload_work_queue struct array.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3ba3814c00a4817eb1cd31eff08d921c40e5f3a4","https://git.kernel.org/stable/c/600de40ed50c8b5ecb9c7a4f41eb882066c15a00","https://git.kernel.org/stable/c/7136f956c73c4ba50bfeb61653dfd6a9669ea915","https://git.kernel.org/stable/c/8b8da09da2701330e7f2c371655887e3d7defe90"],"published_time":"2025-10-07T16:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50516","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs: dlm: fix invalid derefence of sb_lvbptr\n\nI experience issues when putting a lkbsb on the stack and have sb_lvbptr\nfield to a dangled pointer while not using DLM_LKF_VALBLK. It will crash\nwith the following kernel message, the dangled pointer is here\n0xdeadbeef as example:\n\n[  102.749317] BUG: unable to handle page fault for address: 00000000deadbeef\n[  102.749320] #PF: supervisor read access in kernel mode\n[  102.749323] #PF: error_code(0x0000) - not-present page\n[  102.749325] PGD 0 P4D 0\n[  102.749332] Oops: 0000 [#1] PREEMPT SMP PTI\n[  102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G        W         5.19.0-rc3+ #1565\n[  102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014\n[  102.749344] RIP: 0010:memcpy_erms+0x6/0x10\n[  102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe\n[  102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202\n[  102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040\n[  102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070\n[  102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001\n[  102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70\n[  102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001\n[  102.749368] FS:  0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000\n[  102.749372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0\n[  102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  102.749379] PKRU: 55555554\n[  102.749381] Call Trace:\n[  102.749382]  <TASK>\n[  102.749383]  ? send_args+0xb2/0xd0\n[  102.749389]  send_common+0xb7/0xd0\n[  102.749395]  _unlock_lock+0x2c/0x90\n[  102.749400]  unlock_lock.isra.56+0x62/0xa0\n[  102.749405]  dlm_unlock+0x21e/0x330\n[  102.749411]  ? lock_torture_stats+0x80/0x80 [dlm_locktorture]\n[  102.749416]  torture_unlock+0x5a/0x90 [dlm_locktorture]\n[  102.749419]  ? preempt_count_sub+0xba/0x100\n[  102.749427]  lock_torture_writer+0xbd/0x150 [dlm_locktorture]\n[  102.786186]  kthread+0x10a/0x130\n[  102.786581]  ? kthread_complete_and_exit+0x20/0x20\n[  102.787156]  ret_from_fork+0x22/0x30\n[  102.787588]  </TASK>\n[  102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw\n[  102.792536] CR2: 00000000deadbeef\n[  102.792930] ---[ end trace 0000000000000000 ]---\n\nThis patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags\nis set when copying the lvbptr array instead of if it's just null which\nfixes for me the issue.\n\nI think this patch can fix other dlm users as well, depending how they\nhandle the init, freeing memory handling of sb_lvbptr and don't set\nDLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a\nhidden issue all the time. However with checking on DLM_LKF_VALBLK the\nuser always need to provide a sb_lvbptr non-null value. There might be\nmore intelligent handling between per ls lvblen, DLM_LKF_VALBLK and\nnon-null to report the user the way how DLM API is used is wrong but can\nbe added for later, this will only fix the current behaviour.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00021,"ranking_epss":0.05711,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1ab6d3030652b5de0015176a5b0ad9df9b847514","https://git.kernel.org/stable/c/57c1cfb5781068e5d3632bc6e5f74a8fcc4f1a30","https://git.kernel.org/stable/c/7175e131ebba47afef47e6ac4d5bab474d1e6e49","https://git.kernel.org/stable/c/ea7be82fd7e1f5de72208bce93fbbe6de6c13dec","https://git.kernel.org/stable/c/ef3033b435a6bac547166b793025578fab2f9df3"],"published_time":"2025-10-07T16:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50517","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: do not clobber swp_entry_t during THP split\n\nThe following has been observed when running stressng mmap since commit\nb653db77350c (\"mm: Clear page->private when splitting or migrating a page\")\n\n   watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546]\n   CPU: 75 PID: 9546 Comm: stress-ng Tainted: G            E      6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374\n   Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016\n   RIP: 0010:xas_descend+0x28/0x80\n   Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2\n   RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246\n   RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002\n   RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0\n   RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0\n   R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000\n   R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88\n   FS:  00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000\n   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n   CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0\n   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n   Call Trace:\n    <TASK>\n    xas_load+0x3a/0x50\n    __filemap_get_folio+0x80/0x370\n    ? put_swap_page+0x163/0x360\n    pagecache_get_page+0x13/0x90\n    __try_to_reclaim_swap+0x50/0x190\n    scan_swap_map_slots+0x31e/0x670\n    get_swap_pages+0x226/0x3c0\n    folio_alloc_swap+0x1cc/0x240\n    add_to_swap+0x14/0x70\n    shrink_page_list+0x968/0xbc0\n    reclaim_page_list+0x70/0xf0\n    reclaim_pages+0xdd/0x120\n    madvise_cold_or_pageout_pte_range+0x814/0xf30\n    walk_pgd_range+0x637/0xa30\n    __walk_page_range+0x142/0x170\n    walk_page_range+0x146/0x170\n    madvise_pageout+0xb7/0x280\n    ? asm_common_interrupt+0x22/0x40\n    madvise_vma_behavior+0x3b7/0xac0\n    ? find_vma+0x4a/0x70\n    ? find_vma+0x64/0x70\n    ? madvise_vma_anon_name+0x40/0x40\n    madvise_walk_vmas+0xa6/0x130\n    do_madvise+0x2f4/0x360\n    __x64_sys_madvise+0x26/0x30\n    do_syscall_64+0x5b/0x80\n    ? do_syscall_64+0x67/0x80\n    ? syscall_exit_to_user_mode+0x17/0x40\n    ? do_syscall_64+0x67/0x80\n    ? syscall_exit_to_user_mode+0x17/0x40\n    ? do_syscall_64+0x67/0x80\n    ? do_syscall_64+0x67/0x80\n    ? common_interrupt+0x8b/0xa0\n    entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe problem can be reproduced with the mmtests config\nconfig-workload-stressng-mmap.  It does not always happen and when it\ntriggers is variable but it has happened on multiple machines.\n\nThe intent of commit b653db77350c patch was to avoid the case where\nPG_private is clear but folio->private is not-NULL.  However, THP tail\npages uses page->private for \"swp_entry_t if folio_test_swapcache()\" as\nstated in the documentation for struct folio.  This patch only clobbers\npage->private for tail pages if the head page was not in swapcache and\nwarns once if page->private had an unexpected value.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/71e2d666ef85d51834d658830f823560c402b8b6","https://git.kernel.org/stable/c/8cace0eeb03d6043827faa6cf6c9067a9f05cd9f"],"published_time":"2025-10-07T16:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50518","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix locking in pdc_iodc_print() firmware call\n\nUtilize pdc_lock spinlock to protect parallel modifications of the\niodc_dbuf[] buffer, check length to prevent buffer overflow of\niodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong\nindentings.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.0001,"ranking_epss":0.01016,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/04a603058e70b8b881bb7860b8bd649f931f2591","https://git.kernel.org/stable/c/553bc5890ed96a8d006224c3a4673c47fee0d12a","https://git.kernel.org/stable/c/7236aae5f81f3efbd93d0601e74fc05994bc2580"],"published_time":"2025-10-07T16:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50519","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure\n\nIf creation or finalization of a checkpoint fails due to anomalies in the\ncheckpoint metadata on disk, a kernel warning is generated.\n\nThis patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted\nwith panic_on_warn, does not panic.  A nilfs_error is appropriate here to\nhandle the abnormal filesystem condition.\n\nThis also replaces the detected error codes with an I/O error so that\nneither of the internal error codes is returned to callers.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/090fcfb6edeb9367a915b2749e2bd1f8b48d8898","https://git.kernel.org/stable/c/259c0f68168ac6a598db3486597b10e74d625db0","https://git.kernel.org/stable/c/5c0776b5bc31de7cd28afb558fae37a20f33602e","https://git.kernel.org/stable/c/723ac751208f6d6540191689cfbf6c77135a7a1b","https://git.kernel.org/stable/c/8a18fdc5ae8e6d7ac33c6ee0a2e5f9f1414ef412","https://git.kernel.org/stable/c/ae16440c44ae2acda6d72aff9d74eccf8967dae5","https://git.kernel.org/stable/c/b63026b5e13040cd5afa11769dd0d9e1504b031a","https://git.kernel.org/stable/c/bf98be80cbe3b4e6c86c36ed00457389aca3eb15","https://git.kernel.org/stable/c/c0c3d3d3ea41cb5228ee90568bb953f9a56c3227"],"published_time":"2025-10-07T16:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50520","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()\n\nAs comment of pci_get_class() says, it returns a pci_device with its\nrefcount increased and decreased the refcount for the input parameter\n@from if it is not NULL.\n\nIf we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, we\nneed to call pci_dev_put() to decrease the refcount. Add the missing\npci_dev_put() to avoid refcount leak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1079df6acf56f99d86b0081a38c84701412cc90e","https://git.kernel.org/stable/c/3991d98a8a07b71c02f3a39f77d6d9a7f575a5c4","https://git.kernel.org/stable/c/470a77989037c3ab2b08bf2d026d2c0ddc35ff5b","https://git.kernel.org/stable/c/6f28c7f67af4ef9bca580ab67ae2d4511797af56","https://git.kernel.org/stable/c/725a521a18734f65de05b8d353b5bd0d3ca4c37a","https://git.kernel.org/stable/c/88c6e0995c04b170563b5c894c50a3b2152e18c2","https://git.kernel.org/stable/c/a6cffe54064a5f6c2162a85af3c16c6b453eac4e","https://git.kernel.org/stable/c/b9decada8749b606fd8b4f04a3d6c74f7983d7bc","https://git.kernel.org/stable/c/e738f82e5b1311e8fb3d1409491a6fcce6418fbe"],"published_time":"2025-10-07T16:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50521","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]()\n\nThe ACPI buffer memory (out.pointer) returned by wmi_evaluate_method()\nis not freed after the call, so it leads to memory leak.\n\nThe method results in ACPI buffer is not used, so just pass NULL to\nwmi_evaluate_method() which fixes the memory leak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/14bb4bde3b7b2584734b13747b345caeeb41bea3","https://git.kernel.org/stable/c/17cd8c46cbec4e6ad593fb9159928b8e7608c11a","https://git.kernel.org/stable/c/379e7794c5e7485193d25d73614fbbd1e1387f6f","https://git.kernel.org/stable/c/3cf81501356c9e898ad94b2369ffc805f83f7d7b","https://git.kernel.org/stable/c/50ac517d6f5348b276f1f663799cf85dce521518","https://git.kernel.org/stable/c/5b0f81b0808235967868e01336c976e840217108","https://git.kernel.org/stable/c/727cc0147f5066e359aca65cc6cc5e6d64cc15d8","https://git.kernel.org/stable/c/87426ce3bd57ad414b6e2436434ef8128986a9a5"],"published_time":"2025-10-07T16:15:35","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50510","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nperf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init()\n\narm_smmu_pmu_init() won't remove the callback added by\ncpuhp_setup_state_multi() when platform_driver_register() failed. Remove\nthe callback by cpuhp_remove_multi_state() in fail path.\n\nSimilar to the handling of arm_ccn_init() in commit 26242b330093 (\"bus:\narm-ccn: Prevent hotplug callback leak\")","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/359286f886feef38536eaa7e673dc3440f03b0a1","https://git.kernel.org/stable/c/582babe17ea878ec1d76f30e03f3a6ce6e30eb91","https://git.kernel.org/stable/c/6f2d566b46436a50a80d6445e82879686b89588c","https://git.kernel.org/stable/c/b131304fe722853cf26e55c4fa21fc58a36e7f21","https://git.kernel.org/stable/c/d69bdb61d577297d3851fc9f6403574bf73ef41f","https://git.kernel.org/stable/c/f245ca9a0fe7f794a8187ad803d5e2ced5a11cb2"],"published_time":"2025-10-07T16:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50511","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nlib/fonts: fix undefined behavior in bit shift for get_default_font\n\nShifting signed 32-bit value by 31 bits is undefined, so changing\nsignificant bit to unsigned.  The UBSAN warning calltrace like below:\n\nUBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20\nleft shift of 1 by 31 places cannot be represented in type 'int'\n <TASK>\n dump_stack_lvl+0x7d/0xa5\n dump_stack+0x15/0x1b\n ubsan_epilogue+0xe/0x4e\n __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c\n get_default_font+0x1c7/0x1f0\n fbcon_startup+0x347/0x3a0\n do_take_over_console+0xce/0x270\n do_fbcon_takeover+0xa1/0x170\n do_fb_registered+0x2a8/0x340\n fbcon_fb_registered+0x47/0xe0\n register_framebuffer+0x294/0x4a0\n __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]\n drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]\n drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]\n drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]\n bochs_pci_probe+0x6ca/0x772 [bochs]\n local_pci_probe+0x4d/0xb0\n pci_device_probe+0x119/0x320\n really_probe+0x181/0x550\n __driver_probe_device+0xc6/0x220\n driver_probe_device+0x32/0x100\n __driver_attach+0x195/0x200\n bus_for_each_dev+0xbb/0x120\n driver_attach+0x27/0x30\n bus_add_driver+0x22e/0x2f0\n driver_register+0xa9/0x190\n __pci_register_driver+0x90/0xa0\n bochs_pci_driver_init+0x52/0x1000 [bochs]\n do_one_initcall+0x76/0x430\n do_init_module+0x61/0x28a\n load_module+0x1f82/0x2e50\n __do_sys_finit_module+0xf8/0x190\n __x64_sys_finit_module+0x23/0x30\n do_syscall_64+0x58/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n </TASK>","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6fe888c4d2fb174408e4540bb2d5602b9f507f90","https://git.kernel.org/stable/c/890d91b31f4874361e0df047f57d268a7021cb12","https://git.kernel.org/stable/c/9c14a85e18a58c102ec223144b7edb5b345c1bea","https://git.kernel.org/stable/c/c9a9aa02f0fa3318e0ae5774f404419a1b4759ca","https://git.kernel.org/stable/c/e039929e36818507e90901edae87f6fa8bc81093","https://git.kernel.org/stable/c/e83b47580a0738361772d6f24286adfdaba57e36"],"published_time":"2025-10-07T16:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50512","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential memory leak in ext4_fc_record_regions()\n\nAs krealloc may return NULL, in this case 'state->fc_regions' may not be\nfreed by krealloc, but 'state->fc_regions' already set NULL. Then will\nlead to 'state->fc_regions' memory leak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2cfb769d60a2a57eb3566765428b6131cd16dcfe","https://git.kernel.org/stable/c/417b0455a0b6d0f60a2930592731d1f8340e24be","https://git.kernel.org/stable/c/518566e71ad86b7c2f1bf6d9caee9588bb7ac158","https://git.kernel.org/stable/c/7069d105c1f15c442b68af43f7fde784f3126739","https://git.kernel.org/stable/c/a4058b869e6c5e517c79e30532a350d0f3115c3e"],"published_time":"2025-10-07T16:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50513","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()\n\nIn rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocated\nin failure, then `pcmdpriv->cmd_allocated_buf` will be not properly\nreleased. Besides, considering there are only two error paths and the\nfirst one can directly return, so we do not need implicitly jump to the\n`exit` tag to execute the error handler.\n\nSo this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the error\npath to release the resource and simplified the return logic of\nrtw_init_cmd_priv(). As there is no proper device to test with, no runtime\ntesting was performed.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02821,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/39bef9c6a91bbb790d04c1347cfeae584541fb6a","https://git.kernel.org/stable/c/708056fba733a73d926772ea4ce9a42d240345da","https://git.kernel.org/stable/c/8db6ca84eee0ac258706f3fca54f7c021cb159ef","https://git.kernel.org/stable/c/a5be64ff6d21f7805a91e6d81f53fc19cd9f0fae","https://git.kernel.org/stable/c/e5d8f05edb36fc4ab15beec62cb6ab62f5a60fe2","https://git.kernel.org/stable/c/e6cc39db24a63f68314473621020ed8cad7be423"],"published_time":"2025-10-07T16:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50514","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_hid: fix refcount leak on error path\n\nWhen failing to allocate report_desc, opts->refcnt has already been\nincremented so it needs to be decremented to avoid leaving the options\nstructure permanently locked.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/216437dd64fce36791a3b6cc8f8013df36856958","https://git.kernel.org/stable/c/70a3288a7586526315105c699b687d78cd32559a","https://git.kernel.org/stable/c/80dc47e751a837106c09bec73964ff8f7ea280b4","https://git.kernel.org/stable/c/95412c932b3c9e8cc4431dac4fac8fcd80d54982","https://git.kernel.org/stable/c/9d4a0aca8a75550d3456c8de339a341dc4536ec5","https://git.kernel.org/stable/c/ba78f7c10606719f702c04a15fb0471507b32d7b","https://git.kernel.org/stable/c/e88b89a096af0001bcff6bf7ad2feb1486487173"],"published_time":"2025-10-07T16:15:34","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50509","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: coda: Add check for kmalloc\n\nAs the kmalloc may return NULL pointer,\nit should be better to check the return value\nin order to avoid NULL poineter dereference,\nsame as the others.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0209e70ad496c1fcd85c2ec70e6736fd09f95d14","https://git.kernel.org/stable/c/11e32126b3e56c3156fb610d793732acd2bdac4f","https://git.kernel.org/stable/c/441c05485cf1a29eef05c1fd8281716815283315","https://git.kernel.org/stable/c/6e5e5defdb8b0186312c2f855ace175aee6daf9b","https://git.kernel.org/stable/c/7a2c66429b04e85fee44d6d9f455327bf23cf49c","https://git.kernel.org/stable/c/aa17a252dbde432095e390e2092205d4debb12e1","https://git.kernel.org/stable/c/ba9cc9e2035f7a45f5222543265daf7cd51f2530","https://git.kernel.org/stable/c/d308c4a035b636756786af91e5f39f9d92d7d42a","https://git.kernel.org/stable/c/d9b37ea8869e4e6da90c07a310d819a78cbd23d2"],"published_time":"2025-10-07T16:15:33","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53613","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndax: Fix dax_mapping_release() use after free\n\nA CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax region\nprovider (like modprobe -r dax_hmem) yields:\n\n kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000)\n [..]\n DEBUG_LOCKS_WARN_ON(1)\n WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260\n [..]\n RIP: 0010:__lock_acquire+0x9fc/0x2260\n [..]\n Call Trace:\n  <TASK>\n [..]\n  lock_acquire+0xd4/0x2c0\n  ? ida_free+0x62/0x130\n  _raw_spin_lock_irqsave+0x47/0x70\n  ? ida_free+0x62/0x130\n  ida_free+0x62/0x130\n  dax_mapping_release+0x1f/0x30\n  device_release+0x36/0x90\n  kobject_delayed_cleanup+0x46/0x150\n\nDue to attempting ida_free() on an ida object that has already been\nfreed. Devices typically only hold a reference on their parent while\nregistered. If a child needs a parent object to complete its release it\nneeds to hold a reference that it drops from its release callback.\nArrange for a dax_mapping to pin its parent dev_dax instance until\ndax_mapping_release().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03859868ab82d57bfdd0cea1bf31f9319a5dded0","https://git.kernel.org/stable/c/6d24b170a9db0456f577b1ab01226a2254c016a8","https://git.kernel.org/stable/c/7310b84821f043dcf77d5e6aa0ad55dc1e10a11d","https://git.kernel.org/stable/c/94a85474f5e3e518bdbf8c9f51cb343d734a04f7","https://git.kernel.org/stable/c/9c2f993b6ca903c030d58451b5bf9ea27d0d17fa","https://git.kernel.org/stable/c/f76db6781d76d8464ec2faa9752cc3fb2e4f6923"],"published_time":"2025-10-04T16:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53614","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix race with VMA iteration and mm_struct teardown\n\nexit_mmap() will tear down the VMAs and maple tree with the mmap_lock held\nin write mode.  Ensure that the maple tree is still valid by checking\nksm_test_exit() after taking the mmap_lock in read mode, but before the\nfor_each_vma() iterator dereferences a destroyed maple tree.\n\nSince the maple tree is destroyed, the flags telling lockdep to check an\nexternal lock has been cleared.  Skip the for_each_vma() iterator to avoid\ndereferencing a maple tree without the external lock flag, which would\ncreate a lockdep warning.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.0001,"ranking_epss":0.01008,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/286b0cab31bac29960e5684f6fb331d42f03b363","https://git.kernel.org/stable/c/6db504ce55bdbc575723938fc480713c9183f6a2","https://git.kernel.org/stable/c/b4f664ffd8f78c05a1fd542a28bc5a11e994c014"],"published_time":"2025-10-04T16:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53615","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix deletion race condition\n\nSystem crash when using debug kernel due to link list corruption. The cause\nof the link list corruption is due to session deletion was allowed to queue\nup twice.  Here's the internal trace that show the same port was allowed to\ndouble queue for deletion on different cpu.\n\n20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1\n20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1\n\nMove the clearing/setting of deleted flag lock.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00012,"ranking_epss":0.01473,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4d7da12483e98c451a51bd294a3d3494f0aee5eb","https://git.kernel.org/stable/c/6dfe4344c168c6ca20fe7640649aacfcefcccb26","https://git.kernel.org/stable/c/a4628a5b98e4c6d905e1f7638242612d7db7d9c2","https://git.kernel.org/stable/c/b05017cb4ff75eea783583f3d400059507510ab1","https://git.kernel.org/stable/c/cd06c45b326e44f0d21dc1b3fa23e71f46847e28","https://git.kernel.org/stable/c/f1ea164be545629bf442c22f508ad9e7b94ac100"],"published_time":"2025-10-04T16:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53616","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix invalid free of JFS_IP(ipimap)->i_imap in diUnmount\n\nsyzbot found an invalid-free in diUnmount:\n\nBUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]\nBUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674\nFree of addr ffff88806f410000 by task syz-executor131/3632\n\n CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\n Call Trace:\n  <TASK>\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106\n  print_address_description+0x74/0x340 mm/kasan/report.c:284\n  print_report+0x107/0x1f0 mm/kasan/report.c:395\n  kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460\n  ____kasan_slab_free+0xfb/0x120\n  kasan_slab_free include/linux/kasan.h:177 [inline]\n  slab_free_hook mm/slub.c:1724 [inline]\n  slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750\n  slab_free mm/slub.c:3661 [inline]\n  __kmem_cache_free+0x71/0x110 mm/slub.c:3674\n  diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195\n  jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63\n  jfs_put_super+0x86/0x190 fs/jfs/super.c:194\n  generic_shutdown_super+0x130/0x310 fs/super.c:492\n  kill_block_super+0x79/0xd0 fs/super.c:1428\n  deactivate_locked_super+0xa7/0xf0 fs/super.c:332\n  cleanup_mnt+0x494/0x520 fs/namespace.c:1186\n  task_work_run+0x243/0x300 kernel/task_work.c:179\n  exit_task_work include/linux/task_work.h:38 [inline]\n  do_exit+0x664/0x2070 kernel/exit.c:820\n  do_group_exit+0x1fd/0x2b0 kernel/exit.c:950\n  __do_sys_exit_group kernel/exit.c:961 [inline]\n  __se_sys_exit_group kernel/exit.c:959 [inline]\n  __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959\n  do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[...]\n\nJFS_IP(ipimap)->i_imap is not setting to NULL after free in diUnmount.\nIf jfs_remount() free JFS_IP(ipimap)->i_imap but then failed at diMount().\nJFS_IP(ipimap)->i_imap will be freed once again.\nFix this problem by setting JFS_IP(ipimap)->i_imap to NULL after free.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/114ea3cb13ab25f7178cb60283adb93d2f96dad7","https://git.kernel.org/stable/c/4de3a603010e0ca334487de24c6aab0777b7f808","https://git.kernel.org/stable/c/5873df0195124be2f357de11bfd473ead4f90ed8","https://git.kernel.org/stable/c/6e2bda2c192d0244b5a78b787ef20aa10cb319b7","https://git.kernel.org/stable/c/756747d4b439e3e1159282ae89f17eefebbe9b25","https://git.kernel.org/stable/c/88484bde6f12126616b38e43b6c00edcd941f615","https://git.kernel.org/stable/c/c3c0f0ddd851b3fa3e9d3450bbcd561f4f850469","https://git.kernel.org/stable/c/ef7311101ca43dd73b45bca7a30ac72d9535ff87"],"published_time":"2025-10-04T16:15:58","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53604","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndm integrity: call kmem_cache_destroy() in dm_integrity_init() error path\n\nOtherwise the journal_io_cache will leak if dm_register_target() fails.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3877b5c1509b16eeb1f275228fd91789cd88cf17","https://git.kernel.org/stable/c/44f29e93a55b544dc961b6f8b4e93abaeaafb9ee","https://git.kernel.org/stable/c/6b79a428c02769f2a11f8ae76bf866226d134887","https://git.kernel.org/stable/c/6d126899b0747305c9d39a0bcf87e0df9c3f555b","https://git.kernel.org/stable/c/a5d8c6bf58e5b2e70fbc15f3b08dfc1ba6f269ac","https://git.kernel.org/stable/c/c8c9c50268729bf35f6c9bb1205f490db920454e","https://git.kernel.org/stable/c/ca8b634fdf07dee3f6dfde57079c4511480b525e","https://git.kernel.org/stable/c/e09a592fdd6c716506774bdbebb5f6c537b47767","https://git.kernel.org/stable/c/ff4d6b5b38429a7731e5593680d2138bf74dd546"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53605","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: amd: display: Fix memory leakage\n\nThis commit fixes memory leakage in dc_construct_ctx() function.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1bdea8ee92a6abc650b2189fd5c53f36859baecb","https://git.kernel.org/stable/c/6b8701be1f66064ca72733c5f6e13748cdbf8397","https://git.kernel.org/stable/c/83ace0dd67ee386be1ddcf59dab49d6d9a54e62e","https://git.kernel.org/stable/c/9ae15ebaefc4878d614f10cc56ea672f88cea582","https://git.kernel.org/stable/c/d473c55ce1975c9e601c25293328a5039225d2b2"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53606","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: clean up potential nfsd_file refcount leaks in COPY codepath\n\nThere are two different flavors of the nfsd4_copy struct. One is\nembedded in the compound and is used directly in synchronous copies. The\nother is dynamically allocated, refcounted and tracked in the client\nstruture. For the embedded one, the cleanup just involves releasing any\nnfsd_files held on its behalf. For the async one, the cleanup is a bit\nmore involved, and we need to dequeue it from lists, unhash it, etc.\n\nThere is at least one potential refcount leak in this code now. If the\nkthread_create call fails, then both the src and dst nfsd_files in the\noriginal nfsd4_copy object are leaked.\n\nThe cleanup in this codepath is also sort of weird. In the async copy\ncase, we'll have up to four nfsd_file references (src and dst for both\nflavors of copy structure). They are both put at the end of\nnfsd4_do_async_copy, even though the ones held on behalf of the embedded\none outlive that structure.\n\nChange it so that we always clean up the nfsd_file refs held by the\nembedded copy structure before nfsd4_copy returns. Rework\ncleanup_async_copy to handle both inter and intra copies. Eliminate\nnfsd4_cleanup_intra_ssc since it now becomes a no-op.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6ba434cb1a8d403ea9aad1b667c3ea3ad8b3191f","https://git.kernel.org/stable/c/75b8c681c563ef7e85da6862354efc18d2a08b1b","https://git.kernel.org/stable/c/8f565846fbe8182961498d4cbe618b15076a683b","https://git.kernel.org/stable/c/b3169b6ffe036b549c296a9e71591d29a1fb3209","https://git.kernel.org/stable/c/fd63299db8090307eae66f2aef17c8f00aafa0a9"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53607","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ymfpci: Fix BUG_ON in probe function\n\nThe snd_dma_buffer.bytes field now contains the aligned size, which this\nsnd_BUG_ON() did not account for, resulting in the following:\n\n[    9.625915] ------------[ cut here ]------------\n[    9.633440] WARNING: CPU: 0 PID: 126 at sound/pci/ymfpci/ymfpci_main.c:2168 snd_ymfpci_create+0x681/0x698 [snd_ymfpci]\n[    9.648926] Modules linked in: snd_ymfpci(+) snd_intel_dspcfg kvm(+) snd_intel_sdw_acpi snd_ac97_codec snd_mpu401_uart snd_opl3_lib irqbypass snd_hda_codec gameport snd_rawmidi crct10dif_pclmul crc32_pclmul cfg80211 snd_hda_core polyval_clmulni polyval_generic gf128mul snd_seq_device ghash_clmulni_intel snd_hwdep ac97_bus sha512_ssse3 rfkill snd_pcm aesni_intel tg3 snd_timer crypto_simd snd mxm_wmi libphy cryptd k10temp fam15h_power pcspkr soundcore sp5100_tco wmi acpi_cpufreq mac_hid dm_multipath sg loop fuse dm_mod bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi firewire_ohci crc32c_intel firewire_core xhci_pci crc_itu_t pata_via xhci_pci_renesas floppy\n[    9.711849] CPU: 0 PID: 126 Comm: kworker/0:2 Not tainted 6.1.21-1-lts #1 08d2e5ece03136efa7c6aeea9a9c40916b1bd8da\n[    9.722200] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./990FX Extreme4, BIOS P2.70 06/05/2014\n[    9.732204] Workqueue: events work_for_cpu_fn\n[    9.736580] RIP: 0010:snd_ymfpci_create+0x681/0x698 [snd_ymfpci]\n[    9.742594] Code: 8c c0 4c 89 e2 48 89 df 48 c7 c6 92 c6 8c c0 e8 15 d0 e9 ff 48 83 c4 08 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d3 7a 33 e3 <0f> 0b e9 cb fd ff ff 41 bd fb ff ff ff eb db 41 bd f4 ff ff ff eb\n[    9.761358] RSP: 0018:ffffab64804e7da0 EFLAGS: 00010287\n[    9.766594] RAX: ffff8fa2df06c400 RBX: ffff8fa3073a8000 RCX: ffff8fa303fbc4a8\n[    9.773734] RDX: ffff8fa2df06d000 RSI: 0000000000000010 RDI: 0000000000000020\n[    9.780876] RBP: ffff8fa300b5d0d0 R08: ffff8fa3073a8e50 R09: 00000000df06bf00\n[    9.788018] R10: ffff8fa2df06bf00 R11: 00000000df068200 R12: ffff8fa3073a8918\n[    9.795159] R13: 0000000000000000 R14: 0000000000000080 R15: ffff8fa2df068200\n[    9.802317] FS:  0000000000000000(0000) GS:ffff8fa9fec00000(0000) knlGS:0000000000000000\n[    9.810414] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    9.816158] CR2: 000055febaf66500 CR3: 0000000101a2e000 CR4: 00000000000406f0\n[    9.823301] Call Trace:\n[    9.825747]  <TASK>\n[    9.827889]  snd_card_ymfpci_probe+0x194/0x950 [snd_ymfpci b78a5fe64b5663a6390a909c67808567e3e73615]\n[    9.837030]  ? finish_task_switch.isra.0+0x90/0x2d0\n[    9.841918]  local_pci_probe+0x45/0x80\n[    9.845680]  work_for_cpu_fn+0x1a/0x30\n[    9.849431]  process_one_work+0x1c7/0x380\n[    9.853464]  worker_thread+0x1af/0x390\n[    9.857225]  ? rescuer_thread+0x3b0/0x3b0\n[    9.861254]  kthread+0xde/0x110\n[    9.864414]  ? kthread_complete_and_exit+0x20/0x20\n[    9.869210]  ret_from_fork+0x22/0x30\n[    9.872792]  </TASK>\n[    9.874985] ---[ end trace 0000000000000000 ]---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.01989,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/32b9bd7cfc2e2d92d595386add4e111b232b351f","https://git.kernel.org/stable/c/6be2e7522eb529b41c16d459f33bbdbcddbf5c15","https://git.kernel.org/stable/c/81d2a7e93c8322ca6b858f6736d7fc3d034e6c23","https://git.kernel.org/stable/c/96e34c88000febc83e41aa7db0b0a41676314818","https://git.kernel.org/stable/c/d0217b09910c081b6471181345ea5b24025edf51"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53608","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread()\n\nThe finalization of nilfs_segctor_thread() can race with\nnilfs_segctor_kill_thread() which terminates that thread, potentially\ncausing a use-after-free BUG as KASAN detected.\n\nAt the end of nilfs_segctor_thread(), it assigns NULL to \"sc_task\" member\nof \"struct nilfs_sc_info\" to indicate the thread has finished, and then\nnotifies nilfs_segctor_kill_thread() of this using waitqueue\n\"sc_wait_task\" on the struct nilfs_sc_info.\n\nHowever, here, immediately after the NULL assignment to \"sc_task\", it is\npossible that nilfs_segctor_kill_thread() will detect it and return to\ncontinue the deallocation, freeing the nilfs_sc_info structure before the\nthread does the notification.\n\nThis fixes the issue by protecting the NULL assignment to \"sc_task\" and\nits notification, with spinlock \"sc_state_lock\" of the struct\nnilfs_sc_info.  Since nilfs_segctor_kill_thread() does a final check to\nsee if \"sc_task\" is NULL with \"sc_state_lock\" locked, this can eliminate\nthe race.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/034cce77d52ba013ce62b4f5258c29907eb1ada5","https://git.kernel.org/stable/c/0dbf0e64b91ee8fcb278aea93eb06fc7d56ecbcc","https://git.kernel.org/stable/c/613bf23c070d11c525268f2945aa594704a9b764","https://git.kernel.org/stable/c/6be49d100c22ffea3287a4b19d7639d259888e33","https://git.kernel.org/stable/c/92684e02654c91a61a0b0561433b710bcece19fe","https://git.kernel.org/stable/c/b4d80bd6370b81a1725b6b8f7894802c23a14e9f","https://git.kernel.org/stable/c/bae009a2f1b7c2011d2e92d8c84868d315c0b97e","https://git.kernel.org/stable/c/f32297dba338dc06d62286dedb3cdbd5175b1719"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53609","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: core: Do not increase scsi_device's iorequest_cnt if dispatch failed\"\n\nThe \"atomic_inc(&cmd->device->iorequest_cnt)\" in scsi_queue_rq() would\ncause kernel panic because cmd->device may be freed after returning from\nscsi_dispatch_cmd().\n\nThis reverts commit cfee29ffb45b1c9798011b19d454637d1b0fe87d.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/35fe6fa57b994e7da222893adf0bb748d6055e73","https://git.kernel.org/stable/c/6ca9818d1624e136a76ae8faedb6b6c95ca66903"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53610","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip: Fix refcount leak in platform_irqchip_probe\n\nof_irq_find_parent() returns a node pointer with refcount incremented,\nWe should use of_node_put() on it when not needed anymore.\nAdd missing of_node_put() to avoid refcount leak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4401b485855700f296cae4d0db36a52948bff4fa","https://git.kernel.org/stable/c/6caa5a2b78f5f53c433d3a3781e53325da22f0ac","https://git.kernel.org/stable/c/b00baffcc2561374f8fe8af873d00531f19864eb","https://git.kernel.org/stable/c/c32fb16331f612e66a7fa8930164e0dc15725b72","https://git.kernel.org/stable/c/ea54b608d85b7536f92238f3259730fa06cb5d21"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53611","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nipmi_si: fix a memleak in try_smi_init()\n\nKmemleak reported the following leak info in try_smi_init():\n\nunreferenced object 0xffff00018ecf9400 (size 1024):\n  comm \"modprobe\", pid 2707763, jiffies 4300851415 (age 773.308s)\n  backtrace:\n    [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0\n    [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si]\n    [<000000006460d325>] 0xffff800081b10148\n    [<0000000039206ea5>] do_one_initcall+0x64/0x2a4\n    [<00000000601399ce>] do_init_module+0x50/0x300\n    [<000000003c12ba3c>] load_module+0x7a8/0x9e0\n    [<00000000c246fffe>] __se_sys_init_module+0x104/0x180\n    [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30\n    [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250\n    [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0\n    [<000000005a05337f>] el0_svc+0x24/0x3c\n    [<000000005eb248d6>] el0_sync_handler+0x160/0x164\n    [<0000000030a59039>] el0_sync+0x160/0x180\n\nThe problem was that when an error occurred before handlers registration\nand after allocating `new_smi->si_sm`, the variable wouldn't be freed in\nthe error handling afterwards since `shutdown_smi()` hadn't been\nregistered yet. Fix it by adding a `kfree()` in the error handling path\nin `try_smi_init()`.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/09cb2a71b2e982015fe0464f28da1ab42b8e6375","https://git.kernel.org/stable/c/1bfcfea0fae0d0a6c6ff5543e6d704b3807b83ce","https://git.kernel.org/stable/c/5c5f02e16b919c8cb6024dc3778c8d8f1fb1f26b","https://git.kernel.org/stable/c/6cf1a126de2992b4efe1c3c4d398f8de4aed6e3f","https://git.kernel.org/stable/c/7291af9a738d936c2d6869d030711dceb68404d0","https://git.kernel.org/stable/c/b9bc8fbb2d416ce87f0342478dc9fcfd79f2c65f","https://git.kernel.org/stable/c/cbb7d8a4b4beb3061b3a1847a742983a01dca381","https://git.kernel.org/stable/c/f53ab5a2bf20fed59a2f7542d3453228b8056358"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53612","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Simplify platform device handling\n\nCoretemp's platform driver is unconventional. All the real work is done\nglobally by the initcall and CPU hotplug notifiers, while the \"driver\"\neffectively just wraps an allocation and the registration of the hwmon\ninterface in a long-winded round-trip through the driver core.  The whole\nlogic of dynamically creating and destroying platform devices to bring\nthe interfaces up and down is error prone, since it assumes\nplatform_device_add() will synchronously bind the driver and set drvdata\nbefore it returns, thus results in a NULL dereference if drivers_autoprobe\nis turned off for the platform bus. Furthermore, the unusual approach of\ndoing that from within a CPU hotplug notifier, already commented in the\ncode that it deadlocks suspend, also causes lockdep issues for other\ndrivers or subsystems which may want to legitimately register a CPU\nhotplug notifier from a platform bus notifier.\n\nAll of these issues can be solved by ripping this unusual behaviour out\ncompletely, simply tying the platform devices to the lifetime of the\nmodule itself, and directly managing the hwmon interfaces from the\nhotplug notifiers. There is a slight user-visible change in that\n/sys/bus/platform/drivers/coretemp will no longer appear, and\n/sys/devices/platform/coretemp.n will remain present if package n is\nhotplugged off, but hwmon users should really only be looking for the\npresence of the hwmon interfaces, whose behaviour remains unchanged.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04367,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4000384684f612b3645a944f6acde0e65ac370b8","https://git.kernel.org/stable/c/52ea47a0ddfbc5fe05e873d3f5a59db4ba3e03fe","https://git.kernel.org/stable/c/5735878a7b7db7e9ce731cb36cec298a9de67549","https://git.kernel.org/stable/c/6d03bbff456befeccdd4d663177c4d6c75d0c4ff","https://git.kernel.org/stable/c/8fcdbc4bc01365f4b10fed7db544a3149e3054fd","https://git.kernel.org/stable/c/c57a8d14d7880521150ee801d53a0a64fdffd9c8"],"published_time":"2025-10-04T16:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53595","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: mcs: Fix NULL pointer dereferences\n\nWhen system is rebooted after creating macsec interface\nbelow NULL pointer dereference crashes occurred. This\npatch fixes those crashes by using correct order of teardown\n\n[ 3324.406942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 3324.415726] Mem abort info:\n[ 3324.418510]   ESR = 0x96000006\n[ 3324.421557]   EC = 0x25: DABT (current EL), IL = 32 bits\n[ 3324.426865]   SET = 0, FnV = 0\n[ 3324.429913]   EA = 0, S1PTW = 0\n[ 3324.433047] Data abort info:\n[ 3324.435921]   ISV = 0, ISS = 0x00000006\n[ 3324.439748]   CM = 0, WnR = 0\n....\n[ 3324.575915] Call trace:\n[ 3324.578353]  cn10k_mdo_del_secy+0x24/0x180\n[ 3324.582440]  macsec_common_dellink+0xec/0x120\n[ 3324.586788]  macsec_notify+0x17c/0x1c0\n[ 3324.590529]  raw_notifier_call_chain+0x50/0x70\n[ 3324.594965]  call_netdevice_notifiers_info+0x34/0x7c\n[ 3324.599921]  rollback_registered_many+0x354/0x5bc\n[ 3324.604616]  unregister_netdevice_queue+0x88/0x10c\n[ 3324.609399]  unregister_netdev+0x20/0x30\n[ 3324.613313]  otx2_remove+0x8c/0x310\n[ 3324.616794]  pci_device_shutdown+0x30/0x70\n[ 3324.620882]  device_shutdown+0x11c/0x204\n\n[  966.664930] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[  966.673712] Mem abort info:\n[  966.676497]   ESR = 0x96000006\n[  966.679543]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  966.684848]   SET = 0, FnV = 0\n[  966.687895]   EA = 0, S1PTW = 0\n[  966.691028] Data abort info:\n[  966.693900]   ISV = 0, ISS = 0x00000006\n[  966.697729]   CM = 0, WnR = 0\n[  966.833467] Call trace:\n[  966.835904]  cn10k_mdo_stop+0x20/0xa0\n[  966.839557]  macsec_dev_stop+0xe8/0x11c\n[  966.843384]  __dev_close_many+0xbc/0x140\n[  966.847298]  dev_close_many+0x84/0x120\n[  966.851039]  rollback_registered_many+0x114/0x5bc\n[  966.855735]  unregister_netdevice_many.part.0+0x14/0xa0\n[  966.860952]  unregister_netdevice_many+0x18/0x24\n[  966.865560]  macsec_notify+0x1ac/0x1c0\n[  966.869303]  raw_notifier_call_chain+0x50/0x70\n[  966.873738]  call_netdevice_notifiers_info+0x34/0x7c\n[  966.878694]  rollback_registered_many+0x354/0x5bc\n[  966.883390]  unregister_netdevice_queue+0x88/0x10c\n[  966.888173]  unregister_netdev+0x20/0x30\n[  966.892090]  otx2_remove+0x8c/0x310\n[  966.895571]  pci_device_shutdown+0x30/0x70\n[  966.899660]  device_shutdown+0x11c/0x204\n[  966.903574]  __do_sys_reboot+0x208/0x290\n[  966.907487]  __arm64_sys_reboot+0x20/0x30\n[  966.911489]  el0_svc_handler+0x80/0x1c0\n[  966.915316]  el0_svc+0x8/0x180\n[  966.918362] Code: f9400000 f9400a64 91220014 f94b3403 (f9400060)\n[  966.924448] ---[ end trace 341778e799c3d8d7 ]---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1152c0f947b76e7731e039185cbd00fdb4389f00","https://git.kernel.org/stable/c/13ff119b17e5e2916435ce01a0156c8698ad9e16","https://git.kernel.org/stable/c/699af748c61574125d269db260dabbe20436d74e","https://git.kernel.org/stable/c/a3dcc45eca017fca82ac47dbde6f41af960657e5"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53596","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: base: Free devm resources when unregistering a device\n\nIn the current code, devres_release_all() only gets called if the device\nhas a bus and has been probed.\n\nThis leads to issues when using bus-less or driver-less devices where\nthe device might never get freed if a managed resource holds a reference\nto the device. This is happening in the DRM framework for example.\n\nWe should thus call devres_release_all() in the device_del() function to\nmake sure that the device-managed actions are properly executed when the\ndevice is unregistered, even if it has neither a bus nor a driver.\n\nThis is effectively the same change than commit 2f8d16a996da (\"devres:\nrelease resources on device_del()\") that got reverted by commit\na525a3ddeaca (\"driver core: free devres in device_release\") over\nmemory leaks concerns.\n\nThis patch effectively combines the two commits mentioned above to\nrelease the resources both on device_del() and device_release() and get\nthe best of both worlds.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00016,"ranking_epss":0.03471,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/297992e5c63528e603666e36081836204fc36ec9","https://git.kernel.org/stable/c/3bcc4c2a096e8342c8c719e595ce15de212694dd","https://git.kernel.org/stable/c/699fb50d99039a50e7494de644f96c889279aca3","https://git.kernel.org/stable/c/c8c426fae26086a0ca8ab6cc6da2de79810ec038"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53597","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix mid leak during reconnection after timeout threshold\n\nWhen the number of responses with status of STATUS_IO_TIMEOUT\nexceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect\nthe connection. But we do not return the mid, or the credits\nreturned for the mid, or reduce the number of in-flight requests.\n\nThis bug could result in the server->in_flight count to go bad,\nand also cause a leak in the mids.\n\nThis change moves the check to a few lines below where the\nresponse is decrypted, even of the response is read from the\ntransform header. This way, the code for returning the mids\ncan be reused.\n\nAlso, the cifs_reconnect was reconnecting just the transport\nconnection before. In case of multi-channel, this may not be\nwhat we want to do after several timeouts. Changed that to\nreconnect the session and the tree too.\n\nAlso renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name\nMAX_STATUS_IO_TIMEOUT.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/57d25e9905c71133e201f6d06b56a3403d4ad433","https://git.kernel.org/stable/c/69cba9d3c1284e0838ae408830a02c4a063104bc","https://git.kernel.org/stable/c/c55901d381a22300c9922170e59704059f50977b","https://git.kernel.org/stable/c/df31d05f0678cdd0796ea19983a2b93edca18bb0"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53598","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: host: Range check CHDBOFF and ERDBOFF\n\nIf the value read from the CHDBOFF and ERDBOFF registers is outside the\nrange of the MHI register space then an invalid address might be computed\nwhich later causes a kernel panic.  Range check the read value to prevent\na crash due to bad data from the device.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2343385fe6eed11d0432ab42a97b3ca4aef06a99","https://git.kernel.org/stable/c/372f1752b74572b0a9d2288841eab7db17daccae","https://git.kernel.org/stable/c/4e584127ec2bd42a37c88badb49df409f21fa40a","https://git.kernel.org/stable/c/6a0c637bfee69a74c104468544d9f2a6579626d0","https://git.kernel.org/stable/c/83bf6b87e2dd053d95d89eb2f01ae885f9e568db","https://git.kernel.org/stable/c/a2cbb1a45a0c86ce77839c0875414efe1a89315e"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53599","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix missing initialisation affecting gcm-aes-s390\n\nFix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point\nto the scatterlist array in areq->first_rsgl.sgl.sgl.\n\nWithout this, the gcm-aes-s390 driver will oops when it tries to do\ngcm_walk_start() on req->dst because req->dst is set to the value of\nareq->first_rsgl.sgl.sgl by _aead_recvmsg() calling\naead_request_set_crypt().\n\nThe problem comes if an empty ciphertext is passed: the loop in\naf_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl\nup.\n\nThis isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far\nas I can tell, that ignores req->dst and only uses req->src[*].\n\n[*] Is this a bug in aesni-intel_glue.c?\n\nThe s390x oops looks something like:\n\n Unable to handle kernel pointer dereference in virtual kernel address space\n Failing address: 0000000a00000000 TEID: 0000000a00000803\n Fault in home space mode while using kernel ASCE.\n AS:00000000a43a0007 R3:0000000000000024\n Oops: 003b ilc:2 [#1] SMP\n ...\n Call Trace:\n  [<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390]\n  [<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8\n  [<00000000a2a60888>] aead_recvmsg+0x478/0x698\n  [<00000000a2e519a0>] sock_recvmsg+0x70/0xb0\n  [<00000000a2e51a56>] sock_read_iter+0x76/0xa0\n  [<00000000a273e066>] vfs_read+0x26e/0x2a8\n  [<00000000a273e8c4>] ksys_read+0xbc/0x100\n  [<00000000a311d808>] __do_syscall+0x1d0/0x1f8\n  [<00000000a312ff30>] system_call+0x70/0x98\n Last Breaking-Event-Address:\n  [<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2c9d205040d7c0eaccc473917f9b0bb0a923e440","https://git.kernel.org/stable/c/6a4b8aa0a916b39a39175584c07222434fa6c6ef"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53600","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntunnels: fix kasan splat when generating ipv4 pmtu error\n\nIf we try to emit an icmp error in response to a nonliner skb, we get\n\nBUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220\nRead of size 4 at addr ffff88811c50db00 by task iperf3/1691\nCPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309\n[..]\n kasan_report+0x105/0x140\n ip_compute_csum+0x134/0x220\n iptunnel_pmtud_build_icmp+0x554/0x1020\n skb_tunnel_check_pmtu+0x513/0xb80\n vxlan_xmit_one+0x139e/0x2ef0\n vxlan_xmit+0x1867/0x2760\n dev_hard_start_xmit+0x1ee/0x4f0\n br_dev_queue_push_xmit+0x4d1/0x660\n [..]\n\nip_compute_csum() cannot deal with nonlinear skbs, so avoid it.\nAfter this change, splat is gone and iperf3 is no longer stuck.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.03059,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5850c391fd7e25662334cb3cbf29a62bcbff1084","https://git.kernel.org/stable/c/6a7ac3d20593865209dceb554d8b3f094c6bd940","https://git.kernel.org/stable/c/da5f42a6e7485fbb7a6dbd6a2b3045e19e4df5cc","https://git.kernel.org/stable/c/e95808121953410db8c59f0abfde70ac0d34222c","https://git.kernel.org/stable/c/fe6a9f7516735be9fdabab00e47ef7a3403a174d"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53601","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: do not assume skb mac_header is set\n\nDrivers must not assume in their ndo_start_xmit() that\nskbs have their mac_header set. skb->data is all what is needed.\n\nbonding seems to be one of the last offender as caught by syzbot:\n\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470\nModules linked in:\nCPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023\nRIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]\nRIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]\nRIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]\nRIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]\nRIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]\nRIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]\nRIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470\nCode: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe <0f> 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe\nRSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283\nRAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000\nRDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6\nRBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584\nR10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e\nR13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76\nFS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<TASK>\n[<ffffffff8471a49f>] netdev_start_xmit include/linux/netdevice.h:4925 [inline]\n[<ffffffff8471a49f>] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380\n[<ffffffff851d845b>] dev_direct_xmit include/linux/netdevice.h:3043 [inline]\n[<ffffffff851d845b>] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284\n[<ffffffff851c7472>] packet_snd net/packet/af_packet.c:3112 [inline]\n[<ffffffff851c7472>] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143\n[<ffffffff8467a4b2>] sock_sendmsg_nosec net/socket.c:716 [inline]\n[<ffffffff8467a4b2>] sock_sendmsg net/socket.c:736 [inline]\n[<ffffffff8467a4b2>] __sys_sendto+0x472/0x5f0 net/socket.c:2139\n[<ffffffff8467a715>] __do_sys_sendto net/socket.c:2151 [inline]\n[<ffffffff8467a715>] __se_sys_sendto net/socket.c:2147 [inline]\n[<ffffffff8467a715>] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147\n[<ffffffff8553071f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[<ffffffff8553071f>] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80\n[<ffffffff85600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/029d892b05fc5e42a1b1c0665f62cb3e4b23e6dc","https://git.kernel.org/stable/c/37b6143376a578265add04f35161b257eeb84a5e","https://git.kernel.org/stable/c/6a940abdef3162e5723f1495b8a49859d1708f79","https://git.kernel.org/stable/c/bc16fc63592c419357dd4c4d82d50762102a60ef","https://git.kernel.org/stable/c/c96cc3d9acaca53d9a81c884c23f1224b61c829b"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53602","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix memory leak in WMI firmware stats\n\nMemory allocated for firmware pdev, vdev and beacon statistics\nare not released during rmmod.\n\nFix it by calling ath11k_fw_stats_free() function before hardware\nunregister.\n\nWhile at it, avoid calling ath11k_fw_stats_free() while processing\nthe firmware stats received in the WMI event because the local list\nis getting spliced and reinitialised and hence there are no elements\nin the list after splicing.\n\nTested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/55248d36beb79d3a61c9fb3122dc377fff523c89","https://git.kernel.org/stable/c/6aafa1c2d3e3fea2ebe84c018003f2a91722e607","https://git.kernel.org/stable/c/86f9330a49d1464849482298dd34d361859183eb"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53603","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Avoid fcport pointer dereference\n\nKlocwork reported warning of NULL pointer may be dereferenced.  The routine\nexits when sa_ctl is NULL and fcport is allocated after the exit call thus\ncausing NULL fcport pointer to dereference at the time of exit.\n\nTo avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4406fe8a96a946c7ea5724ee59625755a1d9c59d","https://git.kernel.org/stable/c/477bc74ad1add644b606bff6ba1284943c42818a","https://git.kernel.org/stable/c/6b504d06976fe4a61cc05dedc68b84fadb397f77","https://git.kernel.org/stable/c/7bbeff613ec0560fb2f6f8b405288f3f043adf64"],"published_time":"2025-10-04T16:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53587","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nring-buffer: Sync IRQ works before buffer destruction\n\nIf something was written to the buffer just before destruction,\nit may be possible (maybe not in a real system, but it did\nhappen in ARCH=um with time-travel) to destroy the ringbuffer\nbefore the IRQ work ran, leading this KASAN report (or a crash\nwithout KASAN):\n\n    BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a\n    Read of size 8 at addr 000000006d640a48 by task swapper/0\n\n    CPU: 0 PID: 0 Comm: swapper Tainted: G        W  O       6.3.0-rc1 #7\n    Stack:\n     60c4f20f 0c203d48 41b58ab3 60f224fc\n     600477fa 60f35687 60c4f20f 601273dd\n     00000008 6101eb00 6101eab0 615be548\n    Call Trace:\n     [<60047a58>] show_stack+0x25e/0x282\n     [<60c609e0>] dump_stack_lvl+0x96/0xfd\n     [<60c50d4c>] print_report+0x1a7/0x5a8\n     [<603078d3>] kasan_report+0xc1/0xe9\n     [<60308950>] __asan_report_load8_noabort+0x1b/0x1d\n     [<60232844>] irq_work_run_list+0x11a/0x13a\n     [<602328b4>] irq_work_tick+0x24/0x34\n     [<6017f9dc>] update_process_times+0x162/0x196\n     [<6019f335>] tick_sched_handle+0x1a4/0x1c3\n     [<6019fd9e>] tick_sched_timer+0x79/0x10c\n     [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695\n     [<60182913>] hrtimer_interrupt+0x16c/0x2c4\n     [<600486a3>] um_timer+0x164/0x183\n     [...]\n\n    Allocated by task 411:\n     save_stack_trace+0x99/0xb5\n     stack_trace_save+0x81/0x9b\n     kasan_save_stack+0x2d/0x54\n     kasan_set_track+0x34/0x3e\n     kasan_save_alloc_info+0x25/0x28\n     ____kasan_kmalloc+0x8b/0x97\n     __kasan_kmalloc+0x10/0x12\n     __kmalloc+0xb2/0xe8\n     load_elf_phdrs+0xee/0x182\n     [...]\n\n    The buggy address belongs to the object at 000000006d640800\n     which belongs to the cache kmalloc-1k of size 1024\n    The buggy address is located 584 bytes inside of\n     freed 1024-byte region [000000006d640800, 000000006d640c00)\n\nAdd the appropriate irq_work_sync() so the work finishes before\nthe buffers are destroyed.\n\nPrior to the commit in the Fixes tag below, there was only a\nsingle global IRQ work, so this issue didn't exist.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0a65165bd24ee9231191597b7c232376fcd70cdb","https://git.kernel.org/stable/c/1c99f65d6af2a454bfd5207b4f6a97c8474a1191","https://git.kernel.org/stable/c/2399b1fda025e939b6fb1ac94505bcf718534e65","https://git.kernel.org/stable/c/2702b67f59d455072a08dc40312f9b090d4dec04","https://git.kernel.org/stable/c/372c5ee537b8366b64b691ba29e9335525e1655e","https://git.kernel.org/stable/c/675751bb20634f981498c7d66161584080cc061e","https://git.kernel.org/stable/c/c63741e872fcfb10e153517750f7908f0c00f60d","https://git.kernel.org/stable/c/d9834abd8b24d1fe8092859e436fe1e0fd467c61","https://git.kernel.org/stable/c/fc6858b7f8e1221f62ce8c6ff8a13a349c32cd76"],"published_time":"2025-10-04T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53588","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: check for station first in client probe\n\nWhen probing a client, first check if we have it, and then\ncheck for the channel context, otherwise you can trigger\nthe warning there easily by probing when the AP isn't even\nstarted yet. Since a client existing means the AP is also\noperating, we can then keep the warning.\n\nAlso simplify the moved code a bit.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/67dfa589aa8806c7959cbca2f4613b8d41c75a06","https://git.kernel.org/stable/c/7dce2deb0b03aaf46c87ceedea81ef4153e26c40","https://git.kernel.org/stable/c/7e1cda5cf07f848e6b50b4e5e7761ffbce905a3d"],"published_time":"2025-10-04T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53589","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: don't trust firmware n_channels\n\nIf the firmware sends us a corrupted MCC response with\nn_channels much larger than the command response can be,\nwe might copy far too much (uninitialized) memory and\neven crash if the n_channels is large enough to make it\nrun out of the one page allocated for the FW response.\n\nFix that by checking the lengths. Doing a < comparison\nwould be sufficient, but the firmware should be doing\nit correctly, so check more strictly.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/05ad5a4d421ce65652fcb24d46b7e273130240d6","https://git.kernel.org/stable/c/557ba100d8cf3661ff8d71c0b4a2cba8db555ec2","https://git.kernel.org/stable/c/682b6dc29d98e857e6ca4bbc077c7dc2899b7473","https://git.kernel.org/stable/c/c176f03350954b795322de0bfe1d7b514db41f45","https://git.kernel.org/stable/c/d0d39bed9e95f27a246be91c5929254ac043ed30","https://git.kernel.org/stable/c/e519a404a5bbba37693cb10fa61794a5fce4fd9b"],"published_time":"2025-10-04T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53590","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: add a refcnt in sctp_stream_priorities to avoid a nested loop\n\nWith this refcnt added in sctp_stream_priorities, we don't need to\ntraverse all streams to check if the prio is used by other streams\nwhen freeing one stream's prio in sctp_sched_prio_free_sid(). This\ncan avoid a nested loop (up to 65535 * 65535), which may cause a\nstuck as Ying reported:\n\n    watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]\n    Call Trace:\n     <TASK>\n     sctp_sched_prio_free_sid+0xab/0x100 [sctp]\n     sctp_stream_free_ext+0x64/0xa0 [sctp]\n     sctp_stream_free+0x31/0x50 [sctp]\n     sctp_association_free+0xa5/0x200 [sctp]\n\nNote that it doesn't need to use refcount_t type for this counter,\nas its accessing is always protected under the sock lock.\n\nv1->v2:\n - add a check in sctp_sched_prio_set to avoid the possible prio_head\n   refcnt overflow.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01473,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03c3a5584a0a29821e59b7834635ce823050caaa","https://git.kernel.org/stable/c/68ba44639537de6f91fe32783766322d41848127","https://git.kernel.org/stable/c/6d529928ea212127851a2df8c40d822237ca946b","https://git.kernel.org/stable/c/8ee401f89cdb10f39098c0656d695b2bc4052100","https://git.kernel.org/stable/c/bf5540cbd20e2dae2c81ab9b31deef41ef147d0a","https://git.kernel.org/stable/c/cec326443f01283ef68ea00c06ea073b1835a562"],"published_time":"2025-10-04T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53591","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix deadlock in tc route query code\n\nCited commit causes ABBA deadlock[0] when peer flows are created while\nholding the devcom rw semaphore. Due to peer flows offload implementation\nthe lock is taken much higher up the call chain and there is no obvious way\nto easily fix the deadlock. Instead, since tc route query code needs the\npeer eswitch structure only to perform a lookup in xarray and doesn't\nperform any sleeping operations with it, refactor the code for lockless\nexecution in following ways:\n\n- RCUify the devcom 'data' pointer. When resetting the pointer\nsynchronously wait for RCU grace period before returning. This is fine\nsince devcom is currently only used for synchronization of\npairing/unpairing of eswitches which is rare and already expensive as-is.\n\n- Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has\nalready been used in some unlocked contexts without proper\nannotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't\nan issue since all relevant code paths checked it again after obtaining the\ndevcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as\n\"best effort\" check to return NULL when devcom is being unpaired. Note that\nwhile RCU read lock doesn't prevent the unpaired flag from being changed\nconcurrently it still guarantees that reader can continue to use 'data'.\n\n- Refactor mlx5e_tc_query_route_vport() function to use new\nmlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.\n\n[0]:\n\n[  164.599612] ======================================================\n[  164.600142] WARNING: possible circular locking dependency detected\n[  164.600667] 6.3.0-rc3+ #1 Not tainted\n[  164.601021] ------------------------------------------------------\n[  164.601557] handler1/3456 is trying to acquire lock:\n[  164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]\n[  164.603078]\n               but task is already holding lock:\n[  164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]\n[  164.604459]\n               which lock already depends on the new lock.\n\n[  164.605190]\n               the existing dependency chain (in reverse order) is:\n[  164.605848]\n               -> #1 (&comp->sem){++++}-{3:3}:\n[  164.606380]        down_read+0x39/0x50\n[  164.606772]        mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]\n[  164.607336]        mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core]\n[  164.607914]        mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core]\n[  164.608495]        mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core]\n[  164.609063]        mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core]\n[  164.609627]        __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core]\n[  164.610175]        mlx5e_configure_flower+0x952/0x1a20 [mlx5_core]\n[  164.610741]        tc_setup_cb_add+0xd4/0x200\n[  164.611146]        fl_hw_replace_filter+0x14c/0x1f0 [cls_flower]\n[  164.611661]        fl_change+0xc95/0x18a0 [cls_flower]\n[  164.612116]        tc_new_tfilter+0x3fc/0xd20\n[  164.612516]        rtnetlink_rcv_msg+0x418/0x5b0\n[  164.612936]        netlink_rcv_skb+0x54/0x100\n[  164.613339]        netlink_unicast+0x190/0x250\n[  164.613746]        netlink_sendmsg+0x245/0x4a0\n[  164.614150]        sock_sendmsg+0x38/0x60\n[  164.614522]        ____sys_sendmsg+0x1d0/0x1e0\n[  164.614934]        ___sys_sendmsg+0x80/0xc0\n[  164.615320]        __sys_sendmsg+0x51/0x90\n[  164.615701]        do_syscall_64+0x3d/0x90\n[  164.616083]        entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[  164.616568]\n               -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}:\n[  164.617210]        __lock_acquire+0x159e/0x26e0\n[  164.617638]        lock_acquire+0xc2/0x2a0\n[  164.618018]        __mutex_lock+0x92/0xcd0\n[  164.618401]        mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]\n[  164.618943]        post_process_attr+0x153/0x2d0 [\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01664,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/362063df6ceec80b0b6798b61ae03504dcc125a5","https://git.kernel.org/stable/c/691c041bf20899fc13c793f92ba61ab660fa3a30","https://git.kernel.org/stable/c/69966bce28da6aadccfd968b75d128a79da32d17","https://git.kernel.org/stable/c/a7236e420a7d8082b1df4b3e05c739dd2642a662"],"published_time":"2025-10-04T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53592","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: sifive: Fix refcount leak in sifive_gpio_probe\n\nof_irq_find_parent() returns a node pointer with refcount incremented,\nWe should use of_node_put() on it when not needed anymore.\nAdd missing of_node_put() to avoid refcount leak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/694175cd8a1643cde3acb45c9294bca44a8e08e9","https://git.kernel.org/stable/c/95da1882ce9372ba20278f87cdb7a34f9812c4b5","https://git.kernel.org/stable/c/9a402a210798662b04cbe6ca466e916a15efa03a","https://git.kernel.org/stable/c/f4a2ad1002006548e235255c65a4f1d07312be9d","https://git.kernel.org/stable/c/f9fb4776ebbc16dfc512adbdc0fe218acb47c7cc"],"published_time":"2025-10-04T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53593","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Release folio lock on fscache read hit.\n\nUnder the current code, when cifs_readpage_worker is called, the call\ncontract is that the callee should unlock the page. This is documented\nin the read_folio section of Documentation/filesystems/vfs.rst as:\n\n> The filesystem should unlock the folio once the read has completed,\n> whether it was successful or not.\n\nWithout this change, when fscache is in use and cache hit occurs during\na read, the page lock is leaked, producing the following stack on\nsubsequent reads (via mmap) to the page:\n\n$ cat /proc/3890/task/12864/stack\n[<0>] folio_wait_bit_common+0x124/0x350\n[<0>] filemap_read_folio+0xad/0xf0\n[<0>] filemap_fault+0x8b1/0xab0\n[<0>] __do_fault+0x39/0x150\n[<0>] do_fault+0x25c/0x3e0\n[<0>] __handle_mm_fault+0x6ca/0xc70\n[<0>] handle_mm_fault+0xe9/0x350\n[<0>] do_user_addr_fault+0x225/0x6c0\n[<0>] exc_page_fault+0x84/0x1b0\n[<0>] asm_exc_page_fault+0x27/0x30\n\nThis requires a reboot to resolve; it is a deadlock.\n\nNote however that the call to cifs_readpage_from_fscache does mark the\npage clean, but does not free the folio lock. This happens in\n__cifs_readpage_from_fscache on success. Releasing the lock at that\npoint however is not appropriate as cifs_readahead also calls\ncifs_readpage_from_fscache and *does* unconditionally release the lock\nafter its return. This change therefore effectively makes\ncifs_readpage_worker work like cifs_readahead.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/69513dd669e243928f7450893190915a88f84a2b","https://git.kernel.org/stable/c/7a9fb689c1a1dc373887621a3bfa3810df0abde4","https://git.kernel.org/stable/c/9e725386d4262ef23ae51993f04602bc535b5be2"],"published_time":"2025-10-04T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53594","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix resource leak in device_add()\n\nWhen calling kobject_add() failed in device_add(), it will call\ncleanup_glue_dir() to free resource. But in kobject_add(),\ndev->kobj.parent has been set to NULL. This will cause resource leak.\n\nThe process is as follows:\ndevice_add()\n\tget_device_parent()\n\t\tclass_dir_create_and_add()\n\t\t\tkobject_add()\t\t//kobject_get()\n\t...\n\tdev->kobj.parent = kobj;\n\t...\n\tkobject_add()\t\t//failed, but set dev->kobj.parent = NULL\n\t...\n\tglue_dir = get_glue_dir(dev)\t//glue_dir = NULL, and goto\n\t\t\t\t\t//\"Error\" label\n\t...\n\tcleanup_glue_dir()\t//becaues glue_dir is NULL, not call\n\t\t\t\t//kobject_put()\n\nThe preceding problem may cause insmod mac80211_hwsim.ko to failed.\nsysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'\nCall Trace:\n<TASK>\ndump_stack_lvl+0x8e/0xd1\nsysfs_warn_dup.cold+0x1c/0x29\nsysfs_create_dir_ns+0x224/0x280\nkobject_add_internal+0x2aa/0x880\nkobject_add+0x135/0x1a0\nget_device_parent+0x3d7/0x590\ndevice_add+0x2aa/0x1cb0\ndevice_create_groups_vargs+0x1eb/0x260\ndevice_create+0xdc/0x110\nmac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]\ninit_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]\ndo_one_initcall+0x10f/0x630\ndo_init_module+0x19f/0x5e0\nload_module+0x64b7/0x6eb0\n__do_sys_finit_module+0x140/0x200\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\n</TASK>\nkobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to\nregister things with the same name in the same directory.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6977b1a5d67097eaa4d02b0c126c04cc6e8917c0","https://git.kernel.org/stable/c/8d389e363075c2e1deb84a560686ea92123e4b8b","https://git.kernel.org/stable/c/d1dbff10c6cd3b43457f3efd3c9c4950009635bf","https://git.kernel.org/stable/c/f39d21154db87545d8f0b25d13c326f37cc32239"],"published_time":"2025-10-04T16:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53583","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nperf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()\n\nSince commit 096b52fd2bb4 (\"perf: RISC-V: throttle perf events\") the\nperf_sample_event_took() function was added to report time spent in\noverflow interrupts. If the interrupt takes too long, the perf framework\nwill lower the sysctl_perf_event_sample_rate and max_samples_per_tick.\nWhen hwc->interrupts is larger than max_samples_per_tick, the\nhwc->interrupts will be set to MAX_INTERRUPTS, and events will be\nthrottled within the __perf_event_account_interrupt() function.\n\nHowever, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the\nPERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()\nfunction to avoid throttling. When the perf framework unthrottled the event\nin the timer interrupt handler, it triggers riscv_pmu_start() function\nand causes a WARN_ON_ONCE() warning, as shown below:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e\n Modules linked in:\n CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1\n Hardware name: SiFive (DT)\n epc : riscv_pmu_start+0x7c/0x8e\n  ra : riscv_pmu_start+0x28/0x8e\n epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0\n  gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0\n  t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720\n  s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000\n  a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000\n  a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030\n  s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00\n  s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000\n  s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340\n  s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796\n  t5 : 0000000700000000 t6 : ffffaf8005269870\n status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003\n [<ffffffff80aef864>] riscv_pmu_start+0x7c/0x8e\n [<ffffffff80185b56>] perf_adjust_freq_unthr_context+0x15e/0x174\n [<ffffffff80188642>] perf_event_task_tick+0x88/0x9c\n [<ffffffff800626a8>] scheduler_tick+0xfe/0x27c\n [<ffffffff800b5640>] update_process_times+0x9a/0xba\n [<ffffffff800c5bd4>] tick_sched_handle+0x32/0x66\n [<ffffffff800c5e0c>] tick_sched_timer+0x64/0xb0\n [<ffffffff800b5e50>] __hrtimer_run_queues+0x156/0x2f4\n [<ffffffff800b6bdc>] hrtimer_interrupt+0xe2/0x1fe\n [<ffffffff80acc9e8>] riscv_timer_interrupt+0x38/0x42\n [<ffffffff80090a16>] handle_percpu_devid_irq+0x90/0x1d2\n [<ffffffff8008a9f4>] generic_handle_domain_irq+0x28/0x36\n\nAfter referring other PMU drivers like Arm, Loongarch, Csky, and Mips,\nthey don't call *_pmu_stop() to update with PERF_HES_STOPPED flag\nafter perf_event_overflow() function nor do they add PERF_HES_STOPPED\nflag checking in *_pmu_start() which don't cause this warning.\n\nThus, it's recommended to remove this unnecessary check in\nriscv_pmu_start() function to prevent this warning.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/66843b14fb71825fdd73ab12f6594f2243b402be","https://git.kernel.org/stable/c/8270d539a943d00cf6a094da0073e2b5972b641d","https://git.kernel.org/stable/c/aeb62beaf9cbd0a72e7f97c9af6d3e7f76ce2946"],"published_time":"2025-10-04T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53584","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process\n\nThere are two states for ubifs writing pages:\n1. Dirty, Private\n2. Not Dirty, Not Private\n\nThe normal process cannot go to ubifs_releasepage() which means there\nexists pages being private but not dirty. Reproducer[1] shows that it\ncould occur (which maybe related to [2]) with following process:\n\n     PA                     PB                    PC\nlock(page)[PA]\nubifs_write_end\n  attach_page_private         // set Private\n  __set_page_dirty_nobuffers  // set Dirty\nunlock(page)\n\nwrite_cache_pages[PA]\n  lock(page)\n  clear_page_dirty_for_io(page)\t// clear Dirty\n  ubifs_writepage\n\n                        do_truncation[PB]\n\t\t\t  truncate_setsize\n\t\t\t    i_size_write(inode, newsize) // newsize = 0\n\n    i_size = i_size_read(inode)\t// i_size = 0\n    end_index = i_size >> PAGE_SHIFT\n    if (page->index > end_index)\n      goto out // jump\nout:\nunlock(page)   // Private, Not Dirty\n\n\t\t\t\t\t\tgeneric_fadvise[PC]\n\t\t\t\t\t\t  lock(page)\n\t\t\t\t\t\t  invalidate_inode_page\n\t\t\t\t\t\t    try_to_release_page\n\t\t\t\t\t\t      ubifs_releasepage\n\t\t\t\t\t\t        ubifs_assert(c, 0)\n\t\t                                        // bad assertion!\n\t\t\t\t\t\t  unlock(page)\n\t\t\t  truncate_pagecache[PB]\n\nThen we may get following assertion failed:\n  UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]:\n  UBIFS assert failed: 0, in fs/ubifs/file.c:1513\n  UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]:\n  switched to read-only mode, error -22\n  CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308\n  Call Trace:\n    dump_stack+0x13/0x1b\n    ubifs_ro_mode+0x54/0x60 [ubifs]\n    ubifs_assert_failed+0x4b/0x80 [ubifs]\n    ubifs_releasepage+0x67/0x1d0 [ubifs]\n    try_to_release_page+0x57/0xe0\n    invalidate_inode_page+0xfb/0x130\n    __invalidate_mapping_pages+0xb9/0x280\n    invalidate_mapping_pagevec+0x12/0x20\n    generic_fadvise+0x303/0x3c0\n    ksys_fadvise64_64+0x4c/0xb0\n\n[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373\n[2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":7e-05,"ranking_epss":0.00559,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/66f4742e93523ab2f062d9d9828b3e590bc61536","https://git.kernel.org/stable/c/7750be5d3e18500b454714677463b500a0b8b0d8","https://git.kernel.org/stable/c/bd188ff1c8a1935c93a1e3cacf3be62667fdf762"],"published_time":"2025-10-04T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53585","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: reject unhashed sockets in bpf_sk_assign\n\nThe semantics for bpf_sk_assign are as follows:\n\n    sk = some_lookup_func()\n    bpf_sk_assign(skb, sk)\n    bpf_sk_release(sk)\n\nThat is, the sk is not consumed by bpf_sk_assign. The function\ntherefore needs to make sure that sk lives long enough to be\nconsumed from __inet_lookup_skb. The path through the stack for a\nTCPv4 packet is roughly:\n\n  netif_receive_skb_core: takes RCU read lock\n    __netif_receive_skb_core:\n      sch_handle_ingress:\n        tcf_classify:\n          bpf_sk_assign()\n      deliver_ptype_list_skb:\n        deliver_skb:\n          ip_packet_type->func == ip_rcv:\n            ip_rcv_core:\n            ip_rcv_finish_core:\n              dst_input:\n                ip_local_deliver:\n                  ip_local_deliver_finish:\n                    ip_protocol_deliver_rcu:\n                      tcp_v4_rcv:\n                        __inet_lookup_skb:\n                          skb_steal_sock\n\nThe existing helper takes advantage of the fact that everything\nhappens in the same RCU critical section: for sockets with\nSOCK_RCU_FREE set bpf_sk_assign never takes a reference.\nskb_steal_sock then checks SOCK_RCU_FREE again and does sock_put\nif necessary.\n\nThis approach assumes that SOCK_RCU_FREE is never set on a sk\nbetween bpf_sk_assign and skb_steal_sock, but this invariant is\nviolated by unhashed UDP sockets. A new UDP socket is created\nin TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only\nadded in udp_lib_get_port() which happens when a socket is bound.\n\nWhen bpf_sk_assign was added it wasn't possible to access unhashed\nUDP sockets from BPF, so this wasn't a problem. This changed\nin commit 0c48eefae712 (\"sock_map: Lift socket state restriction\nfor datagram sockets\"), but the helper wasn't adjusted accordingly.\nThe following sequence of events will therefore lead to a refcount\nleak:\n\n1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.\n2. Pull socket out of sockmap and bpf_sk_assign it. Since\n   SOCK_RCU_FREE is not set we increment the refcount.\n3. bind() or connect() the socket, setting SOCK_RCU_FREE.\n4. skb_steal_sock will now set refcounted = false due to\n   SOCK_RCU_FREE.\n5. tcp_v4_rcv() skips sock_put().\n\nFix the problem by rejecting unhashed sockets in bpf_sk_assign().\nThis matches the behaviour of __inet_lookup_skb which is ultimately\nthe goal of bpf_sk_assign().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3d4522f59fb748a54446846522941a4f09da63e9","https://git.kernel.org/stable/c/67312adc96b5a585970d03b62412847afe2c6b01","https://git.kernel.org/stable/c/791a12102e5191dcb6ce0b3a99d71b5a2802d12a","https://git.kernel.org/stable/c/7dcbc0bb0e5cc1823923744befce59ac353135e6","https://git.kernel.org/stable/c/8aa43cfbb68b25119d2ced14ec717173e2901fa2","https://git.kernel.org/stable/c/c0ce0fb76610d5fad31f56f2ca8241a2a6717a1b"],"published_time":"2025-10-04T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53586","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Fix multiple LUN_RESET handling\n\nThis fixes a bug where an initiator thinks a LUN_RESET has cleaned up\nrunning commands when it hasn't. The bug was added in commit 51ec502a3266\n(\"target: Delete tmr from list before processing\").\n\nThe problem occurs when:\n\n 1. We have N I/O cmds running in the target layer spread over 2 sessions.\n\n 2. The initiator sends a LUN_RESET for each session.\n\n 3. session1's LUN_RESET loops over all the running commands from both\n    sessions and moves them to its local drain_task_list.\n\n 4. session2's LUN_RESET does not see the LUN_RESET from session1 because\n    the commit above has it remove itself. session2 also does not see any\n    commands since the other reset moved them off the state lists.\n\n 5. sessions2's LUN_RESET will then complete with a successful response.\n\n 6. sessions2's inititor believes the running commands on its session are\n    now cleaned up due to the successful response and cleans up the running\n    commands from its side. It then restarts them.\n\n 7. The commands do eventually complete on the backend and the target\n    starts to return aborted task statuses for them. The initiator will\n    either throw a invalid ITT error or might accidentally lookup a new\n    task if the ITT has been reallocated already.\n\nFix the bug by reverting the patch, and serialize the execution of\nLUN_RESETs and Preempt and Aborts.\n\nAlso prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,\nbecause it turns out the original patch fixed a bug that was not\nmentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second\nLUN_RESET and wait on it. Then the second reset will run\ncore_tmr_drain_tmr_list and see the first reset and wait on it resulting in\na deadlock.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00015,"ranking_epss":0.03068,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2c43de56f9220dca3e28c774d1c5e2cab574223a","https://git.kernel.org/stable/c/673db054d7a2b5a470d7a25baf65956d005ad729","https://git.kernel.org/stable/c/9158c86fd3237acaea8f0181c7836d90fd6eea10","https://git.kernel.org/stable/c/e1f59cd18a10969d08a082264b557876ca38766e","https://git.kernel.org/stable/c/eacfe32c3650bfd0e54224d160c431013d7f6998","https://git.kernel.org/stable/c/ed18526289b5603bf2253dee50f1d7ec245cf397"],"published_time":"2025-10-04T16:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53574","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: delete timer and free skb queue when unloading\n\nFix possible crash and memory leak on driver unload by deleting\nTX purge timer and freeing C2H queue in 'rtw_core_deinit()',\nshrink critical section in the latter by freeing COEX queue\nout of TX report lock scope.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4128b00a6006870e117ab1841e58f369e9284ecb","https://git.kernel.org/stable/c/634fcbcaa4062db39aeb5ac6ed1bc1feb8dd5216"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53575","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: fix potential array out of bounds access\n\nAccount for IWL_SEC_WEP_KEY_OFFSET when needed while verifying\nkey_len size in iwl_mvm_sec_key_add().","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/133b1cd4d98bb8b272335c8e6b0e0c399c0b2ffa","https://git.kernel.org/stable/c/637452360ecde9ac972d19416e9606529576b302"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53576","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnull_blk: Always check queue mode setting from configfs\n\nMake sure to check device queue mode in the null_validate_conf() and\nreturn error for NULL_Q_RQ as we don't allow legacy I/O path, without\nthis patch we get OOPs when queue mode is set to 1 from configfs,\nfollowing are repro steps :-\n\nmodprobe null_blk nr_devices=0\nmkdir config/nullb/nullb0\necho 1 > config/nullb/nullb0/memory_backed\necho 4096 > config/nullb/nullb0/blocksize\necho 20480 > config/nullb/nullb0/size\necho 1 > config/nullb/nullb0/queue_mode\necho 1 > config/nullb/nullb0/power\n\nEntering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)\ndue to oops @ 0xffffffffc041c329\nCPU: 42 PID: 2372 Comm: sh Tainted: G           O     N 6.3.0-rc5lblk+ #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\nRIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]\nCode: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20\nRSP: 0018:ffffc900052cbde0 EFLAGS: 00010246\nRAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00\nRBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002\nR13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740\nFS:  00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0\nDR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a\nDR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n nullb_device_power_store+0xd1/0x120 [null_blk]\n configfs_write_iter+0xb4/0x120\n vfs_write+0x2ba/0x3c0\n ksys_write+0x5f/0xe0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7fd4460c57a7\nCode: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24\nRSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7\nRDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001\nRBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0\nR10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002\nR13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700\n </TASK>","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/35e304dbcefa95237a3d6f94c007bfb10f012b17","https://git.kernel.org/stable/c/63f8793ee60513a09f110ea460a6ff2c33811cdb","https://git.kernel.org/stable/c/651260e563d9f50827dac496dc8a0b9b23d5db1a","https://git.kernel.org/stable/c/e732a266b973cd4e115e2cc2ea5007119e8a7fbc","https://git.kernel.org/stable/c/fd35b7bb6d5a329c427924886949ab51f210200a"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53577","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, cpumap: Make sure kthread is running before map update returns\n\nThe following warning was reported when running stress-mode enabled\nxdp_redirect_cpu with some RT threads:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135\n  CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n  Workqueue: events cpu_map_kthread_stop\n  RIP: 0010:put_cpu_map_entry+0xda/0x220\n  ......\n  Call Trace:\n   <TASK>\n   ? show_regs+0x65/0x70\n   ? __warn+0xa5/0x240\n   ......\n   ? put_cpu_map_entry+0xda/0x220\n   cpu_map_kthread_stop+0x41/0x60\n   process_one_work+0x6b0/0xb80\n   worker_thread+0x96/0x720\n   kthread+0x1a5/0x1f0\n   ret_from_fork+0x3a/0x70\n   ret_from_fork_asm+0x1b/0x30\n   </TASK>\n\nThe root cause is the same as commit 436901649731 (\"bpf: cpumap: Fix memory\nleak in cpu_map_update_elem\"). The kthread is stopped prematurely by\nkthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call\ncpu_map_kthread_run() at all but XDP program has already queued some\nframes or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks\nthe ptr_ring, it will find it was not emptied and report a warning.\n\nAn alternative fix is to use __cpu_map_ring_cleanup() to drop these\npending frames or skbs when kthread_stop() returns -EINTR, but it may\nconfuse the user, because these frames or skbs have been handled\ncorrectly by XDP program. So instead of dropping these frames or skbs,\njust make sure the per-cpu kthread is running before\n__cpu_map_entry_alloc() returns.\n\nAfter apply the fix, the error handle for kthread_stop() will be\nunnecessary because it will always return 0, so just remove it.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00016,"ranking_epss":0.03471,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/640a604585aa30f93e39b17d4d6ba69fcb1e66c9","https://git.kernel.org/stable/c/7a1178a3671b40746830d355836b72e47ceb2490","https://git.kernel.org/stable/c/b44d28b98f185d2f2348aa3c3636838c316f889e","https://git.kernel.org/stable/c/ecb45b852af5e88257020b88bea5ff0798d72aca"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53578","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()\n\nSyzbot reported a bug as following:\n\n=====================================================\nBUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230\n qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230\n qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519\n qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108\n call_write_iter include/linux/fs.h:2189 [inline]\n aio_write+0x63a/0x950 fs/aio.c:1600\n io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019\n __do_sys_io_submit fs/aio.c:2078 [inline]\n __se_sys_io_submit+0x293/0x770 fs/aio.c:2048\n __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:766 [inline]\n slab_alloc_node mm/slub.c:3452 [inline]\n __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491\n __do_kmalloc_node mm/slab_common.c:967 [inline]\n __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988\n kmalloc_reserve net/core/skbuff.c:492 [inline]\n __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565\n __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630\n qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446\n qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108\n call_write_iter include/linux/fs.h:2189 [inline]\n aio_write+0x63a/0x950 fs/aio.c:1600\n io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019\n __do_sys_io_submit fs/aio.c:2078 [inline]\n __se_sys_io_submit+0x293/0x770 fs/aio.c:2048\n __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nIt is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt)\nin qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post().\nBut size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type\nequals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot\nscenario. This triggers the uninit variable access bug.\n\nAdd size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in\nqrtr_endpoint_post() to fix the bug.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03059,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3814d211ff13ee35f2d9437439a6c7df58524137","https://git.kernel.org/stable/c/6417070918de3bcdbe0646e7256dae58fd8083ba","https://git.kernel.org/stable/c/8c9ce34a6ff2c544f96ce0b088e8fd3c1b9698c4","https://git.kernel.org/stable/c/bef57c227b52c2bde00fad33556175d36d12cfa0","https://git.kernel.org/stable/c/c6a796ee5a639ffb83c6e5469408cc2ec16cac6a"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53579","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: mvebu: fix irq domain leak\n\nUwe Kleine-König pointed out we still have one resource leak in the mvebu\ndriver triggered on driver detach. Let's address it with a custom devm\naction.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/44e2afbf650f3264519643fcc9e6b4d2f6e8d547","https://git.kernel.org/stable/c/644ee70267a934be27370f9aa618b29af7290544","https://git.kernel.org/stable/c/b19e90521286a03bc3793fd598f20277a8f99c85","https://git.kernel.org/stable/c/d9b791d8362359d241b4e8f4b4767c681ffdb6ef"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53580","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: Gadget: core: Help prevent panic during UVC unconfigure\n\nAvichal Rakesh reported a kernel panic that occurred when the UVC\ngadget driver was removed from a gadget's configuration.  The panic\ninvolves a somewhat complicated interaction between the kernel driver\nand a userspace component (as described in the Link tag below), but\nthe analysis did make one thing clear: The Gadget core should\naccomodate gadget drivers calling usb_gadget_deactivate() as part of\ntheir unbind procedure.\n\nCurrently this doesn't work.  gadget_unbind_driver() calls\ndriver->unbind() while holding the udc->connect_lock mutex, and\nusb_gadget_deactivate() attempts to acquire that mutex, which will\nresult in a deadlock.\n\nThe simple fix is for gadget_unbind_driver() to release the mutex when\ninvoking the ->unbind() callback.  There is no particular reason for\nit to be holding the mutex at that time, and the mutex isn't held\nwhile the ->bind() callback is invoked.  So we'll drop the mutex\nbefore performing the unbind callback and reacquire it afterward.\n\nWe'll also add a couple of comments to usb_gadget_activate() and\nusb_gadget_deactivate().  Because they run in process context they\nmust not be called from a gadget driver's ->disconnect() callback,\nwhich (according to the kerneldoc for struct usb_gadget_driver in\ninclude/linux/usb/gadget.h) may run in interrupt context.  This may\nhelp prevent similar bugs from arising in the future.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0001,"ranking_epss":0.01008,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/65dadb2beeb7360232b09ebc4585b54475dfee06","https://git.kernel.org/stable/c/8c1edc00db65f6d4408b3d1cd845e8da3b9e0ca4","https://git.kernel.org/stable/c/bed19d95fcb9c98dfaa9585922b39a2dfba7898d"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53581","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Check for NOT_READY flag state after locking\n\nCurrently the check for NOT_READY flag is performed before obtaining the\nnecessary lock. This opens a possibility for race condition when the flow\nis concurrently removed from unready_flows list by the workqueue task,\nwhich causes a double-removal from the list and a crash[0]. Fix the issue\nby moving the flag check inside the section protected by\nuplink_priv->unready_flows_lock mutex.\n\n[0]:\n[44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP\n[44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1\n[44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]\n[44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06\n[44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246\n[44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00\n[44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0\n[44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001\n[44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000\n[44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000\n[44376.402999] FS:  00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000\n[44376.403787] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0\n[44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[44376.406339] Call Trace:\n[44376.406651]  <TASK>\n[44376.406939]  ? die_addr+0x33/0x90\n[44376.407311]  ? exc_general_protection+0x192/0x390\n[44376.407795]  ? asm_exc_general_protection+0x22/0x30\n[44376.408292]  ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]\n[44376.408876]  __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core]\n[44376.409482]  mlx5e_tc_del_flow+0x42/0x210 [mlx5_core]\n[44376.410055]  mlx5e_flow_put+0x25/0x50 [mlx5_core]\n[44376.410529]  mlx5e_delete_flower+0x24b/0x350 [mlx5_core]\n[44376.411043]  tc_setup_cb_reoffload+0x22/0x80\n[44376.411462]  fl_reoffload+0x261/0x2f0 [cls_flower]\n[44376.411907]  ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]\n[44376.412481]  ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]\n[44376.413044]  tcf_block_playback_offloads+0x76/0x170\n[44376.413497]  tcf_block_unbind+0x7b/0xd0\n[44376.413881]  tcf_block_setup+0x17d/0x1c0\n[44376.414269]  tcf_block_offload_cmd.isra.0+0xf1/0x130\n[44376.414725]  tcf_block_offload_unbind+0x43/0x70\n[44376.415153]  __tcf_block_put+0x82/0x150\n[44376.415532]  ingress_destroy+0x22/0x30 [sch_ingress]\n[44376.415986]  qdisc_destroy+0x3b/0xd0\n[44376.416343]  qdisc_graft+0x4d0/0x620\n[44376.416706]  tc_get_qdisc+0x1c9/0x3b0\n[44376.417074]  rtnetlink_rcv_msg+0x29c/0x390\n[44376.419978]  ? rep_movs_alternative+0x3a/0xa0\n[44376.420399]  ? rtnl_calcit.isra.0+0x120/0x120\n[44376.420813]  netlink_rcv_skb+0x54/0x100\n[44376.421192]  netlink_unicast+0x1f6/0x2c0\n[44376.421573]  netlink_sendmsg+0x232/0x4a0\n[44376.421980]  sock_sendmsg+0x38/0x60\n[44376.422328]  ____sys_sendmsg+0x1d0/0x1e0\n[44376.422709]  ? copy_msghdr_from_user+0x6d/0xa0\n[44376.423127]  ___sys_sendmsg+0x80/0xc0\n[44376.423495]  ? ___sys_recvmsg+0x8b/0xc0\n[44376.423869]  __sys_sendmsg+0x51/0x90\n[44376.424226]  do_syscall_64+0x3d/0x90\n[44376.424587]  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[44376.425046] RIP: 0033:0x7f045134f887\n[44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00\n---truncated---","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00012,"ranking_epss":0.01453,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/30c281a77fb1b2d362030ea243dd663201d62a21","https://git.kernel.org/stable/c/65e64640e97c0f223e77f9ea69b5a46186b93470","https://git.kernel.org/stable/c/82ac62d76a000871004f534ad294e763e966d3b0","https://git.kernel.org/stable/c/e962fd5933ebc767ce2a1cf7b7c85035b5a5d04c","https://git.kernel.org/stable/c/f7ceedd1d124217a67ed1a67bbd7a7b1288705e3"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53582","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds\n\nFix a stack-out-of-bounds read in brcmfmac that occurs\nwhen 'buf' that is not null-terminated is passed as an argument of\nstrreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with\na CLM version string by memcpy() in brcmf_fil_iovar_data_get().\nEnsure buf is null-terminated.\n\nFound by a modified version of syzkaller.\n\n[   33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available\n[   33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22\n[   33.021554][ T1896] ==================================================================\n[   33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110\n[   33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896\n[   33.023852][ T1896]\n[   33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132\n[   33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\n[   33.026065][ T1896] Workqueue: usb_hub_wq hub_event\n[   33.026581][ T1896] Call Trace:\n[   33.026896][ T1896]  dump_stack_lvl+0x57/0x7d\n[   33.027372][ T1896]  print_address_description.constprop.0.cold+0xf/0x334\n[   33.028037][ T1896]  ? strreplace+0xf2/0x110\n[   33.028403][ T1896]  ? strreplace+0xf2/0x110\n[   33.028807][ T1896]  kasan_report.cold+0x83/0xdf\n[   33.029283][ T1896]  ? strreplace+0xf2/0x110\n[   33.029666][ T1896]  strreplace+0xf2/0x110\n[   33.029966][ T1896]  brcmf_c_preinit_dcmds+0xab1/0xc40\n[   33.030351][ T1896]  ? brcmf_c_set_joinpref_default+0x100/0x100\n[   33.030787][ T1896]  ? rcu_read_lock_sched_held+0xa1/0xd0\n[   33.031223][ T1896]  ? rcu_read_lock_bh_held+0xb0/0xb0\n[   33.031661][ T1896]  ? lock_acquire+0x19d/0x4e0\n[   33.032091][ T1896]  ? find_held_lock+0x2d/0x110\n[   33.032605][ T1896]  ? brcmf_usb_deq+0x1a7/0x260\n[   33.033087][ T1896]  ? brcmf_usb_rx_fill_all+0x5a/0xf0\n[   33.033582][ T1896]  brcmf_attach+0x246/0xd40\n[   33.034022][ T1896]  ? wiphy_new_nm+0x1476/0x1d50\n[   33.034383][ T1896]  ? kmemdup+0x30/0x40\n[   33.034722][ T1896]  brcmf_usb_probe+0x12de/0x1690\n[   33.035223][ T1896]  ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n[   33.035833][ T1896]  usb_probe_interface+0x25f/0x710\n[   33.036315][ T1896]  really_probe+0x1be/0xa90\n[   33.036656][ T1896]  __driver_probe_device+0x2ab/0x460\n[   33.037026][ T1896]  ? usb_match_id.part.0+0x88/0xc0\n[   33.037383][ T1896]  driver_probe_device+0x49/0x120\n[   33.037790][ T1896]  __device_attach_driver+0x18a/0x250\n[   33.038300][ T1896]  ? driver_allows_async_probing+0x120/0x120\n[   33.038986][ T1896]  bus_for_each_drv+0x123/0x1a0\n[   33.039906][ T1896]  ? bus_rescan_devices+0x20/0x20\n[   33.041412][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[   33.041861][ T1896]  ? trace_hardirqs_on+0x1c/0x120\n[   33.042330][ T1896]  __device_attach+0x207/0x330\n[   33.042664][ T1896]  ? device_bind_driver+0xb0/0xb0\n[   33.043026][ T1896]  ? kobject_uevent_env+0x230/0x12c0\n[   33.043515][ T1896]  bus_probe_device+0x1a2/0x260\n[   33.043914][ T1896]  device_add+0xa61/0x1ce0\n[   33.044227][ T1896]  ? __mutex_unlock_slowpath+0xe7/0x660\n[   33.044891][ T1896]  ? __fw_devlink_link_to_suppliers+0x550/0x550\n[   33.045531][ T1896]  usb_set_configuration+0x984/0x1770\n[   33.046051][ T1896]  ? kernfs_create_link+0x175/0x230\n[   33.046548][ T1896]  usb_generic_driver_probe+0x69/0x90\n[   33.046931][ T1896]  usb_probe_device+0x9c/0x220\n[   33.047434][ T1896]  really_probe+0x1be/0xa90\n[   33.047760][ T1896]  __driver_probe_device+0x2ab/0x460\n[   33.048134][ T1896]  driver_probe_device+0x49/0x120\n[   33.048516][ T1896]  __device_attach_driver+0x18a/0x250\n[   33.048910][ T1896]  ? driver_allows_async_probing+0x120/0x120\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0ca2efea4f11c6255061e852ac188264c469c197","https://git.kernel.org/stable/c/3b173b4ad9c001a555f44adc7836d6fe3afbe9ec","https://git.kernel.org/stable/c/423a1297ea72bbddf64dbb0957f2879c0f2aa5d0","https://git.kernel.org/stable/c/660145d708be52f946a82e5b633c020f58f996de","https://git.kernel.org/stable/c/a0f0ce1c8ab9fe90618dc394e3d1568b5a9ac154","https://git.kernel.org/stable/c/c02f733024d70105f22de8dd0a1252a0350cd516","https://git.kernel.org/stable/c/ecb980dc79709c02f579a9c03cb92ccec189ab38"],"published_time":"2025-10-04T16:15:53","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53566","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_rbtree: fix null deref on element insertion\n\nThere is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem():\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n nft_add_set_elem+0x14b0/0x2990\n  nf_tables_newsetelem+0x528/0xb30\n\nFurthermore, there is a possible use-after-free while iterating,\n'node' can be free'd so we need to cache the next value to use.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3fa13203b6d90cc3a33af47b058739f92ab82eef","https://git.kernel.org/stable/c/61ae320a29b0540c16931816299eb86bf2b66c08","https://git.kernel.org/stable/c/899aa5638568abf5d69de7a7bb95e4615157375b","https://git.kernel.org/stable/c/a337706c1fb35aac3f26b48aca80421bdbe1d33a","https://git.kernel.org/stable/c/a836be60a3aabcedcd9c79f545d409ace1f20ba6","https://git.kernel.org/stable/c/b76db53ee8802ee5683f8cb401d7e2ec6f9b3d56","https://git.kernel.org/stable/c/ec5caa765f7f6960011c919c9aeb1467940421f6"],"published_time":"2025-10-04T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53567","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nspi: qup: Don't skip cleanup in remove's error path\n\nReturning early in a platform driver's remove callback is wrong. In this\ncase the dma resources are not released in the error path. this is never\nretried later and so this is a permanent leak. To fix this, only skip\nhardware disabling if waking the device fails.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2d0f63077f481f11a07f20eab1c1f4367dfaef32","https://git.kernel.org/stable/c/49c17fccae36505550c9121891722fff337f148a","https://git.kernel.org/stable/c/55ecdcd12bc176b86fecbcb125ac814ac8fe857a","https://git.kernel.org/stable/c/61f49171a43ab1f80c73c5c88c508770c461e0f2","https://git.kernel.org/stable/c/8632384337038b97910c2f7bb5a3f377aa68d001","https://git.kernel.org/stable/c/bc88243bbe6140d289bb32b4ee4607ba5ce1124a","https://git.kernel.org/stable/c/f345d4d71e87d878437417ffbb9a7d4e16d235eb","https://git.kernel.org/stable/c/fd53f41bd86daa39b454fd4637a908ff2123547f"],"published_time":"2025-10-04T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53568","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ns390/zcrypt: don't leak memory if dev_set_name() fails\n\nWhen dev_set_name() fails, zcdn_create() doesn't free the newly\nallocated resources. Do it.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0878052579cb2773caee64812a811edcab6b5a55","https://git.kernel.org/stable/c/131cd74a8e38d75239f2c81dfee53d6554eb8bf8","https://git.kernel.org/stable/c/147d8da33a2c2195ec63acd56cd7d80a3458c253","https://git.kernel.org/stable/c/174f11ef1615ec3ab1e2189685864433c0d855a2","https://git.kernel.org/stable/c/6252f47b78031979ad919f971dc8468b893488bd","https://git.kernel.org/stable/c/6b0cb9c055843777b374309503d89eabeb769355"],"published_time":"2025-10-04T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53569","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\next2: Check block size validity during mount\n\nCheck that log of block size stored in the superblock has sensible\nvalue. Otherwise the shift computing the block size can overflow leading\nto undefined behavior.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0ebfaf14150f55550cffb1148ed3920143c7a69c","https://git.kernel.org/stable/c/22ab5fed07ad4b206ea910fd0132d1a0d4831584","https://git.kernel.org/stable/c/451b98155be5dfee05bc6e7c8b30c0be4add3f71","https://git.kernel.org/stable/c/62aeb94433fcec80241754b70d0d1836d5926b0a","https://git.kernel.org/stable/c/99f8a15af6c9f0653193104a9e70891f950c6001","https://git.kernel.org/stable/c/c2e7776843a953fd7e48895c3880c277f996193e","https://git.kernel.org/stable/c/c4813f858e5c3e4c4659ce95385c1c400c593e1e","https://git.kernel.org/stable/c/e6f4fb28890c1361e0db9eb1adee3fc04e7fe7f5"],"published_time":"2025-10-04T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53570","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems()\n\nnl80211_parse_mbssid_elems() uses a u8 variable num_elems to count the\nnumber of MBSSID elements in the nested netlink attribute attrs, which can\nlead to an integer overflow if a user of the nl80211 interface specifies\n256 or more elements in the corresponding attribute in userspace. The\ninteger overflow can lead to a heap buffer overflow as num_elems determines\nthe size of the trailing array in elems, and this array is thereafter\nwritten to for each element in attrs.\n\nNote that this vulnerability only affects devices with the\nwiphy->mbssid_max_interfaces member set for the wireless physical device\nstruct in the device driver, and can only be triggered by a process with\nCAP_NET_ADMIN capabilities.\n\nFix this by checking for a maximum of 255 elements in attrs.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00012,"ranking_epss":0.01866,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6311071a056272e1e761de8d0305e87cc566f734","https://git.kernel.org/stable/c/7d09f9f255a5f78578deba5454923072bb53b16c","https://git.kernel.org/stable/c/e642eb67b8c10dcce758d549cc81564116e0fa49"],"published_time":"2025-10-04T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53571","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Make intel_get_crtc_new_encoder() less oopsy\n\nThe point of the WARN was to print something, not oops\nstraight up. Currently that is precisely what happens\nif we can't find the connector for the crtc in the atomic\nstate. Get the dev pointer from the atomic state instead\nof the potentially NULL encoder to avoid that.\n\n(cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0fe6ef82e4f4764e8f556632e4cd93d78d448e99","https://git.kernel.org/stable/c/54202488c835dab8c648acd107f0bb8eaa699894","https://git.kernel.org/stable/c/631420b06597a33c72b6dcef78d1c2dea17f452d","https://git.kernel.org/stable/c/780f303233c35eeb5132e3ee1cbc8f4cebe86dd2","https://git.kernel.org/stable/c/8cd725315c559a8a4d18ac1d7fce1d6b9a667529","https://git.kernel.org/stable/c/fd8b0abecdf66379e9d25d7448b942b5be379cb2"],"published_time":"2025-10-04T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53572","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nclk: imx: scu: use _safe list iterator to avoid a use after free\n\nThis loop is freeing \"clk\" so it needs to use list_for_each_entry_safe().\nOtherwise it dereferences a freed variable to get the next item on the\nloop.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03059,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/08cc7cd2c2a29a2abf5bceb8f048c0734d3694ba","https://git.kernel.org/stable/c/0a719f0e4b6f233979e219baff73923e76a96e09","https://git.kernel.org/stable/c/3d90921f91fc6a8c801d527bb5848c99e335c1cf","https://git.kernel.org/stable/c/632c60ecd25dbacee54d5581fe3aeb834b57010a","https://git.kernel.org/stable/c/f95ff838ac39f861d1f95a0f3bbb1e01c2517d79"],"published_time":"2025-10-04T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53573","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nclk: rs9: Fix suspend/resume\n\nDisabling the cache in commit 2ff4ba9e3702 (\"clk: rs9: Fix I2C accessors\")\nwithout removing cache synchronization in resume path results in a\nkernel panic as map->cache_ops is unset, due to REGCACHE_NONE.\nEnable flat cache again to support resume again. num_reg_defaults_raw\nis necessary to read the cache defaults from hardware. Some registers\nare strapped in hardware and cannot be provided in software.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/632e04739c8f45c2d9ca4d4c5bd18d80c2ac9296","https://git.kernel.org/stable/c/74f4471ad64214dd5046213ebdd6e0930da7bd2c","https://git.kernel.org/stable/c/a983967602675880d6160a17ace2c0f48717ff33"],"published_time":"2025-10-04T16:15:52","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53557","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfprobe: Release rethook after the ftrace_ops is unregistered\n\nWhile running bpf selftests it's possible to get following fault:\n\n  general protection fault, probably for non-canonical address \\\n  0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI\n  ...\n  Call Trace:\n   <TASK>\n   fprobe_handler+0xc1/0x270\n   ? __pfx_bpf_testmod_init+0x10/0x10\n   ? __pfx_bpf_testmod_init+0x10/0x10\n   ? bpf_fentry_test1+0x5/0x10\n   ? bpf_fentry_test1+0x5/0x10\n   ? bpf_testmod_init+0x22/0x80\n   ? do_one_initcall+0x63/0x2e0\n   ? rcu_is_watching+0xd/0x40\n   ? kmalloc_trace+0xaf/0xc0\n   ? do_init_module+0x60/0x250\n   ? __do_sys_finit_module+0xac/0x120\n   ? do_syscall_64+0x37/0x90\n   ? entry_SYSCALL_64_after_hwframe+0x72/0xdc\n   </TASK>\n\nIn unregister_fprobe function we can't release fp->rethook while it's\npossible there are some of its users still running on another cpu.\n\nMoving rethook_free call after fp->ops is unregistered with\nunregister_ftrace_function call.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03d63255a5783243c110aec5e6ae2f1475c3be76","https://git.kernel.org/stable/c/5f81018753dfd4989e33ece1f0cb6b8aae498b82","https://git.kernel.org/stable/c/ce3ec57faff559ccae1e0150c1f077eb2df648a4"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53558","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()\n\npr_info() is called with rtp->cbs_gbl_lock spin lock locked.  Because\npr_info() calls printk() that might sleep, this will result in BUG\nlike below:\n\n[    0.206455] cblist_init_generic: Setting adjustable number of callback queues.\n[    0.206463]\n[    0.206464] =============================\n[    0.206464] [ BUG: Invalid wait context ]\n[    0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted\n[    0.206466] -----------------------------\n[    0.206466] swapper/0/1 is trying to lock:\n[    0.206467] ffffffffa0167a58 (&port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0\n[    0.206473] other info that might help us debug this:\n[    0.206473] context-{5:5}\n[    0.206474] 3 locks held by swapper/0/1:\n[    0.206474]  #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0\n[    0.206478]  #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e\n[    0.206482]  #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330\n[    0.206485] stack backtrace:\n[    0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5\n[    0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014\n[    0.206489] Call Trace:\n[    0.206490]  <TASK>\n[    0.206491]  dump_stack_lvl+0x6a/0x9f\n[    0.206493]  __lock_acquire.cold+0x2d7/0x2fe\n[    0.206496]  ? stack_trace_save+0x46/0x70\n[    0.206497]  lock_acquire+0xd1/0x2f0\n[    0.206499]  ? serial8250_console_write+0x327/0x4a0\n[    0.206500]  ? __lock_acquire+0x5c7/0x2720\n[    0.206502]  _raw_spin_lock_irqsave+0x3d/0x90\n[    0.206504]  ? serial8250_console_write+0x327/0x4a0\n[    0.206506]  serial8250_console_write+0x327/0x4a0\n[    0.206508]  console_emit_next_record.constprop.0+0x180/0x330\n[    0.206511]  console_unlock+0xf7/0x1f0\n[    0.206512]  vprintk_emit+0xf7/0x330\n[    0.206514]  _printk+0x63/0x7e\n[    0.206516]  cblist_init_generic.constprop.0.cold+0x24/0x32\n[    0.206518]  rcu_init_tasks_generic+0x5/0xd9\n[    0.206522]  kernel_init_freeable+0x15b/0x2a2\n[    0.206523]  ? rest_init+0x160/0x160\n[    0.206526]  kernel_init+0x11/0x120\n[    0.206527]  ret_from_fork+0x1f/0x30\n[    0.206530]  </TASK>\n[    0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.\n\nThis patch moves pr_info() so that it is called without\nrtp->cbs_gbl_lock locked.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5fc8cbe4cf0fd34ded8045c385790c3bf04f6785","https://git.kernel.org/stable/c/9027d69221ff96e1356f070f7feb2ff989ae7388","https://git.kernel.org/stable/c/ea9b81c7d9104040b46a84d2303045de267f5557"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53559","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nip_vti: fix potential slab-use-after-free in decode_session6\n\nWhen ip_vti device is set to the qdisc of the sfb type, the cb field\nof the sent skb may be modified during enqueuing. Then,\nslab-use-after-free may occur when ip_vti device sends IPv6 packets.\nAs commit f855691975bb (\"xfrm6: Fix the nexthdr offset in\n_decode_session6.\") showed, xfrm_decode_session was originally intended\nonly for the receive path. IP6CB(skb)->nhoff is not set during\ntransmission. Therefore, set the cb field in the skb to 0 before\nsending packets.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0b4d69539fdea138af2befe08893850c89248068","https://git.kernel.org/stable/c/2b05bf5dc437f7891dd409a3eaf5058459391c7a","https://git.kernel.org/stable/c/6018a266279b1a75143c7c0804dd08a5fc4c3e0b","https://git.kernel.org/stable/c/78e397a43e1c47321a4679cc49a6c4530bf820b9","https://git.kernel.org/stable/c/7dfe23659f3677c08a60a0056cda2d91a79c15ca","https://git.kernel.org/stable/c/82fb41c5de243e7dfa90f32ca58e35adaff56c1d","https://git.kernel.org/stable/c/d34c30442d5e53a33cde79ca163320dbe2432cbd","https://git.kernel.org/stable/c/e1e04cc2ef2c0c0866c19f5627149a76c2baae32"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53560","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Add histograms to hist_vars if they have referenced variables\n\nHist triggers can have referenced variables without having direct\nvariables fields. This can be the case if referenced variables are added\nfor trigger actions. In this case the newly added references will not\nhave field variables. Not taking such referenced variables into\nconsideration can result in a bug where it would be possible to remove\nhist trigger with variables being refenced. This will result in a bug\nthat is easily reproducable like so\n\n$ cd /sys/kernel/tracing\n$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events\n$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger\n$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger\n$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger\n\n[  100.263533] ==================================================================\n[  100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180\n[  100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439\n[  100.266320]\n[  100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4\n[  100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\n[  100.268561] Call Trace:\n[  100.268902]  <TASK>\n[  100.269189]  dump_stack_lvl+0x4c/0x70\n[  100.269680]  print_report+0xc5/0x600\n[  100.270165]  ? resolve_var_refs+0xc7/0x180\n[  100.270697]  ? kasan_complete_mode_report_info+0x80/0x1f0\n[  100.271389]  ? resolve_var_refs+0xc7/0x180\n[  100.271913]  kasan_report+0xbd/0x100\n[  100.272380]  ? resolve_var_refs+0xc7/0x180\n[  100.272920]  __asan_load8+0x71/0xa0\n[  100.273377]  resolve_var_refs+0xc7/0x180\n[  100.273888]  event_hist_trigger+0x749/0x860\n[  100.274505]  ? kasan_save_stack+0x2a/0x50\n[  100.275024]  ? kasan_set_track+0x29/0x40\n[  100.275536]  ? __pfx_event_hist_trigger+0x10/0x10\n[  100.276138]  ? ksys_write+0xd1/0x170\n[  100.276607]  ? do_syscall_64+0x3c/0x90\n[  100.277099]  ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[  100.277771]  ? destroy_hist_data+0x446/0x470\n[  100.278324]  ? event_hist_trigger_parse+0xa6c/0x3860\n[  100.278962]  ? __pfx_event_hist_trigger_parse+0x10/0x10\n[  100.279627]  ? __kasan_check_write+0x18/0x20\n[  100.280177]  ? mutex_unlock+0x85/0xd0\n[  100.280660]  ? __pfx_mutex_unlock+0x10/0x10\n[  100.281200]  ? kfree+0x7b/0x120\n[  100.281619]  ? ____kasan_slab_free+0x15d/0x1d0\n[  100.282197]  ? event_trigger_write+0xac/0x100\n[  100.282764]  ? __kasan_slab_free+0x16/0x20\n[  100.283293]  ? __kmem_cache_free+0x153/0x2f0\n[  100.283844]  ? sched_mm_cid_remote_clear+0xb1/0x250\n[  100.284550]  ? __pfx_sched_mm_cid_remote_clear+0x10/0x10\n[  100.285221]  ? event_trigger_write+0xbc/0x100\n[  100.285781]  ? __kasan_check_read+0x15/0x20\n[  100.286321]  ? __bitmap_weight+0x66/0xa0\n[  100.286833]  ? _find_next_bit+0x46/0xe0\n[  100.287334]  ? task_mm_cid_work+0x37f/0x450\n[  100.287872]  event_triggers_call+0x84/0x150\n[  100.288408]  trace_event_buffer_commit+0x339/0x430\n[  100.289073]  ? ring_buffer_event_data+0x3f/0x60\n[  100.292189]  trace_event_raw_event_sys_enter+0x8b/0xe0\n[  100.295434]  syscall_trace_enter.constprop.0+0x18f/0x1b0\n[  100.298653]  syscall_enter_from_user_mode+0x32/0x40\n[  100.301808]  do_syscall_64+0x1a/0x90\n[  100.304748]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[  100.307775] RIP: 0033:0x7f686c75c1cb\n[  100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48\n[  100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021\n[  100.321200] RA\n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1576f0df7b4d1f82db588d6654b89d796fa06929","https://git.kernel.org/stable/c/4815359056083c555f97a5ee3af86519be5166de","https://git.kernel.org/stable/c/4a540f63618e525e433b37d2b5522cda08e321d7","https://git.kernel.org/stable/c/4ffad1528e81c91769d9da1f8436080861c8ec67","https://git.kernel.org/stable/c/5fd32eb6fa0ac795aa5a64bc004ab68d7b44196a","https://git.kernel.org/stable/c/6018b585e8c6fa7d85d4b38d9ce49a5b67be7078","https://git.kernel.org/stable/c/97f54b330c797ed27fba8791baeaa38ace886cbd"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53561","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: iosm: fix NULL pointer dereference when removing device\n\nIn suspend and resume cycle, the removal and rescan of device ends\nup in NULL pointer dereference.\n\nDuring driver initialization, if the ipc_imem_wwan_channel_init()\nfails to get the valid device capabilities it returns an error and\nfurther no resource (wwan struct) will be allocated. Now in this\nsituation if driver removal procedure is initiated it would result\nin NULL pointer exception since unallocated wwan struct is dereferenced\ninside ipc_wwan_deinit().\n\nipc_imem_run_state_worker() to handle the called functions return value\nand to release the resource in failure case. It also reports the link\ndown event in failure cases. The user space application can handle this\nevent to do a device reset for restoring the device communication.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/60829145f1e2650b31ebe6a0ec70a9725b38fa2c","https://git.kernel.org/stable/c/862c6e3e26735247d8a4df41fa2421909c3f4d63","https://git.kernel.org/stable/c/ee44bacf462db3ec6e4f0dcfa7931e768670d77c"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53562","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: fix vram leak on bind errors\n\nMake sure to release the VRAM buffer also in a case a subcomponent fails\nto bind.\n\nPatchwork: https://patchwork.freedesktop.org/patch/525094/","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/544711591a67a6da4d9f0f70ba3c805eb2548729","https://git.kernel.org/stable/c/60d476af96015891c7959f30838ae7a9749932bf","https://git.kernel.org/stable/c/c02e8c1c5b3eb0b6193946194ac280f58f48b3b5","https://git.kernel.org/stable/c/e3401e07ba98a94b978164b7e873c25e5fc82b4b"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53563","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: amd-pstate-ut: Fix kernel panic when loading the driver\n\nAfter loading the amd-pstate-ut driver, amd_pstate_ut_check_perf()\nand amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy\nof the CPU and mark it as busy.\n\nIn these functions, cpufreq_cpu_put() should be used to release the\npolicy, but it is not, so any other entity trying to access the policy\nis blocked indefinitely.\n\nOne such scenario is when amd_pstate mode is changed, leading to the\nfollowing splat:\n\n[ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds.\n[ 1332.110001]       Not tainted 6.5.0-rc2-amd-pstate-ut #5\n[ 1332.115315] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 1332.123140] task:bash            state:D stack:0     pid:2929  ppid:2873   flags:0x00004006\n[ 1332.123143] Call Trace:\n[ 1332.123145]  <TASK>\n[ 1332.123148]  __schedule+0x3c1/0x16a0\n[ 1332.123154]  ? _raw_read_lock_irqsave+0x2d/0x70\n[ 1332.123157]  schedule+0x6f/0x110\n[ 1332.123160]  schedule_timeout+0x14f/0x160\n[ 1332.123162]  ? preempt_count_add+0x86/0xd0\n[ 1332.123165]  __wait_for_common+0x92/0x190\n[ 1332.123168]  ? __pfx_schedule_timeout+0x10/0x10\n[ 1332.123170]  wait_for_completion+0x28/0x30\n[ 1332.123173]  cpufreq_policy_put_kobj+0x4d/0x90\n[ 1332.123177]  cpufreq_policy_free+0x157/0x1d0\n[ 1332.123178]  ? preempt_count_add+0x58/0xd0\n[ 1332.123180]  cpufreq_remove_dev+0xb6/0x100\n[ 1332.123182]  subsys_interface_unregister+0x114/0x120\n[ 1332.123185]  ? preempt_count_add+0x58/0xd0\n[ 1332.123187]  ? __pfx_amd_pstate_change_driver_mode+0x10/0x10\n[ 1332.123190]  cpufreq_unregister_driver+0x3b/0xd0\n[ 1332.123192]  amd_pstate_change_driver_mode+0x1e/0x50\n[ 1332.123194]  store_status+0xe9/0x180\n[ 1332.123197]  dev_attr_store+0x1b/0x30\n[ 1332.123199]  sysfs_kf_write+0x42/0x50\n[ 1332.123202]  kernfs_fop_write_iter+0x143/0x1d0\n[ 1332.123204]  vfs_write+0x2df/0x400\n[ 1332.123208]  ksys_write+0x6b/0xf0\n[ 1332.123210]  __x64_sys_write+0x1d/0x30\n[ 1332.123213]  do_syscall_64+0x60/0x90\n[ 1332.123216]  ? fpregs_assert_state_consistent+0x2e/0x50\n[ 1332.123219]  ? exit_to_user_mode_prepare+0x49/0x1a0\n[ 1332.123223]  ? irqentry_exit_to_user_mode+0xd/0x20\n[ 1332.123225]  ? irqentry_exit+0x3f/0x50\n[ 1332.123226]  ? exc_page_fault+0x8e/0x190\n[ 1332.123228]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 1332.123232] RIP: 0033:0x7fa74c514a37\n[ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37\n[ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001\n[ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff\n[ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008\n[ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00\n[ 1332.123247]  </TASK>\n\nFix this by calling cpufreq_cpu_put() wherever necessary.\n\n[ rjw: Subject and changelog edits ]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0f74f12ee042fd72e45f0e8700e063c84ef3883b","https://git.kernel.org/stable/c/60dd283804479c4a52f995b713f448e2cd65b8c8","https://git.kernel.org/stable/c/84857640c67405eed258c461b3ef909002f1e201","https://git.kernel.org/stable/c/fcf78a17bbb94bebaa912f0460a1848f7d374c94"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53564","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix defrag path triggering jbd2 ASSERT\n\ncode path:\n\nocfs2_ioctl_move_extents\n ocfs2_move_extents\n  ocfs2_defrag_extent\n   __ocfs2_move_extent\n    + ocfs2_journal_access_di\n    + ocfs2_split_extent  //sub-paths call jbd2_journal_restart\n    + ocfs2_journal_dirty //crash by jbs2 ASSERT\n\ncrash stacks:\n\nPID: 11297  TASK: ffff974a676dcd00  CPU: 67  COMMAND: \"defragfs.ocfs2\"\n #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01\n #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d\n #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d\n #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f\n #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205\n #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6\n #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18\n    [exception RIP: jbd2_journal_dirty_metadata+0x2ba]\n    RIP: ffffffffc09ca54a  RSP: ffffb25d8dad3b70  RFLAGS: 00010207\n    RAX: 0000000000000000  RBX: ffff9706eedc5248  RCX: 0000000000000000\n    RDX: 0000000000000001  RSI: ffff97337029ea28  RDI: ffff9706eedc5250\n    RBP: ffff9703c3520200   R8: 000000000f46b0b2   R9: 0000000000000000\n    R10: 0000000000000001  R11: 00000001000000fe  R12: ffff97337029ea28\n    R13: 0000000000000000  R14: ffff9703de59bf60  R15: ffff9706eedc5250\n    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]\n #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]\n #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]\n\nAnalysis\n\nThis bug has the same root cause of 'commit 7f27ec978b0e (\"ocfs2: call\nocfs2_journal_access_di() before ocfs2_journal_dirty() in\nocfs2_write_end_nolock()\")'.  For this bug, jbd2_journal_restart() is\ncalled by ocfs2_split_extent() during defragmenting.\n\nHow to fix\n\nFor ocfs2_split_extent() can handle journal operations totally by itself. \nCaller doesn't need to call journal access/dirty pair, and caller only\nneeds to call journal start/stop pair.  The fix method is to remove\njournal access/dirty from __ocfs2_move_extent().\n\nThe discussion for this patch:\nhttps://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.02011,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2c559b3ba8e0b9e3c4bb08159a28ccadc698410f","https://git.kernel.org/stable/c/33665d1042666f2e5c736a3df1f453e31f030663","https://git.kernel.org/stable/c/590507ebabd33cd93324c04f9a5538309a5ba934","https://git.kernel.org/stable/c/5f43d34a51ed30e6a60f7e59d224a63014fe2cd5","https://git.kernel.org/stable/c/60eed1e3d45045623e46944ebc7c42c30a4350f0","https://git.kernel.org/stable/c/669134a66d37258e1c4a5cfbd5b82f547ae30fca","https://git.kernel.org/stable/c/7f3b1c28e2908755fb248d3ee8ff56826f2387db","https://git.kernel.org/stable/c/8163ea90d89b7012dd1fa4b28edf5db0c641eca7"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53565","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Check for probe() id argument being NULL\n\nThe probe() id argument may be NULL in 2 scenarios:\n\n1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe\n   the device.\n\n2. If a user tries to manually bind the driver from sysfs then the sdio /\n   pcie / usb probe() function gets called with NULL as id argument.\n\n1. Is being hit by users causing the following oops on resume and causing\nwifi to stop working:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000018\n<snip>\nHardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020\nWorkgueue: events_unbound async_run_entry_fn\nRIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac]\n<snip>\nCall Trace:\n <TASK>\n brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887]\n ? pci_pm_resume+0x5b/0xf0\n ? pci_legacy_resume+0x80/0x80\n dpm_run_callback+0x47/0x150\n device_resume+0xa2/0x1f0\n async_resume+0x1d/0x30\n<snip>\n\nFix this by checking for id being NULL.\n\nIn the PCI and USB cases try a manual lookup of the id so that manually\nbinding the driver through sysfs and more importantly brcmf_pcie_probe()\non resume will work.\n\nFor the SDIO case there is no helper to do a manual sdio_device_id lookup,\nso just directly error out on a NULL id there.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/60fc756fc8e6954a5618eecac73b255d651602e4","https://git.kernel.org/stable/c/84766e77a5c35e2b60e34f570c62fc97adc05e09"],"published_time":"2025-10-04T16:15:51","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53548","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb\n\nThe syzbot fuzzer identified a problem in the usbnet driver:\n\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\nModules linked in:\nCPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023\nWorkqueue: mld mld_ifc_work\nRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\nCode: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7\nRSP: 0018:ffffc9000463f568 EFLAGS: 00010086\nRAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000\nRDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001\nRBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003\nR13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500\nFS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0\nCall Trace:\n <TASK>\n usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453\n __netdev_start_xmit include/linux/netdevice.h:4918 [inline]\n netdev_start_xmit include/linux/netdevice.h:4932 [inline]\n xmit_one net/core/dev.c:3578 [inline]\n dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594\n...\n\nThis bug is caused by the fact that usbnet trusts the bulk endpoint\naddresses its probe routine receives in the driver_info structure, and\nit does not check to see that these endpoints actually exist and have\nthe expected type and directions.\n\nThe fix is simply to add such a check.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0dd3e0c31bf3e933fb85faf1443833aef90b8e46","https://git.kernel.org/stable/c/1bebbd9b8037a9cc75984317cb495dec4824c399","https://git.kernel.org/stable/c/27d0f755d649d388fcd12f01436c9a33289e14e3","https://git.kernel.org/stable/c/53c250ea57cf03af41339234b9855ae284f9db91","https://git.kernel.org/stable/c/5e1627cb43ddf1b24b92eb26f8d958a3f5676ccb","https://git.kernel.org/stable/c/a05ac5d00eb7fcb2fda806caa4f56e88df6bc6bb","https://git.kernel.org/stable/c/a0715d04cf687a7e21f0d6ac8c1d479294a3f6f8","https://git.kernel.org/stable/c/ec0d0be41721aca683c5606354a58ee2c687e3f8"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53549","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Rework long task execution when adding/deleting entries\n\nWhen adding/deleting large number of elements in one step in ipset, it can\ntake a reasonable amount of time and can result in soft lockup errors. The\npatch 5f7b51bf09ba (\"netfilter: ipset: Limit the maximal range of\nconsecutive elements to add/delete\") tried to fix it by limiting the max\nelements to process at all. However it was not enough, it is still possible\nthat we get hung tasks. Lowering the limit is not reasonable, so the\napproach in this patch is as follows: rely on the method used at resizing\nsets and save the state when we reach a smaller internal batch limit,\nunlock/lock and proceed from the saved state. Thus we can avoid long\ncontinuous tasks and at the same time removed the limit to add/delete large\nnumber of elements in one step.\n\nThe nfnl mutex is held during the whole operation which prevents one to\nissue other ipset commands in parallel.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01519,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/24a828f5a54bdeca0846526860d72b3766c5fe95","https://git.kernel.org/stable/c/5e29dc36bd5e2166b834ceb19990d9e68a734d7d","https://git.kernel.org/stable/c/8964cc36ba011dc0e1041131fa2e91fb4c2a811b","https://git.kernel.org/stable/c/a1e1521b463968b4eca7163f61fb6cc54d008061","https://git.kernel.org/stable/c/ee756980e491c829ba0495bb420b7224a9ee26b2"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53550","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: amd-pstate: fix global sysfs attribute type\n\nIn commit 3666062b87ec (\"cpufreq: amd-pstate: move to use bus_get_dev_root()\")\nthe \"amd_pstate\" attributes where moved from a dedicated kobject to the\ncpu root kobject.\n\nWhile the dedicated kobject expects to contain kobj_attributes the root\nkobject needs device_attributes.\n\nAs the changed arguments are not used by the callbacks it works most of\nthe time.\nHowever CFI will detect this issue:\n\n[ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de)\n...\n[ 4947.849409] Call Trace:\n[ 4947.849410]  <TASK>\n[ 4947.849411]  ? __warn+0xcf/0x1c0\n[ 4947.849414]  ? dev_attr_show+0x24/0x60\n[ 4947.849415]  ? report_cfi_failure+0x4e/0x60\n[ 4947.849417]  ? handle_cfi_failure+0x14c/0x1d0\n[ 4947.849419]  ? __cfi_show_status+0x10/0x10\n[ 4947.849420]  ? handle_bug+0x4f/0x90\n[ 4947.849421]  ? exc_invalid_op+0x1a/0x60\n[ 4947.849422]  ? asm_exc_invalid_op+0x1a/0x20\n[ 4947.849424]  ? __cfi_show_status+0x10/0x10\n[ 4947.849425]  ? dev_attr_show+0x24/0x60\n[ 4947.849426]  sysfs_kf_seq_show+0xa6/0x110\n[ 4947.849433]  seq_read_iter+0x16c/0x4b0\n[ 4947.849436]  vfs_read+0x272/0x2d0\n[ 4947.849438]  ksys_read+0x72/0xe0\n[ 4947.849439]  do_syscall_64+0x76/0xb0\n[ 4947.849440]  ? do_user_addr_fault+0x252/0x650\n[ 4947.849442]  ? exc_page_fault+0x7a/0x1b0\n[ 4947.849443]  entry_SYSCALL_64_after_hwframe+0x72/0xdc","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5e720f8c8c9d959283c3908bbf32a91a01a86547","https://git.kernel.org/stable/c/ddcfc33a20380508f7fea18e1c330abe17ed4fc0"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53551","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_serial: Add null pointer check in gserial_resume\n\nConsider a case where gserial_disconnect has already cleared\ngser->ioport. And if a wakeup interrupt triggers afterwards,\ngserial_resume gets called, which will lead to accessing of\ngser->ioport and thus causing null pointer dereference.Add\na null pointer check to prevent this.\n\nAdded a static spinlock to prevent gser->ioport from becoming\nnull after the newly added check.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3b24c980dc07be4550a9d1450ed7057f882530e5","https://git.kernel.org/stable/c/44e004f757a7ae13dfebaadbcfdb1a6f98c10377","https://git.kernel.org/stable/c/5ec63fdbca604568890c577753c6f66c5b3ef0b5","https://git.kernel.org/stable/c/c5360eec648bd506afa304ae4a71f82e13d41897","https://git.kernel.org/stable/c/ec357cd3e8af614855d286dd378725cdc7264df6"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53552","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: mark requests for GuC virtual engines to avoid use-after-free\n\nReferences to i915_requests may be trapped by userspace inside a\nsync_file or dmabuf (dma-resv) and held indefinitely across different\nproceses. To counter-act the memory leaks, we try to not to keep\nreferences from the request past their completion.\nOn the other side on fence release we need to know if rq->engine\nis valid and points to hw engine (true for non-virtual requests).\nTo make it possible extra bit has been added to rq->execution_mask,\nfor marking virtual engines.\n\n(cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00013,"ranking_epss":0.01937,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5eefc5307c983b59344a4cb89009819f580c84fa","https://git.kernel.org/stable/c/7fb464d52fa41c31a6fd1ad82888e67c65935d94","https://git.kernel.org/stable/c/8017a27cec32eac8c8f9430b0a3055840136b856"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53553","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nHID: hyperv: avoid struct memcpy overrun warning\n\nA previous patch addressed the fortified memcpy warning for most\nbuilds, but I still see this one with gcc-9:\n\nIn file included from include/linux/string.h:254,\n                 from drivers/hid/hid-hyperv.c:8:\nIn function 'fortify_memcpy_chk',\n    inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:\ninclude/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]\n  583 |    __write_overflow_field(p_size_field, size);\n      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nMy guess is that the WARN_ON() itself is what confuses gcc, so it no\nlonger sees that there is a correct range check. Rework the code in a\nway that helps readability and avoids the warning.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5f151364b1da6bd217632fd4ee8cc24eaf66a497","https://git.kernel.org/stable/c/a7902cc5f5b9c95997017c8e309da760fb1deb6e"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53554","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()\n\nThe \"exc->key_len\" is a u16 that comes from the user.  If it's over\nIW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04358,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5373a1aa91b2298f9305794b8270cf9896be96b6","https://git.kernel.org/stable/c/5f1c7031e044cb2fba82836d55cc235e2ad619dc","https://git.kernel.org/stable/c/663fff29fd613e2b0d30c4138157312ba93c4939","https://git.kernel.org/stable/c/7ae9f55a495077f838bab466411ee6f38574df9b","https://git.kernel.org/stable/c/9496fb96ddeb740dc6b966f4a7d8dfb8b93921c6","https://git.kernel.org/stable/c/b1b04b56745bc79286c80aa876fabfab1e08ebf1","https://git.kernel.org/stable/c/baf420e30364ef9efe3e29a5c0e01e612aebf3fe","https://git.kernel.org/stable/c/caac4b6c15b66feae4d83f602e1e46f124540202"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53555","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/core: initialize damo_filter->list from damos_new_filter()\n\ndamos_new_filter() is not initializing the list field of newly allocated\nfilter object.  However, DAMON sysfs interface and DAMON_RECLAIM are not\ninitializing it after calling damos_new_filter().  As a result, accessing\nuninitialized memory is possible.  Actually, adding multiple DAMOS filters\nvia DAMON sysfs interface caused NULL pointer dereferencing.  Initialize\nthe field just after the allocation from damos_new_filter().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5f1fc67f2cb8d3035d3acd273b48b97835af8afd","https://git.kernel.org/stable/c/da7beebb49c643cd03c54447ed66595936a7a1ce"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53556","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix use-after-free in free_netdev\n\nWe do netif_napi_add() for all allocated q_vectors[], but potentially\ndo netif_napi_del() for part of them, then kfree q_vectors and leave\ninvalid pointers at dev->napi_list.\n\nReproducer:\n\n  [root@host ~]# cat repro.sh\n  #!/bin/bash\n\n  pf_dbsf=\"0000:41:00.0\"\n  vf0_dbsf=\"0000:41:02.0\"\n  g_pids=()\n\n  function do_set_numvf()\n  {\n      echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs\n      sleep $((RANDOM%3+1))\n      echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs\n      sleep $((RANDOM%3+1))\n  }\n\n  function do_set_channel()\n  {\n      local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)\n      [ -z \"$nic\" ] && { sleep $((RANDOM%3)) ; return 1; }\n      ifconfig $nic 192.168.18.5 netmask 255.255.255.0\n      ifconfig $nic up\n      ethtool -L $nic combined 1\n      ethtool -L $nic combined 4\n      sleep $((RANDOM%3))\n  }\n\n  function on_exit()\n  {\n      local pid\n      for pid in \"${g_pids[@]}\"; do\n          kill -0 \"$pid\" &>/dev/null && kill \"$pid\" &>/dev/null\n      done\n      g_pids=()\n  }\n\n  trap \"on_exit; exit\" EXIT\n\n  while :; do do_set_numvf ; done &\n  g_pids+=($!)\n  while :; do do_set_channel ; done &\n  g_pids+=($!)\n\n  wait\n\nResult:\n\n[ 4093.900222] ==================================================================\n[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390\n[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699\n[ 4093.900233]\n[ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G           O     --------- -t - 4.18.0 #1\n[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021\n[ 4093.900239] Call Trace:\n[ 4093.900244]  dump_stack+0x71/0xab\n[ 4093.900249]  print_address_description+0x6b/0x290\n[ 4093.900251]  ? free_netdev+0x308/0x390\n[ 4093.900252]  kasan_report+0x14a/0x2b0\n[ 4093.900254]  free_netdev+0x308/0x390\n[ 4093.900261]  iavf_remove+0x825/0xd20 [iavf]\n[ 4093.900265]  pci_device_remove+0xa8/0x1f0\n[ 4093.900268]  device_release_driver_internal+0x1c6/0x460\n[ 4093.900271]  pci_stop_bus_device+0x101/0x150\n[ 4093.900273]  pci_stop_and_remove_bus_device+0xe/0x20\n[ 4093.900275]  pci_iov_remove_virtfn+0x187/0x420\n[ 4093.900277]  ? pci_iov_add_virtfn+0xe10/0xe10\n[ 4093.900278]  ? pci_get_subsys+0x90/0x90\n[ 4093.900280]  sriov_disable+0xed/0x3e0\n[ 4093.900282]  ? bus_find_device+0x12d/0x1a0\n[ 4093.900290]  i40e_free_vfs+0x754/0x1210 [i40e]\n[ 4093.900298]  ? i40e_reset_all_vfs+0x880/0x880 [i40e]\n[ 4093.900299]  ? pci_get_device+0x7c/0x90\n[ 4093.900300]  ? pci_get_subsys+0x90/0x90\n[ 4093.900306]  ? pci_vfs_assigned.part.7+0x144/0x210\n[ 4093.900309]  ? __mutex_lock_slowpath+0x10/0x10\n[ 4093.900315]  i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]\n[ 4093.900318]  sriov_numvfs_store+0x214/0x290\n[ 4093.900320]  ? sriov_totalvfs_show+0x30/0x30\n[ 4093.900321]  ? __mutex_lock_slowpath+0x10/0x10\n[ 4093.900323]  ? __check_object_size+0x15a/0x350\n[ 4093.900326]  kernfs_fop_write+0x280/0x3f0\n[ 4093.900329]  vfs_write+0x145/0x440\n[ 4093.900330]  ksys_write+0xab/0x160\n[ 4093.900332]  ? __ia32_sys_read+0xb0/0xb0\n[ 4093.900334]  ? fput_many+0x1a/0x120\n[ 4093.900335]  ? filp_close+0xf0/0x130\n[ 4093.900338]  do_syscall_64+0xa0/0x370\n[ 4093.900339]  ? page_fault+0x8/0x30\n[ 4093.900341]  entry_SYSCALL_64_after_hwframe+0x65/0xca\n[ 4093.900357] RIP: 0033:0x7f16ad4d22c0\n[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24\n[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0\n[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001\n[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700\n[ 4093.9003\n---truncated---","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/17046107ca15d7571551539d94e76aba2bf71fd3","https://git.kernel.org/stable/c/345c44e18cc10cded85cb9134830e1684495c866","https://git.kernel.org/stable/c/5f4fa1672d98fe99d2297b03add35346f1685d6b","https://git.kernel.org/stable/c/8d781a9c53034813c3194b7d94409c7d24ac73eb","https://git.kernel.org/stable/c/a4635f190f332304db4a49e827ece790b804b5db","https://git.kernel.org/stable/c/ca12b98e04b5d1902ac08fe826d3500cb4b6e891"],"published_time":"2025-10-04T16:15:50","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53540","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: reject auth/assoc to AP with our address\n\nIf the AP uses our own address as its MLD address or BSSID, then\nclearly something's wrong. Reject such connections so we don't\ntry and fail later.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/07added2c6cd63de047bc786b39436322abb67c0","https://git.kernel.org/stable/c/5d4e04bf3a0f098bd9033de3a5291810fa14c7a6","https://git.kernel.org/stable/c/676a423410131d111a264d29aecbe6aadd57fb22"],"published_time":"2025-10-04T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53541","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write\n\nWhen the oob buffer length is not in multiple of words, the oob write\nfunction does out-of-bounds read on the oob source buffer at the last\niteration. Fix that by always checking length limit on the oob buffer\nread and fill with 0xff when reaching the end of the buffer to the oob\nregisters.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/14b1d00520b4d6a4818364334ce472b79cfc8976","https://git.kernel.org/stable/c/2353b7bb61e45e7cfd21505d0c6747ac8c9496a1","https://git.kernel.org/stable/c/2bc3d6ac704ea7263175ea3da663fdbbb7f3dd8b","https://git.kernel.org/stable/c/45fe4ad7f439799ee1b7b5f80bf82e8b34a98d25","https://git.kernel.org/stable/c/5d53244186c9ac58cb88d76a0958ca55b83a15cd","https://git.kernel.org/stable/c/648d1150a688698e37f7aaf302860180901cb30e","https://git.kernel.org/stable/c/aae45746f4aee9818296e0500e0703e9d8caa5b8","https://git.kernel.org/stable/c/d00b031266514a9395124704630b056a5185ec17"],"published_time":"2025-10-04T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53542","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy\n\nFor some reason, the driver adding support for Exynos5420 MIPI phy\nback in 2016 wasn't used on Exynos5420, which caused a kernel panic.\nAdd the proper compatible for it.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/199624f3144d79fab1cff533ce6a4b82390520a3","https://git.kernel.org/stable/c/29961ee63dd676cc67f7c00f76faa21e11f0d7c6","https://git.kernel.org/stable/c/2e68a0f7bc576318a58335c31c542b358bc63f83","https://git.kernel.org/stable/c/537bdfc1a67836fbd68bbe4210bc380f72cca47f","https://git.kernel.org/stable/c/5d5aa219a790d61cad2c38e1aa32058f16ad2f0b","https://git.kernel.org/stable/c/c075aa3467a799855a92289a3c619afc0a2ad193","https://git.kernel.org/stable/c/f10001af0f7246cf3e43530d25f8d59a8db10df6","https://git.kernel.org/stable/c/f2a6198f5ed7d6e4e06d87a4de007f2e45cc9583"],"published_time":"2025-10-04T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53543","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nvdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check\n\nThe vdpa_nl_policy structure is used to validate the nlattr when parsing\nthe incoming nlmsg. It will ensure the attribute being described produces\na valid nlattr pointer in info->attrs before entering into each handler\nin vdpa_nl_ops.\n\nThat is to say, the missing part in vdpa_nl_policy may lead to illegal\nnlattr after parsing, which could lead to OOB read just like CVE-2023-3773.\n\nThis patch adds the missing nla_policy for vdpa max vqp attr to avoid\nsuch bugs.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00012,"ranking_epss":0.01866,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5d6ba607d6cb5c58a4ddf33381e18c83dbb4098f","https://git.kernel.org/stable/c/ea65e8b5e6b1a34deda7564f09c90e9e80db436a","https://git.kernel.org/stable/c/ff71709445ac033e6e250d971683110e4781c068"],"published_time":"2025-10-04T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53544","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: davinci: Fix clk use after free\n\nThe remove function first frees the clks and only then calls\ncpufreq_unregister_driver(). If one of the cpufreq callbacks is called\njust before cpufreq_unregister_driver() is run, the freed clks might be\nused.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00016,"ranking_epss":0.03471,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5d8f384a9b4fc50f6a18405f1c08e5a87a77b5b3","https://git.kernel.org/stable/c/66b3bbe6fbd8dd410868e5b53ac3944a934b9310","https://git.kernel.org/stable/c/a5f024d0e6f91e05c816ad4ee8837173369dd5cb","https://git.kernel.org/stable/c/ab05ae4ab831f64bbc427592c86f599ed9c4324f"],"published_time":"2025-10-04T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53545","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: unmap and remove csa_va properly\n\nRoot PD BO should be reserved before unmap and remove\na bo_va from VM otherwise lockdep will complain.\n\nv2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)\n\n[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu]\n[14616.937096] Call Trace:\n[14616.937097]  <TASK>\n[14616.937102]  amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu]\n[14616.937187]  drm_file_free+0x1d6/0x300 [drm]\n[14616.937207]  drm_close_helper.isra.0+0x62/0x70 [drm]\n[14616.937220]  drm_release+0x5e/0x100 [drm]\n[14616.937234]  __fput+0x9f/0x280\n[14616.937239]  ____fput+0xe/0x20\n[14616.937241]  task_work_run+0x61/0x90\n[14616.937246]  exit_to_user_mode_prepare+0x215/0x220\n[14616.937251]  syscall_exit_to_user_mode+0x2a/0x60\n[14616.937254]  do_syscall_64+0x48/0x90\n[14616.937257]  entry_SYSCALL_64_after_hwframe+0x63/0xcd","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00017,"ranking_epss":0.0393,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5daff15cd013422bc6d1efcfe82b586800025384","https://git.kernel.org/stable/c/a3a96bf843c356d1d9b2d7f6d0784b6ee28ca9d0","https://git.kernel.org/stable/c/ae325b245208394279a1dc412c831ebd71befb0d"],"published_time":"2025-10-04T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53546","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx\n\nwhen mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memory\npointed by 'in' is not released, which will cause memory leak. Move memory\nrelease after mlx5_cmd_exec.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/00cecb0a8f9e7a21754d5ad85813ab6b47b3308f","https://git.kernel.org/stable/c/165159854757dbae0dfd1812b27051da35aa6223","https://git.kernel.org/stable/c/3169c3854397f3070a63b1b772db16dcb8cba7b4","https://git.kernel.org/stable/c/5dd77585dd9d0e03dd1bceb95f0269a7eaf6b936","https://git.kernel.org/stable/c/622d71d99124e69f7bf2e2b7a89f5f444a24d235","https://git.kernel.org/stable/c/800d8c96bf997da5eb76ccf8d88795c4231c83fb"],"published_time":"2025-10-04T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53547","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix sdma v4 sw fini error\n\nFix sdma v4 sw fini error for sdma 4.2.2 to\nsolve the following general protection fault\n\n[  +0.108196] general protection fault, probably for non-canonical\naddress 0xd5e5a4ae79d24a32: 0000 [#1] PREEMPT SMP PTI\n[  +0.000018] RIP: 0010:free_fw_priv+0xd/0x70\n[  +0.000022] Call Trace:\n[  +0.000012]  <TASK>\n[  +0.000011]  release_firmware+0x55/0x80\n[  +0.000021]  amdgpu_ucode_release+0x11/0x20 [amdgpu]\n[  +0.000415]  amdgpu_sdma_destroy_inst_ctx+0x4f/0x90 [amdgpu]\n[  +0.000360]  sdma_v4_0_sw_fini+0xce/0x110 [amdgpu]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0ebc02d9ff85626a526353584526da6aa9c96792","https://git.kernel.org/stable/c/210ef6cd8e634f18fd889421012192b81325b27b","https://git.kernel.org/stable/c/5e08e9c742a00384e5abe74bd40cf4dc15cb3a2e"],"published_time":"2025-10-04T16:15:49","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50508","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt76x0: fix oob access in mt76x0_phy_get_target_power\n\nAfter 'commit ba45841ca5eb (\"wifi: mt76: mt76x02: simplify struct\nmt76x02_rate_power\")', mt76x02 relies on ht[0-7] rate_power data for\nvht mcs{0,7}, while it uses vth[0-1] rate_power for vht mcs {8,9}.\nFix a possible out-of-bound access in mt76x0_phy_get_target_power routine.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6e1abc51c945663bddebfa1beb9590ff5b250eb7","https://git.kernel.org/stable/c/bf425c5d7ef6fb4083c1e0d46440f886127b5ee5"],"published_time":"2025-10-04T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53533","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nInput: raspberrypi-ts - fix refcount leak in rpi_ts_probe\n\nrpi_firmware_get() take reference, we need to release it in error paths\nas well. Use devm_rpi_firmware_get() helper to handling the resources.\nAlso remove the existing rpi_firmware_put().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.0002,"ranking_epss":0.05261,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0d6a5c9489c8a3d434e685066119c4333476dccd","https://git.kernel.org/stable/c/1dfa3c9dd27bdc347733d06e980395768520bc3e","https://git.kernel.org/stable/c/36d087e49dabd28d2c13a7532dac72d625ce69fb","https://git.kernel.org/stable/c/5bca3688bdbc3b58a2894b8671a8e2378efe28bd","https://git.kernel.org/stable/c/7acad58049acc6ac148e8b613a6eceeca4bcb4a7","https://git.kernel.org/stable/c/9216aa5cfd86809a2681be3683cd9ac30432de0c","https://git.kernel.org/stable/c/9dbbe9db224c23a60dc7b1e00c701be93328c873"],"published_time":"2025-10-04T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53534","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: mtk_drm_crtc: Add checks for devm_kcalloc\n\nAs the devm_kcalloc may return NULL, the return value needs to be checked\nto avoid NULL poineter dereference.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5bf1e3bd7da625ccf9a22c8cb7d65271e6e47f4c","https://git.kernel.org/stable/c/62952905e195f7350bc230cf0960a74ddbceed5d","https://git.kernel.org/stable/c/67ea657c7891c2f86a7750395640d9bdf2555926","https://git.kernel.org/stable/c/7d569ae98ee5490585929be69fea68047679b7b2","https://git.kernel.org/stable/c/b64b6dff15a38468b8cd33fc7864fa4e02b0933a"],"published_time":"2025-10-04T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53535","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bcmgenet: Add a check for oversized packets\n\nOccasionnaly we may get oversized packets from the hardware which\nexceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early\ncheck which drops the packet to avoid invoking skb_over_panic() and move\non to processing the next packet.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/124ca24e0de958d2e20e0aa1e2434af7b72f8887","https://git.kernel.org/stable/c/411317d2a4a7d6049d8efeef0d32ae43f8baefce","https://git.kernel.org/stable/c/5c0862c2c962052ed5055220a00ac1cefb92fbcd","https://git.kernel.org/stable/c/5f56767fb5f2df875b6553e08dbec6a45431c988","https://git.kernel.org/stable/c/7cdb07e10c1258c08f31b24898930e4ece88d163","https://git.kernel.org/stable/c/841881320562cbeac7046b537b91cd000480cea2","https://git.kernel.org/stable/c/87363d1ab55e497702a9506ff423c422639c8a25","https://git.kernel.org/stable/c/c34b1c0870323649d45c5074828d7f754dea2673"],"published_time":"2025-10-04T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53536","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nblk-crypto: make blk_crypto_evict_key() more robust\n\nIf blk_crypto_evict_key() sees that the key is still in-use (due to a\nbug) or that ->keyslot_evict failed, it currently just returns while\nleaving the key linked into the keyslot management structures.\n\nHowever, blk_crypto_evict_key() is only called in contexts such as inode\neviction where failure is not an option.  So actually the caller\nproceeds with freeing the blk_crypto_key regardless of the return value\nof blk_crypto_evict_key().\n\nThese two assumptions don't match, and the result is that there can be a\nuse-after-free in blk_crypto_reprogram_all_keys() after one of these\nerrors occurs.  (Note, these errors *shouldn't* happen; we're just\ntalking about what happens if they do anyway.)\n\nFix this by making blk_crypto_evict_key() unlink the key from the\nkeyslot management structures even on failure.\n\nAlso improve some comments.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5bb4005fb667c6e2188fa87950f8d5faf2994410","https://git.kernel.org/stable/c/5c62852942667c613de0458fc797c5b8c36112b5","https://git.kernel.org/stable/c/5c7cb94452901a93e90c2230632e2c12a681bc92","https://git.kernel.org/stable/c/64ef787bb1588475163069c2e62fdd8f6c27b1f6","https://git.kernel.org/stable/c/701a8220762ff90615dc91d3543f789391b63298","https://git.kernel.org/stable/c/809a5be62e92a444a3c3d7b9f438019d0b322f55"],"published_time":"2025-10-04T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53537","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid use-after-free for cached IPU bio\n\nxfstest generic/019 reports a bug:\n\nkernel BUG at mm/filemap.c:1619!\nRIP: 0010:folio_end_writeback+0x8a/0x90\nCall Trace:\n end_page_writeback+0x1c/0x60\n f2fs_write_end_io+0x199/0x420\n bio_endio+0x104/0x180\n submit_bio_noacct+0xa5/0x510\n submit_bio+0x48/0x80\n f2fs_submit_write_bio+0x35/0x300\n f2fs_submit_merged_ipu_write+0x2a0/0x2b0\n f2fs_write_single_data_page+0x838/0x8b0\n f2fs_write_cache_pages+0x379/0xa30\n f2fs_write_data_pages+0x30c/0x340\n do_writepages+0xd8/0x1b0\n __writeback_single_inode+0x44/0x370\n writeback_sb_inodes+0x233/0x4d0\n __writeback_inodes_wb+0x56/0xf0\n wb_writeback+0x1dd/0x2d0\n wb_workfn+0x367/0x4a0\n process_one_work+0x21d/0x430\n worker_thread+0x4e/0x3c0\n kthread+0x103/0x130\n ret_from_fork+0x2c/0x50\n\nThe root cause is: after cp_error is set, f2fs_submit_merged_ipu_write()\nin f2fs_write_single_data_page() tries to flush IPU bio in cache, however\nf2fs_submit_merged_ipu_write() missed to check validity of @bio parameter,\nresult in submitting random cached bio which belong to other IO context,\nthen it will cause use-after-free issue, fix it by adding additional\nvalidity check.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5cdb422c839134273866208dad5360835ddb9794","https://git.kernel.org/stable/c/7d058f0ab161437369ad6e45a4b67c2886e71373","https://git.kernel.org/stable/c/97ec6f1788cc6bee3f8c89cb908e1a2a1cd859bb","https://git.kernel.org/stable/c/9a7f63283af6befc0f91d549f4f6917dff7479a9","https://git.kernel.org/stable/c/af4ce124d7bd74cb839bbdaccffbb416771a56b5","https://git.kernel.org/stable/c/b2f423fda64fb49213aa0ed5056079cf295a5df2"],"published_time":"2025-10-04T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53538","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: insert tree mod log move in push_node_left\n\nThere is a fairly unlikely race condition in tree mod log rewind that\ncan result in a kernel panic which has the following trace:\n\n  [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096\n  [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096\n  [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002\n  [530.618] #PF: supervisor read access in kernel mode\n  [530.629] #PF: error_code(0x0000) - not-present page\n  [530.641] PGD 0 P4D 0\n  [530.647] Oops: 0000 [#1] SMP\n  [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S         O  K   5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1\n  [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017\n  [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00\n  [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246\n  [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100\n  [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8\n  [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff\n  [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000\n  [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0\n  [530.848] FS:  00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000\n  [530.866] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0\n  [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  [530.928] Call Trace:\n  [530.934]  ? btrfs_printk+0x13b/0x18c\n  [530.943]  ? btrfs_bio_counter_inc_blocked+0x3d/0x130\n  [530.955]  btrfs_map_bio+0x75/0x330\n  [530.963]  ? kmem_cache_alloc+0x12a/0x2d0\n  [530.973]  ? btrfs_submit_metadata_bio+0x63/0x100\n  [530.984]  btrfs_submit_metadata_bio+0xa4/0x100\n  [530.995]  submit_extent_page+0x30f/0x360\n  [531.004]  read_extent_buffer_pages+0x49e/0x6d0\n  [531.015]  ? submit_extent_page+0x360/0x360\n  [531.025]  btree_read_extent_buffer_pages+0x5f/0x150\n  [531.037]  read_tree_block+0x37/0x60\n  [531.046]  read_block_for_search+0x18b/0x410\n  [531.056]  btrfs_search_old_slot+0x198/0x2f0\n  [531.066]  resolve_indirect_ref+0xfe/0x6f0\n  [531.076]  ? ulist_alloc+0x31/0x60\n  [531.084]  ? kmem_cache_alloc_trace+0x12e/0x2b0\n  [531.095]  find_parent_nodes+0x720/0x1830\n  [531.105]  ? ulist_alloc+0x10/0x60\n  [531.113]  iterate_extent_inodes+0xea/0x370\n  [531.123]  ? btrfs_previous_extent_item+0x8f/0x110\n  [531.134]  ? btrfs_search_path_in_tree+0x240/0x240\n  [531.146]  iterate_inodes_from_logical+0x98/0xd0\n  [531.157]  ? btrfs_search_path_in_tree+0x240/0x240\n  [531.168]  btrfs_ioctl_logical_to_ino+0xd9/0x180\n  [531.179]  btrfs_ioctl+0xe2/0x2eb0\n\nThis occurs when logical inode resolution takes a tree mod log sequence\nnumber, and then while backref walking hits a rewind on a busy node\nwhich has the following sequence of tree mod log operations (numbers\nfilled in from a specific example, but they are somewhat arbitrary)\n\n  REMOVE_WHILE_FREEING slot 532\n  REMOVE_WHILE_FREEING slot 531\n  REMOVE_WHILE_FREEING slot 530\n  ...\n  REMOVE_WHILE_FREEING slot 0\n  REMOVE slot 455\n  REMOVE slot 454\n  REMOVE slot 453\n  ...\n  REMOVE slot 0\n  ADD slot 455\n  ADD slot 454\n  ADD slot 453\n  ...\n  ADD slot 0\n  MOVE src slot 0 -> dst slot 456 nritems 533\n  REMOVE slot 455\n  REMOVE slot 454\n  REMOVE slot 453\n  ...\n  REMOVE slot 0\n\nWhen this sequence gets applied via btrfs_tree_mod_log_rewind, it\nallocates a fresh rewind eb, and first inserts the correct key info for\nthe 533 elements, then overwrites the first 456 of them, then decrements\nthe count by 456 via the add ops, then rewinds the move by doing a\nmemmove from 456:988->0:532. We have never written anything past 532,\n---truncated---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04621,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/11f14402fe3437852cb44945b3b9f1bdb4032956","https://git.kernel.org/stable/c/5cead5422a0e3d13b0bcee986c0f5c4ebb94100b"],"published_time":"2025-10-04T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53539","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix incomplete state save in rxe_requester\n\nIf a send packet is dropped by the IP layer in rxe_requester()\nthe call to rxe_xmit_packet() can fail with err == -EAGAIN.\nTo recover, the state of the wqe is restored to the state before\nthe packet was sent so it can be resent. However, the routines\nthat save and restore the state miss a significnt part of the\nvariable state in the wqe, the dma struct which is used to process\nthrough the sge table. And, the state is not saved before the packet\nis built which modifies the dma struct.\n\nUnder heavy stress testing with many QPs on a fast node sending\nlarge messages to a slow node dropped packets are observed and\nthe resent packets are corrupted because the dma struct was not\nrestored. This patch fixes this behavior and allows the test cases\nto succeed.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/255c0e60e1d16874fc151358d94bc8df661600dd","https://git.kernel.org/stable/c/2f2a6422287fe29f9343247d77b645100ece0652","https://git.kernel.org/stable/c/5d122db2ff80cd2aed4dcd630befb56b51ddf947","https://git.kernel.org/stable/c/70518f3aaf5a059b691867d7d2d46b999319656a"],"published_time":"2025-10-04T16:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50499","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-core: Fix double free in dvb_register_device()\n\nIn function dvb_register_device() -> dvb_register_media_device() ->\ndvb_create_media_entity(), dvb->entity is allocated and initialized. If\nthe initialization fails, it frees the dvb->entity, and return an error\ncode. The caller takes the error code and handles the error by calling\ndvb_media_device_free(), which unregisters the entity and frees the\nfield again if it is not NULL. As dvb->entity may not NULLed in\ndvb_create_media_entity() when the allocation of dvbdev->pad fails, a\ndouble free may occur. This may also cause an Use After free in\nmedia_device_unregister_entity().\n\nFix this by storing NULL to dvb->entity when it is freed.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0588b12c418c3e4f927ced11f27b02ef4a5bfb07","https://git.kernel.org/stable/c/123eddf92a114e03919942641d2c2b1f4ca56ea6","https://git.kernel.org/stable/c/6b0d0477fce747d4137aa65856318b55fba72198","https://git.kernel.org/stable/c/70bc51303871159796b55ba1a8f16637b46c2511","https://git.kernel.org/stable/c/772892b29ac50c2c5e918fc80104aa6ede81d837","https://git.kernel.org/stable/c/7dd5a68cdbbbe7fc67ba701cb52ba10d8ba149f8","https://git.kernel.org/stable/c/acf984a3718c2458eb9e08b6714490a04f213c58","https://git.kernel.org/stable/c/b21f62b49ee9c3e0216d685d9cfd6003e5727271","https://git.kernel.org/stable/c/e9a78485b658361fab6a5547377be6c1af6f1b3d"],"published_time":"2025-10-04T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50500","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed\n\nIf some items in nsim_dev_resources_register() fail, memory leak will\noccur. The following is the memory leak information.\n\nunreferenced object 0xffff888074c02600 (size 128):\n  comm \"echo\", pid 8159, jiffies 4294945184 (age 493.530s)\n  hex dump (first 32 bytes):\n    40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00  @G..............\n    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................\n  backtrace:\n    [<0000000011a31c98>] kmalloc_trace+0x22/0x60\n    [<0000000027384c69>] devl_resource_register+0x144/0x4e0\n    [<00000000a16db248>] nsim_drv_probe+0x37a/0x1260\n    [<000000007d1f448c>] really_probe+0x20b/0xb10\n    [<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0\n    [<00000000077e0351>] driver_probe_device+0x49/0x140\n    [<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0\n    [<000000008538f359>] bus_for_each_drv+0x151/0x1d0\n    [<0000000038e09747>] __device_attach+0x1c9/0x4e0\n    [<00000000dd86e533>] bus_probe_device+0x1d5/0x280\n    [<00000000839bea35>] device_add+0xae0/0x1cb0\n    [<000000009c2abf46>] new_device_store+0x3b6/0x5f0\n    [<00000000fb823d7f>] bus_attr_store+0x72/0xa0\n    [<000000007acc4295>] sysfs_kf_write+0x106/0x160\n    [<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0\n    [<0000000075eb41bf>] vfs_write+0x8f0/0xc80","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6b1da9f7126f05e857da6db24c6a04aa7974d644","https://git.kernel.org/stable/c/7c4957fe40e2a628b7cceaf4c9bfb5b701774d05"],"published_time":"2025-10-04T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50501","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: coda: Add check for dcoda_iram_alloc\n\nAs the coda_iram_alloc may return NULL pointer,\nit should be better to check the return value\nin order to avoid NULL poineter dereference,\nsame as the others.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/05f165ded4a7baec31b65aba88e2cd1fb9b91db2","https://git.kernel.org/stable/c/2b436f1410245412ea5e4c356a175a928d73eed3","https://git.kernel.org/stable/c/2c6887d5a29024bada6928d1d0959c9990401384","https://git.kernel.org/stable/c/35ddd00b36589cf948875b825eedaab1aefd5ad5","https://git.kernel.org/stable/c/45f57abaee136a1e39d2b04443a1bd5311ba7d94","https://git.kernel.org/stable/c/532417dc98cb9c1185ada4ea4e7ccf965c06bcb5","https://git.kernel.org/stable/c/5688d33aa293dfa122d66bef9c0258ddf7ef11e7","https://git.kernel.org/stable/c/6b8082238fb8bb20f67e46388123e67a5bbc558d","https://git.kernel.org/stable/c/b99872178e7473f21904fdeea38109275aad8ae8"],"published_time":"2025-10-04T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50503","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: lpddr2_nvm: Fix possible null-ptr-deref\n\nIt will cause null-ptr-deref when resource_size(add_range) invoked,\nif platform_get_resource() returns NULL.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0919982a1744346269320615615c7deb14106661","https://git.kernel.org/stable/c/4d10bd7416e8383340b5524b8d616b8ad01ef1e1","https://git.kernel.org/stable/c/6bdd45d795adf9e73b38ced5e7f750cd199499ff","https://git.kernel.org/stable/c/8eb64dc5a790a529ef49ec94b3337af09dac15d3","https://git.kernel.org/stable/c/bb9ccb6121ec4140d366147aa866ceb5a21a8d3d","https://git.kernel.org/stable/c/c4cc41e94d8357f5f02b8ef40257bb23931d8438","https://git.kernel.org/stable/c/e0d3e46ac6669cdf1b99bc7b7d92f1221b9a1ff2","https://git.kernel.org/stable/c/e6aafb57d90ff2c1e18554f3a3c36247a59825ce","https://git.kernel.org/stable/c/f82f63b3911f1b2da68a14d9c4babf3b55feca55"],"published_time":"2025-10-04T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50504","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/rtas: avoid scheduling in rtas_os_term()\n\nIt's unsafe to use rtas_busy_delay() to handle a busy status from\nthe ibm,os-term RTAS function in rtas_os_term():\n\nKernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\nBUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0\npreempt_count: 2, expected: 0\nCPU: 7 PID: 1 Comm: swapper/0 Tainted: G      D            6.0.0-rc5-02182-gf8553a572277-dirty #9\nCall Trace:\n[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)\n[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0\n[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0\n[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4\n[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68\n[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50\n[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0\n[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0\n[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0\n[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420\n[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200\n\nUse rtas_busy_delay_time() instead, which signals without side effects\nwhether to attempt the ibm,os-term RTAS call again.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4768935b8cc2d2afeb7956292df0f6e2c49ca0a5","https://git.kernel.org/stable/c/482d990a5dd1027ee0b70a8a570d56749cac8103","https://git.kernel.org/stable/c/515959eb49e6d218a46979d66f36fdef329ac7d2","https://git.kernel.org/stable/c/6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4","https://git.kernel.org/stable/c/6f7e2fcab73372a371ab4017cbedf7a71f4f9b40","https://git.kernel.org/stable/c/7280fdb80bf0fe35d9b799fc7009f2cbe0a397d7","https://git.kernel.org/stable/c/bed48651c87bef59ea1a9d6dbc381bcbc452f4ff","https://git.kernel.org/stable/c/f413135b337c4e90c1e593c6613f8717e17bc724","https://git.kernel.org/stable/c/ffa991a003abb4f8cb9e5004646bfe2d9a46912c"],"published_time":"2025-10-04T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50505","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix pci device refcount leak in ppr_notifier()\n\nAs comment of pci_get_domain_bus_and_slot() says, it returns\na pci device with refcount increment, when finish using it,\nthe caller must decrement the reference count by calling\npci_dev_put(). So call it before returning from ppr_notifier()\nto avoid refcount leak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/03f51c72997559e73b327608f0cccfded715c9a0","https://git.kernel.org/stable/c/6cf0981c2233f97d56938d9d61845383d6eb227c","https://git.kernel.org/stable/c/6e501b3fd7a2e1c4372d72bc70717aaca2beb8a5","https://git.kernel.org/stable/c/8581ec1feb895ff596fe3d326d9ba320083290aa","https://git.kernel.org/stable/c/902cc2507091a81643502d8ceb0e2f105e902518","https://git.kernel.org/stable/c/b0637f4bd426925f5c3a15e8f8e36190fe06bac5","https://git.kernel.org/stable/c/bdb2113dd8f17a3cc84a2b4be4968a849f69ec72","https://git.kernel.org/stable/c/efd50c65fd1cdef63eb58825f3fe72496443764c"],"published_time":"2025-10-04T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50506","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrbd: only clone bio if we have a backing device\n\nCommit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a\nbio_set_dev call (which has since been removed) to \"earlier\", from\ndrbd_request_prepare to drbd_req_new.\n\nThe problem is that this accesses device->ldev->backing_bdev, which is\nnot NULL-checked at this point. When we don't have an ldev (i.e. when\nthe DRBD device is diskless), this leads to a null pointer deref.\n\nSo, only allocate the private_bio if we actually have a disk. This is\nalso a small optimization, since we don't clone the bio to only to\nimmediately free it again in the diskless case.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/05580a3bbf3cec677cb00a85dfeb21d6a9b48eaf","https://git.kernel.org/stable/c/6d42ddf7f27b6723549ee6d4c8b1b418b59bf6b5"],"published_time":"2025-10-04T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50507","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate data run offset\n\nThis adds sanity checks for data run offset. We should make sure data\nrun offset is legit before trying to unpack them, otherwise we may\nencounter use-after-free or some unexpected memory access behaviors.\n\n[   82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570\n[   82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240\n[   82.941670]\n[   82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15\n[   82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[   82.943720] Call Trace:\n[   82.944204]  <TASK>\n[   82.944471]  dump_stack_lvl+0x49/0x63\n[   82.944908]  print_report.cold+0xf5/0x67b\n[   82.945141]  ? __wait_on_bit+0x106/0x120\n[   82.945750]  ? run_unpack+0x2e3/0x570\n[   82.946626]  kasan_report+0xa7/0x120\n[   82.947046]  ? run_unpack+0x2e3/0x570\n[   82.947280]  __asan_load1+0x51/0x60\n[   82.947483]  run_unpack+0x2e3/0x570\n[   82.947709]  ? memcpy+0x4e/0x70\n[   82.947927]  ? run_pack+0x7a0/0x7a0\n[   82.948158]  run_unpack_ex+0xad/0x3f0\n[   82.948399]  ? mi_enum_attr+0x14a/0x200\n[   82.948717]  ? run_unpack+0x570/0x570\n[   82.949072]  ? ni_enum_attr_ex+0x1b2/0x1c0\n[   82.949332]  ? ni_fname_type.part.0+0xd0/0xd0\n[   82.949611]  ? mi_read+0x262/0x2c0\n[   82.949970]  ? ntfs_cmp_names_cpu+0x125/0x180\n[   82.950249]  ntfs_iget5+0x632/0x1870\n[   82.950621]  ? ntfs_get_block_bmap+0x70/0x70\n[   82.951192]  ? evict+0x223/0x280\n[   82.951525]  ? iput.part.0+0x286/0x320\n[   82.951969]  ntfs_fill_super+0x1321/0x1e20\n[   82.952436]  ? put_ntfs+0x1d0/0x1d0\n[   82.952822]  ? vsprintf+0x20/0x20\n[   82.953188]  ? mutex_unlock+0x81/0xd0\n[   82.953379]  ? set_blocksize+0x95/0x150\n[   82.954001]  get_tree_bdev+0x232/0x370\n[   82.954438]  ? put_ntfs+0x1d0/0x1d0\n[   82.954700]  ntfs_fs_get_tree+0x15/0x20\n[   82.955049]  vfs_get_tree+0x4c/0x130\n[   82.955292]  path_mount+0x645/0xfd0\n[   82.955615]  ? putname+0x80/0xa0\n[   82.955955]  ? finish_automount+0x2e0/0x2e0\n[   82.956310]  ? kmem_cache_free+0x110/0x390\n[   82.956723]  ? putname+0x80/0xa0\n[   82.957023]  do_mount+0xd6/0xf0\n[   82.957411]  ? path_mount+0xfd0/0xfd0\n[   82.957638]  ? __kasan_check_write+0x14/0x20\n[   82.957948]  __x64_sys_mount+0xca/0x110\n[   82.958310]  do_syscall_64+0x3b/0x90\n[   82.958719]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[   82.959341] RIP: 0033:0x7fd0d1ce948a\n[   82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[   82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5\n[   82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a\n[   82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0\n[   82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020\n[   82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0\n[   82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.0001,"ranking_epss":0.01122,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6db620863f8528ed9a9aa5ad323b26554a17881d","https://git.kernel.org/stable/c/9173b89c16a603d73c434b695fe2a7a13491300f","https://git.kernel.org/stable/c/de5e0955248ff90a2ae91e7f5c108392b52152d0","https://git.kernel.org/stable/c/e0455361d3068066a91fe18282b751925d7b5ee7"],"published_time":"2025-10-04T16:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50491","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: cti: Fix hang in cti_disable_hw()\n\ncti_enable_hw() and cti_disable_hw() are called from an atomic context\nso shouldn't use runtime PM because it can result in a sleep when\ncommunicating with firmware.\n\nSince commit 3c6656337852 (\"Revert \"firmware: arm_scmi: Add clock\nmanagement to the SCMI power domain\"\"), this causes a hang on Juno when\nrunning the Perf Coresight tests or running this command:\n\n  perf record -e cs_etm//u -- ls\n\nThis was also missed until the revert commit because pm_runtime_put()\nwas called with the wrong device until commit 692c9a499b28 (\"coresight:\ncti: Correct the parameter for pm_runtime_put\")\n\nWith lock and scheduler debugging enabled the following is output:\n\n   coresight cti_sys0: cti_enable_hw -- dev:cti_sys0  parent: 20020000.cti\n   BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151\n   in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec\n   preempt_count: 2, expected: 0\n   RCU nest depth: 0, expected: 0\n   INFO: lockdep is turned off.\n   irq event stamp: 0\n   hardirqs last  enabled at (0): [<0000000000000000>] 0x0\n   hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948\n   softirqs last  enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948\n   softirqs last disabled at (0): [<0000000000000000>] 0x0\n   CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7\n   Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022\n   Call trace:\n    dump_backtrace+0x134/0x140\n    show_stack+0x20/0x58\n    dump_stack_lvl+0x8c/0xb8\n    dump_stack+0x18/0x34\n    __might_resched+0x180/0x228\n    __might_sleep+0x50/0x88\n    __pm_runtime_resume+0xac/0xb0\n    cti_enable+0x44/0x120\n    coresight_control_assoc_ectdev+0xc0/0x150\n    coresight_enable_path+0xb4/0x288\n    etm_event_start+0x138/0x170\n    etm_event_add+0x48/0x70\n    event_sched_in.isra.122+0xb4/0x280\n    merge_sched_in+0x1fc/0x3d0\n    visit_groups_merge.constprop.137+0x16c/0x4b0\n    ctx_sched_in+0x114/0x1f0\n    perf_event_sched_in+0x60/0x90\n    ctx_resched+0x68/0xb0\n    perf_event_exec+0x138/0x508\n    begin_new_exec+0x52c/0xd40\n    load_elf_binary+0x6b8/0x17d0\n    bprm_execve+0x360/0x7f8\n    do_execveat_common.isra.47+0x218/0x238\n    __arm64_sys_execve+0x48/0x60\n    invoke_syscall+0x4c/0x110\n    el0_svc_common.constprop.4+0xfc/0x120\n    do_el0_svc+0x34/0xc0\n    el0_svc+0x40/0x98\n    el0t_64_sync_handler+0x98/0xc0\n    el0t_64_sync+0x170/0x174\n\nFix the issue by removing the runtime PM calls completely. They are not\nneeded here because it must have already been done when building the\npath for a trace.\n\n[ Fix build warnings ]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/4c365a0c21aaf2b8fcc88de8dc298803288f61ac","https://git.kernel.org/stable/c/6746eae4bbaddcc16b40efb33dab79210828b3ce","https://git.kernel.org/stable/c/c51cfba50df8b9e16bfe0e6d4f2f252a4a10063d","https://git.kernel.org/stable/c/e33ce54cef5d429430e3b1ae5c8ee4f4103c4fdc"],"published_time":"2025-10-04T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50492","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: fix use-after-free on probe deferral\n\nThe bridge counter was never reset when tearing down the DRM device so\nthat stale pointers to deallocated structures would be accessed on the\nnext tear down (e.g. after a second late bind deferral).\n\nGiven enough bridges and a few probe deferrals this could currently also\nlead to data beyond the bridge array being corrupted.\n\nPatchwork: https://patchwork.freedesktop.org/patch/502665/","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0a30a47741b6df1f9555a0fac6aebb7e8c363bad","https://git.kernel.org/stable/c/6808abdb33bf90330e70a687d29f038507e06ebb"],"published_time":"2025-10-04T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50493","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix crash when I/O abort times out\n\nWhile performing CPU hotplug, a crash with the following stack was seen:\n\nCall Trace:\n     qla24xx_process_response_queue+0x42a/0x970 [qla2xxx]\n     qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx]\n     qla_nvme_post_cmd+0x166/0x240 [qla2xxx]\n     nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc]\n     blk_mq_dispatch_rq_list+0x17b/0x610\n     __blk_mq_sched_dispatch_requests+0xb0/0x140\n     blk_mq_sched_dispatch_requests+0x30/0x60\n     __blk_mq_run_hw_queue+0x35/0x90\n     __blk_mq_delay_run_hw_queue+0x161/0x180\n     blk_execute_rq+0xbe/0x160\n     __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core]\n     nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics]\n     nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc]\n     nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc]\n     process_one_work+0x1e8/0x3c0\n\nOn abort timeout, completion was called without checking if the I/O was\nalready completed.\n\nVerify that I/O and abort request are indeed outstanding before attempting\ncompletion.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/05382ed9142cf8a8a3fb662224477eecc415778b","https://git.kernel.org/stable/c/68ad83188d782b2ecef2e41ac245d27e0710fe8e","https://git.kernel.org/stable/c/cb4dff498468b62e8c520568559b3a9007e104d7","https://git.kernel.org/stable/c/d3871af13aa03fbbe7fbb812eaf140501229a72e"],"published_time":"2025-10-04T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50494","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash\n\nWhen CPU 0 is offline and intel_powerclamp is used to inject\nidle, it generates kernel BUG:\n\nBUG: using smp_processor_id() in preemptible [00000000] code: bash/15687\ncaller is debug_smp_processor_id+0x17/0x20\nCPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57\nCall Trace:\n<TASK>\ndump_stack_lvl+0x49/0x63\ndump_stack+0x10/0x16\ncheck_preemption_disabled+0xdd/0xe0\ndebug_smp_processor_id+0x17/0x20\npowerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]\n...\n...\n\nHere CPU 0 is the control CPU by default and changed to the current CPU,\nif CPU 0 offlined. This check has to be performed under cpus_read_lock(),\nhence the above warning.\n\nUse get_cpu() instead of smp_processor_id() to avoid this BUG.\n\n[ rjw: Subject edits ]","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0f91f66c568b316b19cb042cf50584467b3bdff4","https://git.kernel.org/stable/c/3e799e815097febbcb81b472285be824f5d089f9","https://git.kernel.org/stable/c/418fae0700e85a498062424f8656435c32cdb200","https://git.kernel.org/stable/c/513943bf879d45005213e6f5cfb7d9e9943f589f","https://git.kernel.org/stable/c/5614908434451aafbf9b24cb5247cf1d21269f76","https://git.kernel.org/stable/c/5a646c38f648185ee2c62f2a19da3c6f04e27612","https://git.kernel.org/stable/c/68b99e94a4a2db6ba9b31fe0485e057b9354a640","https://git.kernel.org/stable/c/6904727db0eb62fb0c2dce1cf331c341d97ee4b7","https://git.kernel.org/stable/c/6e2a347b304224b2aeb1c0ea000d1cf8a02cc592"],"published_time":"2025-10-04T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50496","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: Fix UAF in destroy()\n\nDm_cache also has the same UAF problem when dm_resume()\nand dm_destroy() are concurrent.\n\nTherefore, cancelling timer again in destroy().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00014,"ranking_epss":0.02714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/034cbc8d3b47a56acd89453c29632a9c117de09d","https://git.kernel.org/stable/c/2b17026685a270b2beaf1cdd9857fcedd3505c7e","https://git.kernel.org/stable/c/2f097dfac7579fd84ff98eb1d3acd41d53a485f3","https://git.kernel.org/stable/c/4d20032dd90664de09f2902a7ea49ae2f7771746","https://git.kernel.org/stable/c/6a3e412c2ab131c54945327a7676b006f000a209","https://git.kernel.org/stable/c/6a459d8edbdbe7b24db42a5a9f21e6aa9e00c2aa","https://git.kernel.org/stable/c/6ac4f36910764cb510bafc4c3768544f86ca48ca","https://git.kernel.org/stable/c/993406104d2b28fe470126a062ad37a1e21e792e","https://git.kernel.org/stable/c/d2a0b298ebf83ab6236f66788a3541e91ce75a70"],"published_time":"2025-10-04T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50497","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: fix shift-out-of-bounds in check_special_flags\n\nUBSAN reported a shift-out-of-bounds warning:\n\n left shift of 1 by 31 places cannot be represented in type 'int'\n Call Trace:\n  <TASK>\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106\n  ubsan_epilogue+0xa/0x44 lib/ubsan.c:151\n  __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322\n  check_special_flags fs/binfmt_misc.c:241 [inline]\n  create_entry fs/binfmt_misc.c:456 [inline]\n  bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654\n  vfs_write+0x11e/0x580 fs/read_write.c:582\n  ksys_write+0xcf/0x120 fs/read_write.c:637\n  do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n  do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x4194e1\n\nSince the type of Node's flags is unsigned long, we should define these\nmacros with same type too.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00014,"ranking_epss":0.02714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0f1a48994b3e516d5c7fd5d12204fdba7a604771","https://git.kernel.org/stable/c/419b808504c26b3e3342365f34ccd0843e09a7f8","https://git.kernel.org/stable/c/6a46bf558803dd2b959ca7435a5c143efe837217","https://git.kernel.org/stable/c/88cea1676a09f7c45a1438153a126610c33b1590","https://git.kernel.org/stable/c/97382a2639b1cd9631f6069061e9d7062cd2b098","https://git.kernel.org/stable/c/a651bb5ff997b9f02662bcdef3d8b4e6f0d79656","https://git.kernel.org/stable/c/a91123d4bda463469f68f0427adabf8108001f94","https://git.kernel.org/stable/c/dcbc51d31d0afbd45e830e3cf565a7b3ca7bf0d8","https://git.kernel.org/stable/c/ea6145370be8016755c43aca799815fc4b8c88b1"],"published_time":"2025-10-04T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50498","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\neth: alx: take rtnl_lock on resume\n\nZbynek reports that alx trips an rtnl assertion on resume:\n\n RTNL: assertion failed at net/core/dev.c (2891)\n RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0\n Call Trace:\n  <TASK>\n  __alx_open+0x230/0x570 [alx]\n  alx_resume+0x54/0x80 [alx]\n  ? pci_legacy_resume+0x80/0x80\n  dpm_run_callback+0x4a/0x150\n  device_resume+0x8b/0x190\n  async_resume+0x19/0x30\n  async_run_entry_fn+0x30/0x130\n  process_one_work+0x1e5/0x3b0\n\nindeed the driver does not hold rtnl_lock during its internal close\nand re-open functions during suspend/resume. Note that this is not\na huge bug as the driver implements its own locking, and does not\nimplement changing the number of queues, but we need to silence\nthe splat.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6ad1c94e1e7e374d88f0cfd77936dddb8339aaba","https://git.kernel.org/stable/c/6f1991a940b90753b34570f093a21dba366e8cc0","https://git.kernel.org/stable/c/a845a0c4bdece2c0073ecea2fca7c4d5f0550f78","https://git.kernel.org/stable/c/c0323c0fd07804d5874699e93f935cda0d989c67"],"published_time":"2025-10-04T16:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50483","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: avoid buffer leaks on xdp_do_redirect() failure\n\nBefore enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software\nBD in the RX ring between index orig_i and i can have one of 2 refcount\nvalues on its page.\n\nWe are the owner of the current buffer that is being processed, so the\nrefcount will be at least 1.\n\nIf the current owner of the buffer at the diametrically opposed index\nin the RX ring (i.o.w, the other half of this page) has not yet called\nkfree(), this page's refcount could even be 2.\n\nenetc_page_reusable() in enetc_flip_rx_buff() tests for the page\nrefcount against 1, and [ if it's 2 ] does not attempt to reuse it.\n\nBut if enetc_flip_rx_buff() is put after the xdp_do_redirect() call,\nthe page refcount can have one of 3 values. It can also be 0, if there\nis no owner of the other page half, and xdp_do_redirect() for this\nbuffer ran so far that it triggered a flush of the devmap/cpumap bulk\nqueue, and the consumers of those bulk queues also freed the buffer,\nall by the time xdp_do_redirect() returns the execution back to enetc.\n\nThis is the reason why enetc_flip_rx_buff() is called before\nxdp_do_redirect(), but there is a big flaw with that reasoning:\nenetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the\nenetc_page_reusable() branch, and if xdp_do_redirect() returns an error,\nwe call enetc_xdp_free(), which does not deal gracefully with that.\n\nIn fact, what happens is quite special. The page refcounts start as 1.\nenetc_flip_rx_buff() figures they're reusable, transfers these\nrx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and\nbumps the refcount to 2. When xdp_do_redirect() later returns an error,\nwe call the no-op enetc_xdp_free(), but we still haven't lost the\nreference to that page. A copy of it is still at rx_ring->next_to_alloc,\nbut that has refcount 2 (and there are no concurrent owners of it in\nflight, to drop the refcount). What really kills the system is when\nwe'll flip the rx_swbd->page the second time around. With an updated\nrefcount of 2, the page will not be reusable and we'll really leak it.\nThen enetc_new_page() will have to allocate more pages, which will then\neventually leak again on further errors from xdp_do_redirect().\n\nThe problem, summarized, is that we zeroize rx_swbd->page before we're\ncompletely done with it, and this makes it impossible for the error path\nto do something with it.\n\nSince the packet is potentially multi-buffer and therefore the\nrx_swbd->page is potentially an array, manual passing of the old\npointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit\ndifficult.\n\nFor the sake of going with a simple solution, we accept the possibility\nof racing with xdp_do_redirect(), and we move the flip procedure to\nexecute only on the redirect success path. By racing, I mean that the\npage may be deemed as not reusable by enetc (having a refcount of 0),\nbut there will be no leak in that case, either.\n\nOnce we accept that, we have something better to do with buffers on\nXDP_REDIRECT failure. Since we haven't performed half-page flipping yet,\nwe won't, either (and this way, we can avoid enetc_xdp_free()\ncompletely, which gives the entire page to the slab allocator).\nInstead, we'll call enetc_xdp_drop(), which will recycle this half of\nthe buffer back to the RX ring.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03344,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/306526331e7a37e714e11ab7c6d73eb004745224","https://git.kernel.org/stable/c/628050ec952d2e2e46ec9fb6aa07e41139e030c8","https://git.kernel.org/stable/c/7fba523b51ccce5f7981f8a43ad84d664da68131","https://git.kernel.org/stable/c/bcf2c1dc5358dcf7e34a68cdb6b0bbf967801efa"],"published_time":"2025-10-04T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50484","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix potential memory leaks\n\nWhen the driver hits -ENOMEM at allocating a URB or a buffer, it\naborts and goes to the error path that releases the all previously\nallocated resources.  However, when -ENOMEM hits at the middle of the\nsync EP URB allocation loop, the partially allocated URBs might be\nleft without released, because ep->nurbs is still zero at that point.\n\nFix it by setting ep->nurbs at first, so that the error handler loops\nover the full URB list.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0604e5e5537af099ea2f6dfd892afe5c92db8a80","https://git.kernel.org/stable/c/0672215994e2347a9b4f145e2bc1709b1e01cee3","https://git.kernel.org/stable/c/28d8d267af5d73f91d7640cbdb4024703256e36c","https://git.kernel.org/stable/c/46f0aed47673e275d682af60ed26dcc28add8eae","https://git.kernel.org/stable/c/6382da0828995af87aa8b8bef28cc61aceb4aff3","https://git.kernel.org/stable/c/988ec0cd0a2643c25c1658f7c33de2e15a5a2e31","https://git.kernel.org/stable/c/bc1d16d282bca421c6fc31de4b8fd412010f01bd","https://git.kernel.org/stable/c/e4442410f76d66b9f7e854010bce04853f665324","https://git.kernel.org/stable/c/faa8c1ed77d0169955b9b3516b714cc5fb512f27"],"published_time":"2025-10-04T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50485","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: add EXT4_IGET_BAD flag to prevent unexpected bad inode\n\nThere are many places that will get unhappy (and crash) when ext4_iget()\nreturns a bad inode. However, if iget the boot loader inode, allows a bad\ninode to be returned, because the inode may not be initialized. This\nmechanism can be used to bypass some checks and cause panic. To solve this\nproblem, we add a special iget flag EXT4_IGET_BAD. Only with this flag\nwe'd be returning bad inode from ext4_iget(), otherwise we always return\nthe error code if the inode is bad inode.(suggested by Jan Kara)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2142dfa1de61e25b83198af0308ec7689cca25d3","https://git.kernel.org/stable/c/488a5c2bf7543c3cd3f07a025f2e62be91599430","https://git.kernel.org/stable/c/63b1e9bccb71fe7d7e3ddc9877dbdc85e5d2d023","https://git.kernel.org/stable/c/c0a738875c2e9c8c3366d792f8bf7fe508d5e5a5","https://git.kernel.org/stable/c/f725b290ed79ad61e4f721fee95a287892d8b1ad","https://git.kernel.org/stable/c/f7e6b5548f915d7aa435d0764d41eacfb49c6e09"],"published_time":"2025-10-04T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50486","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: Fix return type of netcp_ndo_start_xmit()\n\nWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),\nindirect call targets are validated against the expected function\npointer prototype to make sure the call target is valid to help mitigate\nROP attacks. If they are not identical, there is a failure at run time,\nwhich manifests as either a kernel panic or thread getting killed. A\nproposed warning in clang aims to catch these at compile time, which\nreveals:\n\n  drivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]\n          .ndo_start_xmit         = netcp_ndo_start_xmit,\n                                    ^~~~~~~~~~~~~~~~~~~~\n  1 error generated.\n\n->ndo_start_xmit() in 'struct net_device_ops' expects a return type of\n'netdev_tx_t', not 'int'. Adjust the return type of\nnetcp_ndo_start_xmit() to match the prototype's to resolve the warning\nand CFI failure.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/17bb9bdf701f3e811a9f4820b08b9538ade2641c","https://git.kernel.org/stable/c/1e4953b826e12b31995564a459dbd4e9e4604a35","https://git.kernel.org/stable/c/5b0b6553bf4ad3a435a57e02c68d6075f384e1be","https://git.kernel.org/stable/c/63fe6ff674a96cfcfc0fa8df1051a27aa31c70b4","https://git.kernel.org/stable/c/765636e58ba505cfe4927eda7ee83791b1c6402a","https://git.kernel.org/stable/c/a413ebb6049edd881c6427cfa25a7efddd6a4f74","https://git.kernel.org/stable/c/a447479ea2cf35603b5739ea947885024b901222","https://git.kernel.org/stable/c/d837d74eae077cc3ef9e191ba8535b5f602d4673","https://git.kernel.org/stable/c/dbe1a6b930ae9647e8ce0b684c903ac67d4398eb"],"published_time":"2025-10-04T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50488","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix possible uaf for 'bfqq->bic'\n\nOur test report a uaf for 'bfqq->bic' in 5.10:\n\n==================================================================\nBUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30\n\nCPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014\nCall Trace:\n bfq_select_queue+0x378/0xa30\n bfq_dispatch_request+0xe8/0x130\n blk_mq_do_dispatch_sched+0x62/0xb0\n __blk_mq_sched_dispatch_requests+0x215/0x2a0\n blk_mq_sched_dispatch_requests+0x8f/0xd0\n __blk_mq_run_hw_queue+0x98/0x180\n __blk_mq_delay_run_hw_queue+0x22b/0x240\n blk_mq_run_hw_queue+0xe3/0x190\n blk_mq_sched_insert_requests+0x107/0x200\n blk_mq_flush_plug_list+0x26e/0x3c0\n blk_finish_plug+0x63/0x90\n __iomap_dio_rw+0x7b5/0x910\n iomap_dio_rw+0x36/0x80\n ext4_dio_read_iter+0x146/0x190 [ext4]\n ext4_file_read_iter+0x1e2/0x230 [ext4]\n new_sync_read+0x29f/0x400\n vfs_read+0x24e/0x2d0\n ksys_read+0xd5/0x1b0\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x61/0xc6\n\nCommit 3bc5e683c67d (\"bfq: Split shared queues on move between cgroups\")\nchanges that move process to a new cgroup will allocate a new bfqq to\nuse, however, the old bfqq and new bfqq can point to the same bic:\n\n1) Initial state, two process with io in the same cgroup.\n\nProcess 1       Process 2\n (BIC1)          (BIC2)\n  |  Λ            |  Λ\n  |  |            |  |\n  V  |            V  |\n  bfqq1           bfqq2\n\n2) bfqq1 is merged to bfqq2.\n\nProcess 1       Process 2\n (BIC1)          (BIC2)\n  |               |\n   \\-------------\\|\n                  V\n  bfqq1           bfqq2(coop)\n\n3) Process 1 exit, then issue new io(denoce IOA) from Process 2.\n\n (BIC2)\n  |  Λ\n  |  |\n  V  |\n  bfqq2(coop)\n\n4) Before IOA is completed, move Process 2 to another cgroup and issue io.\n\nProcess 2\n (BIC2)\n   Λ\n   |\\--------------\\\n   |                V\n  bfqq2           bfqq3\n\nNow that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2.\nIf all the requests are completed, and Process 2 exit, BIC2 will be\nfreed while there is no guarantee that bfqq2 will be freed before BIC2.\n\nFix the problem by clearing bfqq->bic while bfqq is detached from bic.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.03059,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/094f3d9314d67691cb21ba091c1b528f6e3c4893","https://git.kernel.org/stable/c/5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a","https://git.kernel.org/stable/c/64dc8c732f5c2b406cc752e6aaa1bd5471159cab","https://git.kernel.org/stable/c/761564d93c8265f65543acf0a576b32d66bfa26a","https://git.kernel.org/stable/c/b22fd72bfebda3956efc4431b60ddfc0a51e03e0"],"published_time":"2025-10-04T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50489","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mipi-dsi: Detach devices when removing the host\n\nWhenever the MIPI-DSI host is unregistered, the code of\nmipi_dsi_host_unregister() loops over every device currently found on that\nbus and will unregister it.\n\nHowever, it doesn't detach it from the bus first, which leads to all kind\nof resource leaks if the host wants to perform some clean up whenever a\ndevice is detached.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/262364574b05676d4b9ebde2ddd3588cd2efd8ce","https://git.kernel.org/stable/c/26c1b4cfe56f040f71a51c92da1f4cac2e3b9455","https://git.kernel.org/stable/c/353ab1c13fdd6e524edde780235a8ce9b892c81c","https://git.kernel.org/stable/c/45120fa5e522d444e3fc1c5a9afc5d53eed91d00","https://git.kernel.org/stable/c/668a8f17b5290d04ef7343636a5588a0692731a1","https://git.kernel.org/stable/c/6fc2cd40db1969ba372ce9536dcfcdb87271eac4","https://git.kernel.org/stable/c/8242167cfc83dd7e4c96f44b45f108db9bb88146","https://git.kernel.org/stable/c/95ae458209f5a556bba98aff872f933694914eb7","https://git.kernel.org/stable/c/c202cda08cd5693645d4990ad1eb2e8068a884ec"],"published_time":"2025-10-04T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50490","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Propagate error from htab_lock_bucket() to userspace\n\nIn __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns\n-EBUSY, it will go to next bucket. Going to next bucket may not only\nskip the elements in current bucket silently, but also incur\nout-of-bound memory access or expose kernel memory to userspace if\ncurrent bucket_cnt is greater than bucket_size or zero.\n\nFixing it by stopping batch operation and returning -EBUSY when\nhtab_lock_bucket() fails, and the application can retry or skip the busy\nbatch as needed.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.0001,"ranking_epss":0.01122,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0e13425104903970a5ede853082d3bbb4edec6f3","https://git.kernel.org/stable/c/4f1f39a8f1ce1b24fee6852d7dcd704ce7c4334d","https://git.kernel.org/stable/c/66a7a92e4d0d091e79148a4c6ec15d1da65f4280","https://git.kernel.org/stable/c/6bfee6eb3d6b96ae730a542909dd22b5f9f50d58"],"published_time":"2025-10-04T16:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50475","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Make sure \"ib_port\" is valid when access sysfs node\n\nThe \"ib_port\" structure must be set before adding the sysfs kobject,\nand reset after removing it, otherwise it may crash when accessing\nthe sysfs node:\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050\n  Mem abort info:\n    ESR = 0x96000006\n    Exception class = DABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n  Data abort info:\n    ISV = 0, ISS = 0x00000006\n    CM = 0, WnR = 0\n  user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5\n  [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000\n  Internal error: Oops: 96000006 [#2] PREEMPT SMP\n  Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci]\n  Process grep (pid: 3372, stack limit = 0x0000000022055c92)\n  CPU: 5 PID: 3372 Comm: grep Tainted: G      D    OE     4.19.161-mlnx.47.gadcd9e3 #1\n  Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep  8 2022\n  pstate: 40000005 (nZcv daif -PAN -UAO)\n  pc : hw_stat_port_show+0x4c/0x80 [ib_core]\n  lr : port_attr_show+0x40/0x58 [ib_core]\n  sp : ffff000029f43b50\n  x29: ffff000029f43b50 x28: 0000000019375000\n  x27: ffff8007b821a540 x26: ffff000029f43e30\n  x25: 0000000000008000 x24: ffff000000eaa958\n  x23: 0000000000001000 x22: ffff8007a4ce3000\n  x21: ffff8007baff8000 x20: ffff8007b9066ac0\n  x19: ffff8007bae97578 x18: 0000000000000000\n  x17: 0000000000000000 x16: 0000000000000000\n  x15: 0000000000000000 x14: 0000000000000000\n  x13: 0000000000000000 x12: 0000000000000000\n  x11: 0000000000000000 x10: 0000000000000000\n  x9 : 0000000000000000 x8 : ffff8007a4ce4000\n  x7 : 0000000000000000 x6 : 000000000000003f\n  x5 : ffff000000e6a280 x4 : ffff8007a4ce3000\n  x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab\n  x1 : ffff8007b9066a10 x0 : ffff8007baff8000\n  Call trace:\n   hw_stat_port_show+0x4c/0x80 [ib_core]\n   port_attr_show+0x40/0x58 [ib_core]\n   sysfs_kf_seq_show+0x8c/0x150\n   kernfs_seq_show+0x44/0x50\n   seq_read+0x1b4/0x45c\n   kernfs_fop_read+0x148/0x1d8\n   __vfs_read+0x58/0x180\n   vfs_read+0x94/0x154\n   ksys_read+0x68/0xd8\n   __arm64_sys_read+0x28/0x34\n   el0_svc_common+0x88/0x18c\n   el0_svc_handler+0x78/0x94\n   el0_svc+0x8/0xe8\n  Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5e15ff29b156bbbdeadae230c8ecd5ecd8ca2477","https://git.kernel.org/stable/c/ac7a7d7079124f46180714b2d41a1703d37101bb","https://git.kernel.org/stable/c/cd06d32a71fbb198b2d43dddf794badd80ffd25d","https://git.kernel.org/stable/c/f981c697b2f9bd5dd2f060e47ff8b5e0a2cd0c06"],"published_time":"2025-10-04T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50476","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nntb_netdev: Use dev_kfree_skb_any() in interrupt context\n\nTX/RX callback handlers (ntb_netdev_tx_handler(),\nntb_netdev_rx_handler()) can be called in interrupt\ncontext via the DMA framework when the respective\nDMA operations have completed. As such, any calls\nby these routines to free skb's, should use the\ninterrupt context safe dev_kfree_skb_any() function.\n\nPreviously, these callback handlers would call the\ninterrupt unsafe version of dev_kfree_skb(). This has\nnot presented an issue on Intel IOAT DMA engines as\nthat driver utilizes tasklets rather than a hard\ninterrupt handler, like the AMD PTDMA DMA driver.\nOn AMD systems, a kernel WARNING message is\nencountered, which is being issued from\nskb_release_head_state() due to in_hardirq()\nbeing true.\n\nBesides the user visible WARNING from the kernel,\nthe other symptom of this bug was that TCP/IP performance\nacross the ntb_netdev interface was very poor, i.e.\napproximately an order of magnitude below what was\nexpected. With the repair to use dev_kfree_skb_any(),\nkernel WARNINGs from skb_release_head_state() ceased\nand TCP/IP performance, as measured by iperf, was on\npar with expected results, approximately 20 Gb/s on\nAMD Milan based server. Note that this performance\nis comparable with Intel based servers.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/07e28a8f450217db679802ebd4de0915556ce846","https://git.kernel.org/stable/c/13286ad1c7c49c606fdcba4cf66f953a1a16c1ca","https://git.kernel.org/stable/c/14d245da57a11e80277ab455aa9b6dcc5ed38a19","https://git.kernel.org/stable/c/21296a52caa6a6bad6debdfe40ad81d4f1a27e69","https://git.kernel.org/stable/c/5f7d78b2b12a9d561f48fa00bab29b40f4616dad","https://git.kernel.org/stable/c/8b78493968ed3cef0326183ed059c55e42f24d5b","https://git.kernel.org/stable/c/a6b9e09403102bdf8402dae734800e4916c7ea58","https://git.kernel.org/stable/c/d4460c82177899751975180c268f352893302221","https://git.kernel.org/stable/c/dd860b39aa7c7b82e6c99b6fdb99d4610ce49d67"],"published_time":"2025-10-04T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50477","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: class: Fix potential memleak in devm_rtc_allocate_device()\n\ndevm_rtc_allocate_device() will alloc a rtc_device first, and then run\ndev_set_name(). If dev_set_name() failed, the rtc_device will memleak.\nMove devm_add_action_or_reset() in front of dev_set_name() to prevent\nmemleak.\n\nunreferenced object 0xffff888110a53000 (size 2048):\n  comm \"python3\", pid 470, jiffies 4296078308 (age 58.882s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff  .........0......\n    08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00  .0..............\n  backtrace:\n    [<000000004aac0364>] kmalloc_trace+0x21/0x110\n    [<000000000ff02202>] devm_rtc_allocate_device+0xd4/0x400\n    [<000000001bdf5639>] devm_rtc_device_register+0x1a/0x80\n    [<00000000351bf81c>] rx4581_probe+0xdd/0x110 [rtc_rx4581]\n    [<00000000f0eba0ae>] spi_probe+0xde/0x130\n    [<00000000bff89ee8>] really_probe+0x175/0x3f0\n    [<00000000128e8d84>] __driver_probe_device+0xe6/0x170\n    [<00000000ee5bf913>] device_driver_attach+0x32/0x80\n    [<00000000f3f28f92>] bind_store+0x10b/0x1a0\n    [<000000009ff812d8>] drv_attr_store+0x49/0x70\n    [<000000008139c323>] sysfs_kf_write+0x8d/0xb0\n    [<00000000b6146e01>] kernfs_fop_write_iter+0x214/0x2d0\n    [<00000000ecbe3895>] vfs_write+0x61a/0x7d0\n    [<00000000aa2196ea>] ksys_write+0xc8/0x190\n    [<0000000046a600f5>] do_syscall_64+0x37/0x90\n    [<00000000541a336f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0bcfc8fd3e596994f527b46730579428b3a4fa5f","https://git.kernel.org/stable/c/59457a0f079eae19aaf322b3cc1c8ba66f55c5f3","https://git.kernel.org/stable/c/60da73808298ff2cfa9f165d55eb3d7aa7078601"],"published_time":"2025-10-04T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50478","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()\n\nPatch series \"nilfs2: fix UBSAN shift-out-of-bounds warnings on mount\ntime\".\n\nThe first patch fixes a bug reported by syzbot, and the second one fixes\nthe remaining bug of the same kind.  Although they are triggered by the\nsame super block data anomaly, I divided it into the above two because the\ndetails of the issues and how to fix it are different.\n\nBoth are required to eliminate the shift-out-of-bounds issues at mount\ntime.\n\n\nThis patch (of 2):\n\nIf the block size exponent information written in an on-disk superblock is\ncorrupted, nilfs_sb2_bad_offset helper function can trigger\nshift-out-of-bounds warning followed by a kernel panic (if panic_on_warn\nis set):\n\n shift exponent 38983 is too large for 64-bit type 'unsigned long long'\n Call Trace:\n  <TASK>\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106\n  ubsan_epilogue lib/ubsan.c:151 [inline]\n  __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322\n  nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline]\n  nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523\n  init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577\n  nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047\n  nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317\n  ...\n\nIn addition, since nilfs_sb2_bad_offset() performs multiplication without\nconsidering the upper bound, the computation may overflow if the disk\nlayout parameters are not normal.\n\nThis fixes these issues by inserting preliminary sanity checks for those\nparameters and by converting the comparison from one involving\nmultiplication and left bit-shifting to one using division and right\nbit-shifting.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00014,"ranking_epss":0.02714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1012ff77284e3bec0ec0a35a820b03ec43dec2cc","https://git.kernel.org/stable/c/610a2a3d7d8be3537458a378ec69396a76c385b6","https://git.kernel.org/stable/c/62d11ec205ef14d8acf172cfc9904fdbf200025a","https://git.kernel.org/stable/c/6b0ea3df56cccd53398d0289f399f19d43136b2e","https://git.kernel.org/stable/c/9b3ba54025357440d6c4414c670984f628c6f6bf","https://git.kernel.org/stable/c/a6f89b10042baca218c8598d6db5a44c7e32625f","https://git.kernel.org/stable/c/b47f5c579c8186f7f5ab5e4254e0734ea5b7bf7a","https://git.kernel.org/stable/c/d464b035c0613856d012cf1704879d3ff3f057fb","https://git.kernel.org/stable/c/d706485dffbbbf848e681edda29c7a46ac55698c"],"published_time":"2025-10-04T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50479","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd: fix potential memory leak\n\nThis patch fix potential memory leak (clk_src) when function run\ninto last return NULL.\n\ns/free/kfree/ - Alex","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/6160216fd2c97107e8a9ab39863b056d677fcd85","https://git.kernel.org/stable/c/a6e6ab9caeac96b277a3fe7da1dfa8f69a591759"],"published_time":"2025-10-04T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50480","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmemory: pl353-smc: Fix refcount leak bug in pl353_smc_probe()\n\nThe break of for_each_available_child_of_node() needs a\ncorresponding of_node_put() when the reference 'child' is not\nused anymore. Here we do not need to call of_node_put() in\nfail path as '!match' means no break.\n\nWhile the of_platform_device_create() will created a new\nreference by 'child' but it has considered the refcounting.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/44db35ceb94756ba513dcf6b69bf9e949b28469c","https://git.kernel.org/stable/c/49605dc25e7fb33bf8b671279d4468531da90f89","https://git.kernel.org/stable/c/566b143aa5112a0c2784e20603778518bb799537","https://git.kernel.org/stable/c/61b3c876c1cbdb1efd1f52a1f348580e6e14efb6","https://git.kernel.org/stable/c/b37f4a711e5d4bf3608ccbc6de82b52e92b441a0","https://git.kernel.org/stable/c/fde46754d5483bc398018bbec3c8ef5c55219e67"],"published_time":"2025-10-04T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50481","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()\n\nIf device_register() fails in cxl_register_afu|adapter(), the device\nis not added, device_unregister() can not be called in the error path,\notherwise it will cause a null-ptr-deref because of removing not added\ndevice.\n\nAs comment of device_register() says, it should use put_device() to give\nup the reference in the error path. So split device_unregister() into\ndevice_del() and put_device(), then goes to put dev when register fails.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/170e8c2d2b61e15e7f7cfeded81bc1e959a15ed8","https://git.kernel.org/stable/c/1ae581696b7a799afa39a664c4b721569643f58a","https://git.kernel.org/stable/c/60b2ed21a65f3f5318666ccd765c3507991370cf","https://git.kernel.org/stable/c/61c80d1c3833e196256fb060382db94f24d3d9a7","https://git.kernel.org/stable/c/96fba6fb95bdede80583c262ac185da09661f264","https://git.kernel.org/stable/c/ab44c182353be101c3be9465e1d15d42130c53c4","https://git.kernel.org/stable/c/b32559ee4e6667c5c3daf4ec5454c277d1f255d2","https://git.kernel.org/stable/c/d775a1da5a52b4f4bb02f2707ba420d1bec48dbb","https://git.kernel.org/stable/c/e5021bbf11b024cc65ea1e84c377df484183be4b"],"published_time":"2025-10-04T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50482","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clean up si_domain in the init_dmars() error path\n\nA splat from kmem_cache_destroy() was seen with a kernel prior to\ncommit ee2653bbe89d (\"iommu/vt-d: Remove domain and devinfo mempool\")\nwhen there was a failure in init_dmars(), because the iommu_domain\ncache still had objects. While the mempool code is now gone, there\nstill is a leak of the si_domain memory if init_dmars() fails. So\nclean up si_domain in the init_dmars() error path.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0365d6af75f9f2696e94a0fef24a2c8464c037c8","https://git.kernel.org/stable/c/5cecfe151874b835331efe086bbdcaeaf64f6b90","https://git.kernel.org/stable/c/620bf9f981365c18cc2766c53d92bf8131c63f32","https://git.kernel.org/stable/c/724483b585a1b1e063d42ac5aa835707ff2ec165","https://git.kernel.org/stable/c/749bea542b67513e99240dc58bbfc099e842d508","https://git.kernel.org/stable/c/c4ad3ae4c6be9d8b0701761c839771116bca6ea3","https://git.kernel.org/stable/c/d74196bb278b8f8af88e16bd595997dfa3d6fdb0"],"published_time":"2025-10-04T16:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50471","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nxen/gntdev: Accommodate VMA splitting\n\nPrior to this commit, the gntdev driver code did not handle the\nfollowing scenario correctly with paravirtualized (PV) Xen domains:\n\n* User process sets up a gntdev mapping composed of two grant mappings\n  (i.e., two pages shared by another Xen domain).\n* User process munmap()s one of the pages.\n* User process munmap()s the remaining page.\n* User process exits.\n\nIn the scenario above, the user process would cause the kernel to log\nthe following messages in dmesg for the first munmap(), and the second\nmunmap() call would result in similar log messages:\n\n  BUG: Bad page map in process doublemap.test  pte:... pmd:...\n  page:0000000057c97bff refcount:1 mapcount:-1 \\\n    mapping:0000000000000000 index:0x0 pfn:...\n  ...\n  page dumped because: bad pte\n  ...\n  file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0\n  ...\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x46/0x5e\n   print_bad_pte.cold+0x66/0xb6\n   unmap_page_range+0x7e5/0xdc0\n   unmap_vmas+0x78/0xf0\n   unmap_region+0xa8/0x110\n   __do_munmap+0x1ea/0x4e0\n   __vm_munmap+0x75/0x120\n   __x64_sys_munmap+0x28/0x40\n   do_syscall_64+0x38/0x90\n   entry_SYSCALL_64_after_hwframe+0x61/0xcb\n   ...\n\nFor each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG)\nwould print out the following and trigger a general protection fault in\nthe affected Xen PV domain:\n\n  (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ...\n  (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ...\n\nAs of this writing, gntdev_grant_map structure's vma field (referred to\nas map->vma below) is mainly used for checking the start and end\naddresses of mappings. However, with split VMAs, these may change, and\nthere could be more than one VMA associated with a gntdev mapping.\nHence, remove the use of map->vma and rely on map->pages_vm_start for\nthe original start address and on (map->count << PAGE_SHIFT) for the\noriginal mapping size. Let the invalidate() and find_special_page()\nhooks use these.\n\nAlso, given that there can be multiple VMAs associated with a gntdev\nmapping, move the \"mmu_interval_notifier_remove(&map->notifier)\" call to\nthe end of gntdev_put_map, so that the MMU notifier is only removed\nafter the closing of the last remaining VMA.\n\nFinally, use an atomic to prevent inadvertent gntdev mapping re-use,\ninstead of using the map->live_grants atomic counter and/or the map->vma\npointer (the latter of which is now removed). This prevents the\nuserspace from mmap()'ing (with MAP_FIXED) a gntdev mapping over the\nsame address range as a previously set up gntdev mapping. This scenario\ncan be summarized with the following call-trace, which was valid prior\nto this commit:\n\n  mmap\n    gntdev_mmap\n  mmap (repeat mmap with MAP_FIXED over the same address range)\n    gntdev_invalidate\n      unmap_grant_pages (sets 'being_removed' entries to true)\n        gnttab_unmap_refs_async\n    unmap_single_vma\n    gntdev_mmap (maps the shared pages again)\n  munmap\n    gntdev_invalidate\n      unmap_grant_pages\n        (no-op because 'being_removed' entries are true)\n    unmap_single_vma (For PV domains, Xen reports that a granted page\n      is being unmapped and triggers a general protection fault in the\n      affected domain, if Xen was built with CONFIG_DEBUG)\n\nThe fix for this last scenario could be worth its own commit, but we\nopted for a single commit, because removing the gntdev_grant_map\nstructure's vma field requires guarding the entry to gntdev_mmap(), and\nthe live_grants atomic counter is not sufficient on its own to prevent\nthe mmap() over a pre-existing mapping.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3c6a888e352283a14f37b9b433cd598a1a3a7dd0","https://git.kernel.org/stable/c/4fb4053d90caa9985b87ec0e0c32c66a55bdfa3a","https://git.kernel.org/stable/c/5c13a4a0291b30191eff9ead8d010e1ca43a4d0c","https://git.kernel.org/stable/c/7c16d0a4e6a436b4e7c92bead3fab55aaa4c1141","https://git.kernel.org/stable/c/cdafa219ace013c594e2491158ad1b51f9923dde"],"published_time":"2025-10-04T16:15:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50472","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nIB/mad: Don't call to function that might sleep while in atomic context\n\nTracepoints are not allowed to sleep, as such the following splat is\ngenerated due to call to ib_query_pkey() in atomic context.\n\nWARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220\nCPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-305.3.1.el8.x86_64 #1\n Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014\n Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]\n RIP: 0010:rb_commit+0xc1/0x220\n RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202\n RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246\n RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246\n R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000\n FS:  0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0\n Call Trace:\n  ring_buffer_unlock_commit+0x1d/0xa0\n  trace_buffer_unlock_commit_regs+0x3b/0x1b0\n  trace_event_buffer_commit+0x67/0x1d0\n  trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core]\n  ib_mad_recv_done+0x48b/0xc10 [ib_core]\n  ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core]\n  __ib_process_cq+0x91/0x1c0 [ib_core]\n  ib_cq_poll_work+0x26/0x80 [ib_core]\n  process_one_work+0x1a7/0x360\n  ? create_worker+0x1a0/0x1a0\n  worker_thread+0x30/0x390\n  ? create_worker+0x1a0/0x1a0\n  kthread+0x116/0x130\n  ? kthread_flush_work_fn+0x10/0x10\n  ret_from_fork+0x35/0x40\n ---[ end trace 78ba8509d3830a16 ]---","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/47e31b86edff36f2d26cbc88ce695d98ff804178","https://git.kernel.org/stable/c/5c20311d76cbaeb7ed2ecf9c8b8322f8fc4a7ae3","https://git.kernel.org/stable/c/cea70a572c0cb9728d728cfebe7d5bd485e97513","https://git.kernel.org/stable/c/fa8a2f3be78e4585996bcf4c15e4504441a4c7a0"],"published_time":"2025-10-04T16:15:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50473","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: Init completion before kobject_init_and_add()\n\nIn cpufreq_policy_alloc(), it will call uninitialed completion in\ncpufreq_sysfs_release() when kobject_init_and_add() fails. And\nthat will cause a crash such as the following page fault in complete:\n\nBUG: unable to handle page fault for address: fffffffffffffff8\n[..]\nRIP: 0010:complete+0x98/0x1f0\n[..]\nCall Trace:\n kobject_put+0x1be/0x4c0\n cpufreq_online.cold+0xee/0x1fd\n cpufreq_add_dev+0x183/0x1e0\n subsys_interface_register+0x3f5/0x4e0\n cpufreq_register_driver+0x3b7/0x670\n acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq]\n do_one_initcall+0x13d/0x780\n do_init_module+0x1c3/0x630\n load_module+0x6e67/0x73b0\n __do_sys_finit_module+0x181/0x240\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3cdd91a9163248935720927531066b74f57aa43b","https://git.kernel.org/stable/c/5c51054896bcce1d33d39fead2af73fec24f40b6","https://git.kernel.org/stable/c/8fb4c98f20dfca1237de2e3dfdbe78d156784fd3","https://git.kernel.org/stable/c/d88540acfc7a17079021d866de914112c396edb1","https://git.kernel.org/stable/c/e379b88a8f8cffc99b318e028705ed9e3da0e1e0","https://git.kernel.org/stable/c/e7c0c943ed675b66d4bbb16c51c6a3bb58da047e"],"published_time":"2025-10-04T16:15:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50474","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmacintosh: fix possible memory leak in macio_add_one_device()\n\nAfer commit 1fa5ae857bb1 (\"driver core: get rid of struct device's\nbus_id string array\"), the name of device is allocated dynamically. It\nneeds to be freed when of_device_register() fails. Call put_device() to\ngive up the reference that's taken in device_initialize(), so that it\ncan be freed in kobject_cleanup() when the refcount hits 0.\n\nmacio device is freed in macio_release_dev(), so the kfree() can be\nremoved.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/19ded60b40e86b0903c8d5bd0161437ed5107a8b","https://git.kernel.org/stable/c/2ac0a7059b7bcbed35bfffa34a82c9a9e99638ef","https://git.kernel.org/stable/c/35858b87a943917fa30172aa4bf01ce7adbcb42c","https://git.kernel.org/stable/c/3a866ff6fc2232c8e393cdb55ffb8ce947349e03","https://git.kernel.org/stable/c/5ca86eae55a2f006e6c1edd2029b2cacb6979515","https://git.kernel.org/stable/c/76837e7f6b30da72ad59f56291e22804a219e015","https://git.kernel.org/stable/c/aa9054267366ff0a382d403d17728e21951ddbb9","https://git.kernel.org/stable/c/b29a2f1dd33ae9b94821ab2f4d398b9081786748","https://git.kernel.org/stable/c/ca765257feb89dacf604ced9cd233db5f865dee0"],"published_time":"2025-10-04T16:15:43","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2022-50470","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nxhci: Remove device endpoints from bandwidth list when freeing the device\n\nEndpoints are normally deleted from the bandwidth list when they are\ndropped, before the virt device is freed.\n\nIf xHC host is dying or being removed then the endpoints aren't dropped\ncleanly due to functions returning early to avoid interacting with a\nnon-accessible host controller.\n\nSo check and delete endpoints that are still on the bandwidth list when\nfreeing the virt device.\n\nSolves a list_del corruption kernel crash when unbinding xhci-pci,\ncaused by xhci_mem_cleanup() when it later tried to delete already freed\nendpoints from the bandwidth list.\n\nThis only affects hosts that use software bandwidth checking, which\ncurrenty is only the xHC in intel Panther Point PCH (Ivy Bridge)","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3bf860a41e0f2fcea0ac3aae8f7ef887a7994b70","https://git.kernel.org/stable/c/5aed5b7c2430ce318a8e62f752f181e66f0d1053","https://git.kernel.org/stable/c/5e4ce28ad907aa54f13b21d5f1dc490525957b0c","https://git.kernel.org/stable/c/678d2cc2041cc6ce05030852dce9ad42719abcfc","https://git.kernel.org/stable/c/8f1cd9633d1f21efc13e8fc75be8f2b6bb85e38c","https://git.kernel.org/stable/c/c892a81c7424b4f6a660cb9c249d354ccf3afeca","https://git.kernel.org/stable/c/cebbc8d335d6bcc1316584f779c08f80287c6af8","https://git.kernel.org/stable/c/f0de39474078adef6ece7a183e34c15ce2c1d8d1"],"published_time":"2025-10-04T16:15:42","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39949","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don't collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc'ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere \"ADDRESS\" is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware's return value to the maximum\nnumber of legal elements the firmware should return.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00021,"ranking_epss":0.05736,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/25672c620421fa2105703a94a29a03487245e6d6","https://git.kernel.org/stable/c/56c0a2a9ddc2f5b5078c5fb0f81ab76bbc3d4c37","https://git.kernel.org/stable/c/660b2a8f5a306a28c7efc1b4990ecc4912a68f87","https://git.kernel.org/stable/c/70affe82e38fd3dc76b9c68b5a1989f11e7fa0f3","https://git.kernel.org/stable/c/8141910869596b7a3a5d9b46107da2191d523f82","https://git.kernel.org/stable/c/e0e24571a7b2f8c8f06e25d3417253ebbdbc8d5c","https://git.kernel.org/stable/c/ea53e6a47e148b490b1c652fc65d2de5a086df76"],"published_time":"2025-10-04T08:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39950","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR\n\nA NULL pointer dereference can occur in tcp_ao_finish_connect() during a\nconnect() system call on a socket with a TCP-AO key added and TCP_REPAIR\nenabled.\n\nThe function is called with skb being NULL and attempts to dereference it\non tcp_hdr(skb)->seq without a prior skb validation.\n\nFix this by checking if skb is NULL before dereferencing it.\n\nThe commentary is taken from bpf_skops_established(), which is also called\nin the same flow. Unlike the function being patched,\nbpf_skops_established() validates the skb before dereferencing it.\n\nint main(void){\n\tstruct sockaddr_in sockaddr;\n\tstruct tcp_ao_add tcp_ao;\n\tint sk;\n\tint one = 1;\n\n\tmemset(&sockaddr,'\\0',sizeof(sockaddr));\n\tmemset(&tcp_ao,'\\0',sizeof(tcp_ao));\n\n\tsk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);\n\n\tsockaddr.sin_family = AF_INET;\n\n\tmemcpy(tcp_ao.alg_name,\"cmac(aes128)\",12);\n\tmemcpy(tcp_ao.key,\"ABCDEFGHABCDEFGH\",16);\n\ttcp_ao.keylen = 16;\n\n\tmemcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr));\n\n\tsetsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao,\n\tsizeof(tcp_ao));\n\tsetsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one));\n\n\tsockaddr.sin_family = AF_INET;\n\tsockaddr.sin_port = htobe16(123);\n\n\tinet_aton(\"127.0.0.1\", &sockaddr.sin_addr);\n\n\tconnect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr));\n\nreturn 0;\n}\n\n$ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall\n$ unshare -Urn\n\nBUG: kernel NULL pointer dereference, address: 00000000000000b6\nPGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop\nReference Platform, BIOS 6.00 11/12/2020\nRIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2e7bba08923ebc675b1f0e0e0959e68e53047838","https://git.kernel.org/stable/c/5f445eb259906b61a518487a790e11d07d31738c","https://git.kernel.org/stable/c/993b734d31ab804747ac961b1ee664b023c3b5fa"],"published_time":"2025-10-04T08:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39951","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\num: virtio_uml: Fix use-after-free after put_device in probe\n\nWhen register_virtio_device() fails in virtio_uml_probe(),\nthe code sets vu_dev->registered = 1 even though\nthe device was not successfully registered.\nThis can lead to use-after-free or other issues.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.02983,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/00e98b5a69034b251bb36dc6e7123d7648e218e4","https://git.kernel.org/stable/c/14c231959a16ca41bfdcaede72483362a8c645d7","https://git.kernel.org/stable/c/4f364023ddcfe83f7073b973a9cb98584b7f2a46","https://git.kernel.org/stable/c/5e94e44c9cb30d7a383d8ac227f24a8c9326b770","https://git.kernel.org/stable/c/7ebf70cf181651fe3f2e44e95e7e5073d594c9c0","https://git.kernel.org/stable/c/aaf900a83508c8cd5cdf765e7749f9076196ec7f","https://git.kernel.org/stable/c/c2ff91255e0157b356cff115d8dc3eeb5162edf2"],"published_time":"2025-10-04T08:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39952","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: avoid buffer overflow in WID string configuration\n\nFix the following copy overflow warning identified by Smatch checker.\n\n drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()\n        error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)\n\nThis patch introduces size check before accessing the memory buffer.\nThe checks are base on the WID type of received data from the firmware.\nFor WID string configuration, the size limit is determined by individual\nelement size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field\nof 'struct wilc_cfg_str'.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00016,"ranking_epss":0.03471,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2203ef417044b10a8563ade6a17c74183745d72e","https://git.kernel.org/stable/c/6085291a1a5865d4ad70f0e5812d524ebd5d1711","https://git.kernel.org/stable/c/ae50f8562306a7ea1cf3c9722f97ee244f974729","https://git.kernel.org/stable/c/fe9e4d0c39311d0f97b024147a0d155333f388b5"],"published_time":"2025-10-04T08:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39953","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0                            CPU1\nmount perf_event                umount net_prio\ncgroup1_get_tree                cgroup_kill_sb\nrebind_subsystems               // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n                                // one perf_event css A is dying\n                                // css A offline enqueues cgroup_destroy_wq\n                                // root destruction will be executed first\n                                css_free_rwork_fn\n                                cgroup_destroy_root\n                                cgroup_lock_and_drain_offline\n                                // some perf descendants are dying\n                                // cgroup_destroy_wq max_active = 1\n                                // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n   blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq – Handles CSS offline operations\ncgroup_release_wq – Manages resource release\ncgroup_free_wq – Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00026,"ranking_epss":0.07261,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/05e0b03447cf215ec384210441b34b7a3b16e8b0","https://git.kernel.org/stable/c/4a1e3ec28e8062cd9f339aa6a942df9c5bcb6811","https://git.kernel.org/stable/c/79f919a89c9d06816dbdbbd168fa41d27411a7f9","https://git.kernel.org/stable/c/993049c9b1355c78918344a6403427d53f9ee700","https://git.kernel.org/stable/c/a0c896bda7077aa5005473e2c5b3c27173313b4c","https://git.kernel.org/stable/c/cabadd7fd15f97090f752fd22dd7f876a0dc3dc4","https://git.kernel.org/stable/c/ded4d207a3209a834b6831ceec7f39b934c74802","https://git.kernel.org/stable/c/f2795d1b92506e3adf52a298f7181032a1525e04"],"published_time":"2025-10-04T08:15:48","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39941","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nzram: fix slot write race condition\n\nParallel concurrent writes to the same zram index result in leaked\nzsmalloc handles.  Schematically we can have something like this:\n\nCPU0                              CPU1\nzram_slot_lock()\nzs_free(handle)\nzram_slot_lock()\n\t\t\t\tzram_slot_lock()\n\t\t\t\tzs_free(handle)\n\t\t\t\tzram_slot_lock()\n\ncompress\t\t\tcompress\nhandle = zs_malloc()\t\thandle = zs_malloc()\nzram_slot_lock\nzram_set_handle(handle)\nzram_slot_lock\n\t\t\t\tzram_slot_lock\n\t\t\t\tzram_set_handle(handle)\n\t\t\t\tzram_slot_lock\n\nEither CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done\ntoo early.  In fact, we need to reset zram entry right before we set its\nnew handle, all under the same slot lock scope.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00011,"ranking_epss":0.01281,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/ce4be9e4307c5a60701ff6e0cafa74caffdc54ce","https://git.kernel.org/stable/c/ff750e9f2c4d63854c33967d1646b5e89a9a19a2"],"published_time":"2025-10-04T08:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39942","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00021,"ranking_epss":0.05711,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/196a3a7676d726ee67621ea2bf3b7815ac2685b4","https://git.kernel.org/stable/c/9644798294c7287e65a7b26e35aa6d2ce3345bcc","https://git.kernel.org/stable/c/c64b915bb3d9339adcae5db4be2c35ffbef5e615","https://git.kernel.org/stable/c/d3cb3f209d35c44b7ee74f77ed27ebb28995b9ce","https://git.kernel.org/stable/c/e1868ba37fd27c6a68e31565402b154beaa65df0"],"published_time":"2025-10-04T08:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39943","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: validate data_offset and data_length field of smb_direct_data_transfer\n\nIf data_offset and data_length of smb_direct_data_transfer struct are\ninvalid, out of bounds issue could happen.\nThis patch validate data_offset and data_length field in recv_done.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.02983,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5282491fc49d5614ac6ddcd012e5743eecb6a67c","https://git.kernel.org/stable/c/529b121b00a6ee3c88fb3c01b443b2b81f686d48","https://git.kernel.org/stable/c/773fddf976d282ef059c36c575ddb81567acd6bc","https://git.kernel.org/stable/c/8be498fcbd5b07272f560b45981d4b9e5a2ad885","https://git.kernel.org/stable/c/bdaab5c6538e250a9654127e688ecbbeb6f771d5","https://git.kernel.org/stable/c/eb0378dde086363046ed3d7db7f126fc3f76fd70"],"published_time":"2025-10-04T08:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39944","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()\n\nThe original code relies on cancel_delayed_work() in otx2_ptp_destroy(),\nwhich does not ensure that the delayed work item synctstamp_work has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work\nremains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().\nFurthermore, the synctstamp_work is cyclic, the likelihood of triggering\nthe bug is nonnegligible.\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup)           | CPU 1 (delayed work callback)\notx2_remove()             |\n  otx2_ptp_destroy()      | otx2_sync_tstamp()\n    cancel_delayed_work() |\n    kfree(ptp)            |\n                          |   ptp = container_of(...); //UAF\n                          |   ptp-> //UAF\n\nThis is confirmed by a KASAN report:\n\nBUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0\nWrite of size 8 at addr ffff88800aa09a18 by task bash/136\n...\nCall Trace:\n <IRQ>\n dump_stack_lvl+0x55/0x70\n print_report+0xcf/0x610\n ? __run_timer_base.part.0+0x7d7/0x8c0\n kasan_report+0xb8/0xf0\n ? __run_timer_base.part.0+0x7d7/0x8c0\n __run_timer_base.part.0+0x7d7/0x8c0\n ? __pfx___run_timer_base.part.0+0x10/0x10\n ? __pfx_read_tsc+0x10/0x10\n ? ktime_get+0x60/0x140\n ? lapic_next_event+0x11/0x20\n ? clockevents_program_event+0x1d4/0x2a0\n run_timer_softirq+0xd1/0x190\n handle_softirqs+0x16a/0x550\n irq_exit_rcu+0xaf/0xe0\n sysvec_apic_timer_interrupt+0x70/0x80\n </IRQ>\n...\nAllocated by task 1:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n otx2_ptp_init+0xb1/0x860\n otx2_probe+0x4eb/0xc30\n local_pci_probe+0xdc/0x190\n pci_device_probe+0x2fe/0x470\n really_probe+0x1ca/0x5c0\n __driver_probe_device+0x248/0x310\n driver_probe_device+0x44/0x120\n __driver_attach+0xd2/0x310\n bus_for_each_dev+0xed/0x170\n bus_add_driver+0x208/0x500\n driver_register+0x132/0x460\n do_one_initcall+0x89/0x300\n kernel_init_freeable+0x40d/0x720\n kernel_init+0x1a/0x150\n ret_from_fork+0x10c/0x1a0\n ret_from_fork_asm+0x1a/0x30\n\nFreed by task 136:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3a/0x60\n __kasan_slab_free+0x3f/0x50\n kfree+0x137/0x370\n otx2_ptp_destroy+0x38/0x80\n otx2_remove+0x10d/0x4c0\n pci_device_remove+0xa6/0x1d0\n device_release_driver_internal+0xf8/0x210\n pci_stop_bus_device+0x105/0x150\n pci_stop_and_remove_bus_device_locked+0x15/0x30\n remove_store+0xcc/0xe0\n kernfs_fop_write_iter+0x2c3/0x440\n vfs_write+0x871/0xd70\n ksys_write+0xee/0x1c0\n do_syscall_64+0xac/0x280\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the delayed work item is properly canceled before the otx2_ptp is\ndeallocated.\n\nThis bug was initially identified through static analysis. To reproduce\nand test it, I simulated the OcteonTX2 PCI device in QEMU and introduced\nartificial delays within the otx2_sync_tstamp() function to increase the\nlikelihood of triggering the bug.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.02966,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2786879aebf363806a13d41e8d5f99202ddd23d9","https://git.kernel.org/stable/c/5ca20bb7b4bde72110c3ae78423cbfdd0157aa36","https://git.kernel.org/stable/c/d2cfefa14ce8137b17f99683f968bebf134b6a48","https://git.kernel.org/stable/c/f8b4687151021db61841af983f1cb7be6915d4ef","https://git.kernel.org/stable/c/ff27e23b311fed4d25e3852e27ba693416d4c7b3"],"published_time":"2025-10-04T08:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39945","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item 'delete_task' has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup)              | CPU 1 (delayed work callback)\ncnic_netdev_event()          |\n  cnic_stop_hw()             | cnic_delete_task()\n    cnic_cm_stop_bnx2x_hw()  | ...\n      cancel_delayed_work()  | /* the queue_delayed_work()\n      flush_workqueue()      |    executes after flush_workqueue()*/\n                             | queue_delayed_work()\n  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance\n                             |   dev = cp->dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays — such as inserting calls to ssleep()\nwithin the cnic_delete_task() function — to increase the likelihood\nof triggering the bug.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00025,"ranking_epss":0.06881,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0405055930264ea8fd26f4131466fa7652e5e47d","https://git.kernel.org/stable/c/0627e1481676669cae2df0d85b5ff13e7d24c390","https://git.kernel.org/stable/c/6e33a7eed587062ca8161ad1f4584882a860d697","https://git.kernel.org/stable/c/7b6a5b0a6b392263c3767fc945b311ea04b34bbd","https://git.kernel.org/stable/c/8eeb2091e72d75df8ceaa2172638d61b4cf8929a","https://git.kernel.org/stable/c/cfa7d9b1e3a8604afc84e9e51d789c29574fb216","https://git.kernel.org/stable/c/e1fcd4a9c09feac0902a65615e866dbf22616125","https://git.kernel.org/stable/c/fde6e73189f40ebcf0633aed2b68e731c25f3aa3"],"published_time":"2025-10-04T08:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39946","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntls: make sure to abort the stream if headers are bogus\n\nNormally we wait for the socket to buffer up the whole record\nbefore we service it. If the socket has a tiny buffer, however,\nwe read out the data sooner, to prevent connection stalls.\nMake sure that we abort the connection when we find out late\nthat the record is actually invalid. Retrying the parsing is\nfine in itself but since we copy some more data each time\nbefore we parse we can overflow the allocated skb space.\n\nConstructing a scenario in which we're under pressure without\nenough data in the socket to parse the length upfront is quite\nhard. syzbot figured out a way to do this by serving us the header\nin small OOB sends, and then filling in the recvbuf with a large\nnormal send.\n\nMake sure that tls_rx_msg_size() aborts strp, if we reach\nan invalid record there's really no way to recover.","cvss":9.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":9.8,"epss":0.00019,"ranking_epss":0.05009,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0aeb54ac4cd5cf8f60131b4d9ec0b6dc9c27b20d","https://git.kernel.org/stable/c/208640e6225cc929a05adbf79d1df558add3e231","https://git.kernel.org/stable/c/4cefe5be73886f383639fe0850bb72d5b568a7b9","https://git.kernel.org/stable/c/61ca2da5fb8f433ce8bbd1657c84a86272133e6b","https://git.kernel.org/stable/c/b36462146d86b1f22e594fe4dae611dffacfb203"],"published_time":"2025-10-04T08:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39947","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Harden uplink netdev access against device unbind\n\nThe function mlx5_uplink_netdev_get() gets the uplink netdevice\npointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can\nbe removed and its pointer cleared when unbound from the mlx5_core.eth\ndriver. This results in a NULL pointer, causing a kernel panic.\n\n BUG: unable to handle page fault for address: 0000000000001300\n at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]\n Call Trace:\n  <TASK>\n  mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]\n  esw_offloads_enable+0x593/0x910 [mlx5_core]\n  mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]\n  mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]\n  devlink_nl_eswitch_set_doit+0x60/0xd0\n  genl_family_rcv_msg_doit+0xe0/0x130\n  genl_rcv_msg+0x183/0x290\n  netlink_rcv_skb+0x4b/0xf0\n  genl_rcv+0x24/0x40\n  netlink_unicast+0x255/0x380\n  netlink_sendmsg+0x1f3/0x420\n  __sock_sendmsg+0x38/0x60\n  __sys_sendto+0x119/0x180\n  do_syscall_64+0x53/0x1d0\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nEnsure the pointer is valid before use by checking it for NULL. If it\nis valid, immediately call netdev_hold() to take a reference, and\npreventing the netdevice from being freed while it is in use.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2cb17c88edd3a1c7aa6bc880dcdb35a6866fcb2e","https://git.kernel.org/stable/c/6b4be64fd9fec16418f365c2d8e47a7566e9eba5","https://git.kernel.org/stable/c/8df354eb2dd63d111ed5ae2e956e0dbb22bcf93b","https://git.kernel.org/stable/c/d1f3db4e7a3be29fc17f01850f162363f919370d"],"published_time":"2025-10-04T08:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39948","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix Rx page leak on multi-buffer frames\n\nThe ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each\nbuffer in the current frame. This function was introduced as part of\nhandling multi-buffer XDP support in the ice driver.\n\nIt works by iterating over the buffers from first_desc up to 1 plus the\ntotal number of fragments in the frame, cached from before the XDP program\nwas executed.\n\nIf the hardware posts a descriptor with a size of 0, the logic used in\nice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added\nas fragments in ice_add_xdp_frag. Since the buffer isn't counted as a\nfragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't\ncall ice_put_rx_buf().\n\nBecause we don't call ice_put_rx_buf(), we don't attempt to re-use the\npage or free it. This leaves a stale page in the ring, as we don't\nincrement next_to_alloc.\n\nThe ice_reuse_rx_page() assumes that the next_to_alloc has been incremented\nproperly, and that it always points to a buffer with a NULL page. Since\nthis function doesn't check, it will happily recycle a page over the top\nof the next_to_alloc buffer, losing track of the old page.\n\nNote that this leak only occurs for multi-buffer frames. The\nice_put_rx_mbuf() function always handles at least one buffer, so a\nsingle-buffer frame will always get handled correctly. It is not clear\nprecisely why the hardware hands us descriptors with a size of 0 sometimes,\nbut it happens somewhat regularly with \"jumbo frames\" used by 9K MTU.\n\nTo fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on\nall buffers between first_desc and next_to_clean. Borrow the logic of a\nsimilar function in i40e used for this same purpose. Use the same logic\nalso in ice_get_pgcnts().\n\nInstead of iterating over just the number of fragments, use a loop which\niterates until the current index reaches to the next_to_clean element just\npast the current frame. Unlike i40e, the ice_put_rx_mbuf() function does\ncall ice_put_rx_buf() on the last buffer of the frame indicating the end of\npacket.\n\nFor non-linear (multi-buffer) frames, we need to take care when adjusting\nthe pagecnt_bias. An XDP program might release fragments from the tail of\nthe frame, in which case that fragment page is already released. Only\nupdate the pagecnt_bias for the first descriptor and fragments still\nremaining post-XDP program. Take care to only access the shared info for\nfragmented buffers, as this avoids a significant cache miss.\n\nThe xdp_xmit value only needs to be updated if an XDP program is run, and\nonly once per packet. Drop the xdp_xmit pointer argument from\nice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function\ndirectly. This avoids needing to pass the argument and avoids an extra\nbit-wise OR for each buffer in the frame.\n\nMove the increment of the ntc local variable to ensure its updated *before*\nall calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic\nrequires the index of the element just after the current frame.\n\nNow that we use an index pointer in the ring to identify the packet, we no\nlonger need to track or cache the number of fragments in the rx_ring.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01714,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/80555adb5c892f0e21d243ae96ed997ee520aea9","https://git.kernel.org/stable/c/84bf1ac85af84d354c7a2fdbdc0d4efc8aaec34b","https://git.kernel.org/stable/c/fcb5718ebfe7fd64144e3399280440cce361a3ae"],"published_time":"2025-10-04T08:15:47","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39933","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let recv_done verify data_offset, data_length and remaining_data_length\n\nThis is inspired by the related server fixes.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/581fb78e0388b78911b0c920e4073737090c8b5f","https://git.kernel.org/stable/c/f57e53ea252363234f86674db475839e5b87102e"],"published_time":"2025-10-04T08:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39934","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: bridge: anx7625: Fix NULL pointer dereference with early IRQ\n\nIf the interrupt occurs before resource initialization is complete, the\ninterrupt handler/worker may access uninitialized data such as the I2C\ntcpc_client device, potentially leading to NULL pointer dereference.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00021,"ranking_epss":0.05736,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0da73f7827691a5e2265b110d5fe12f29535ec92","https://git.kernel.org/stable/c/15a77e1ab0a994d69b471c76b8d01117128dda26","https://git.kernel.org/stable/c/1a7ea294d57fb61485d11b3f2241d631d73025cb","https://git.kernel.org/stable/c/51a501e990a353a4f15da6bab295b28e5d118f64","https://git.kernel.org/stable/c/a10f910c77f280327b481e77eab909934ec508f0","https://git.kernel.org/stable/c/f9a089d0a6d537d0f2061c8a37a7de535ce0310e"],"published_time":"2025-10-04T08:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39935","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: codec: sma1307: Fix memory corruption in sma1307_setting_loaded()\n\nThe sma1307->set.header_size is how many integers are in the header\n(there are 8 of them) but instead of allocating space of 8 integers\nwe allocate 8 bytes.  This leads to memory corruption when we copy data\nit on the next line:\n\n        memcpy(sma1307->set.header, data,\n               sma1307->set.header_size * sizeof(int));\n\nAlso since we're immediately copying over the memory in ->set.header,\nthere is no need to zero it in the allocator.  Use devm_kmalloc_array()\nto allocate the memory instead.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00022,"ranking_epss":0.05811,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/78338108b5a856dc98223a335f147846a8a18c51","https://git.kernel.org/stable/c/cd59ca8f75dbb42a67fcae975c766114644e36c4"],"published_time":"2025-10-04T08:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39936","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()\n\nWhen\n\n  9770b428b1a2 (\"crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown\")\n\nmoved the error messages dumping so that they don't need to be issued by\nthe callers, it missed the case where __sev_firmware_shutdown() calls\n__sev_platform_shutdown_locked() with a NULL argument which leads to\na NULL ptr deref on the shutdown path, during suspend to disk:\n\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: Oops: 0000 [#1] SMP NOPTI\n  CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary)\n  Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022\n  RIP: 0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp]\n\nThat rIP is:\n\n  00000000000006fd <__sev_platform_shutdown_locked.cold>:\n   6fd:   8b 13                   mov    (%rbx),%edx\n   6ff:   48 8b 7d 00             mov    0x0(%rbp),%rdi\n   703:   89 c1                   mov    %eax,%ecx\n\n  Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e\n  RSP: 0018:ffffc90005467d00 EFLAGS: 00010282\n  RAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000\n  \t\t\t     ^^^^^^^^^^^^^^^^\nand %rbx is nice and clean.\n\n  Call Trace:\n   <TASK>\n   __sev_firmware_shutdown.isra.0\n   sev_dev_destroy\n   psp_dev_destroy\n   sp_destroy\n   pci_device_shutdown\n   device_shutdown\n   kernel_power_off\n   hibernate.cold\n   state_store\n   kernfs_fop_write_iter\n   vfs_write\n   ksys_write\n   do_syscall_64\n   entry_SYSCALL_64_after_hwframe\n\nPass in a pointer to the function-local error var in the caller.\n\nWith that addressed, suspending the ccp shows the error properly at\nleast:\n\n  ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP\n  ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110\n  SEV-SNP: Leaking PFN range 0x146800-0x146a00\n  SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00]\n  ...\n  ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0\n  ACPI: PM: Preparing to enter system sleep state S5\n  kvm: exiting hardware virtualization\n  reboot: Power down\n\nBtw, this driver is crying to be cleaned up to pass in a proper I/O\nstruct which can be used to store information between the different\nfunctions, otherwise stuff like that will happen in the future again.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/46834d90a9a13549264b9581067d8f746b4b36cc","https://git.kernel.org/stable/c/bc509293c9d4f4f74e776f4a0bbb61f63c041938"],"published_time":"2025-10-04T08:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39937","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer\n\nSince commit 7d5e9737efda (\"net: rfkill: gpio: get the name and type from\ndevice property\") rfkill_find_type() gets called with the possibly\nuninitialized \"const char *type_name;\" local variable.\n\nOn x86 systems when rfkill-gpio binds to a \"BCM4752\" or \"LNV4752\"\nacpi_device, the rfkill->type is set based on the ACPI acpi_device_id:\n\n        rfkill->type = (unsigned)id->driver_data;\n\nand there is no \"type\" property so device_property_read_string() will fail\nand leave type_name uninitialized, leading to a potential crash.\n\nrfkill_find_type() does accept a NULL pointer, fix the potential crash\nby initializing type_name to NULL.\n\nNote likely sofar this has not been caught because:\n\n1. Not many x86 machines actually have a \"BCM4752\"/\"LNV4752\" acpi_device\n2. The stack happened to contain NULL where type_name is stored","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00026,"ranking_epss":0.07261,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/184f608a68f96794e8fe58cd5535014d53622cde","https://git.kernel.org/stable/c/21a39b958b4bcf44f7674bfbbe1bbb8cad0d842d","https://git.kernel.org/stable/c/21ba85d9d508422ca9e6698463ff9357c928c22d","https://git.kernel.org/stable/c/47ade5f9d70b23a119ec20b1c6504864b2543a79","https://git.kernel.org/stable/c/689aee35ce671aab752f159e5c8e66d7685e6887","https://git.kernel.org/stable/c/8793e7a8e1b60131a825457174ed6398111daeb7","https://git.kernel.org/stable/c/ada2282259243387e6b6e89239aeb4897e62f051","https://git.kernel.org/stable/c/b6f56a44e4c1014b08859dcf04ed246500e310e5"],"published_time":"2025-10-04T08:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39938","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed\n\nIf earlier opening of source graph fails (e.g. ADSP rejects due to\nincorrect audioreach topology), the graph is closed and\n\"dai_data->graph[dai->id]\" is assigned NULL.  Preparing the DAI for sink\ngraph continues though and next call to q6apm_lpass_dai_prepare()\nreceives dai_data->graph[dai->id]=NULL leading to NULL pointer\nexception:\n\n  qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd\n  qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1\n  q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78\n  q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22\n  Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8\n  ...\n  Call trace:\n   q6apm_graph_media_format_pcm+0x48/0x120 (P)\n   q6apm_lpass_dai_prepare+0x110/0x1b4\n   snd_soc_pcm_dai_prepare+0x74/0x108\n   __soc_pcm_prepare+0x44/0x160\n   dpcm_be_dai_prepare+0x124/0x1c0","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00021,"ranking_epss":0.05711,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/01d1ba106c9e02a2e7d41e07be49031a0ff0ecaa","https://git.kernel.org/stable/c/411f7d4f7038200cdf6d4f71ee31026ebf2dfedb","https://git.kernel.org/stable/c/68f27f7c7708183e7873c585ded2f1b057ac5b97","https://git.kernel.org/stable/c/9c534dbfd1726502abcf0bd393a04214f62c050b","https://git.kernel.org/stable/c/cc336b242ea7e7a09b3ab9f885341455ca0a3bdb"],"published_time":"2025-10-04T08:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39939","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\niommu/s390: Fix memory corruption when using identity domain\n\nzpci_get_iommu_ctrs() returns counter information to be reported as part\nof device statistics; these counters are stored as part of the s390_domain.\nThe problem, however, is that the identity domain is not backed by an\ns390_domain and so the conversion via to_s390_domain() yields a bad address\nthat is zero'd initially and read on-demand later via a sysfs read.\nThese counters aren't necessary for the identity domain; just return NULL\nin this case.\n\nThis issue was discovered via KASAN with reports that look like:\nBUG: KASAN: global-out-of-bounds in zpci_fmb_enable_device\nwhen using the identity domain for a device on s390.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00022,"ranking_epss":0.05811,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/17a58caf3863163c4a84a218a9649be2c8061443","https://git.kernel.org/stable/c/b3506e9bcc777ed6af2ab631c86a9990ed97b474"],"published_time":"2025-10-04T08:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39940","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ndm-stripe: fix a possible integer overflow\n\nThere's a possible integer overflow in stripe_io_hints if we have too\nlarge chunk size. Test if the overflow happened, and if it did, don't set\nlimits->io_min and limits->io_opt;","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1071d560afb4c245c2076494226df47db5a35708","https://git.kernel.org/stable/c/ee27658c239b27721397f3e4eb16370b5cce596e","https://git.kernel.org/stable/c/f8f64254bca5ae58f3b679441962bda4c409f659"],"published_time":"2025-10-04T08:15:46","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39931","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Set merge to zero early in af_alg_sendmsg\n\nIf an error causes af_alg_sendmsg to abort, ctx->merge may contain\na garbage value from the previous loop.  This may then trigger a\ncrash on the next entry into af_alg_sendmsg when it attempts to do\na merge that can't be done.\n\nFix this by setting ctx->merge to zero near the start of the loop.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00021,"ranking_epss":0.05711,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/045ee26aa3920a47ec46d7fcb302420bf01fd753","https://git.kernel.org/stable/c/2374c11189ef704a3e4863646369f1b8e6a27d71","https://git.kernel.org/stable/c/24c1106504c625fabd3b7229611af617b4c27ac7","https://git.kernel.org/stable/c/6241b9e2809b12da9130894cf5beddf088dc1b8a","https://git.kernel.org/stable/c/9574b2330dbd2b5459b74d3b5e9619d39299fc6f"],"published_time":"2025-10-04T08:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39932","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)\n\nIn smbd_destroy() we may destroy the memory so we better\nwait until post_send_credits_work is no longer pending\nand will never be started again.\n\nI actually just hit the case using rxe:\n\nWARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]\n...\n[ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs]\n[ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs]\n[ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60\n[ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs]\n[ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs]\n[ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]\n[ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10\n[ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0\n[ 5305.687889] [    T138]  process_one_work+0x629/0xf80\n[ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687933] [    T138]  worker_thread+0x87f/0x1570\n...\n\nIt means rxe_post_recv was called after rdma_destroy_qp().\nThis happened because put_receive_buffer() was triggered\nby ib_drain_qp() and called:\nqueue_work(info->workqueue, &info->post_send_credits_work);","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3fabb1236f2e3ad78d531be0a4ad9f4a4ccdda87","https://git.kernel.org/stable/c/6ae90a2baf923e85eb037b636aa641250bf4220f","https://git.kernel.org/stable/c/d9dcbbcf9145b68aa85c40947311a6907277e097"],"published_time":"2025-10-04T08:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-39929","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path\n\nDuring tests of another unrelated patch I was able to trigger this\nerror: Objects remaining on __kmem_cache_shutdown()","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00021,"ranking_epss":0.05711,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0991418bf98f191d0c320bd25245fcffa1998c7e","https://git.kernel.org/stable/c/3d7c075c878ac844e33c43e506c2fa27ac7e9689","https://git.kernel.org/stable/c/922338efaad63cfe30d459dfc59f9d69ff93ded4","https://git.kernel.org/stable/c/daac51c7032036a0ca5f1aa419ad1b0471d1c6e0","https://git.kernel.org/stable/c/e7b7a93879558e77d950f1ff9a6f3daa385b33df"],"published_time":"2025-10-04T08:15:44","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-59489","summary":"Unity Runtime before 2025-10-02 on Android, Windows, macOS, and Linux allows argument injection that can result in loading of library code from an unintended location. If an application was built with a version of Unity Editor that had the vulnerable Unity Runtime code, then an adversary may be able to execute code on, and exfiltrate confidential information from, the machine on which that application is running. NOTE: product status is provided for Unity Editor because that is the information available from the Supplier. However, updating Unity Editor typically does not address the effects of the vulnerability; instead, it is necessary to rebuild and redeploy all affected applications.","cvss":7.4,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.4,"epss":0.00015,"ranking_epss":0.02982,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://flatt.tech/research/posts/arbitrary-code-execution-in-unity-runtime/","https://unity.com/security#security-updates-and-patches","https://unity.com/security/sept-2025-01"],"published_time":"2025-10-03T14:15:45","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-54293","summary":"Path Traversal in the log file retrieval function in Canonical LXD 5.0 LTS on Linux allows authenticated remote attackers to read arbitrary files on the host system via crafted log file names or symbolic links.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00065,"ranking_epss":0.20409,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/canonical/lxd/security/advisories/GHSA-472f-vmf2-pr3h","https://github.com/canonical/lxd/security/advisories/GHSA-472f-vmf2-pr3h"],"published_time":"2025-10-02T11:15:30","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-54290","summary":"Information disclosure in image export API in Canonical LXD before 6.5 and 5.21.4 on Linux allows network attackers to determine project existence without authentication via crafted requests using wildcard fingerprints.","cvss":5.3,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.3,"epss":0.00091,"ranking_epss":0.25848,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/canonical/lxd/security/advisories/GHSA-p3x5-mvmp-5f35"],"published_time":"2025-10-02T10:15:39","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-54286","summary":"Cross-Site Request Forgery (CSRF) in LXD-UI in Canonical LXD versions >= 5.0 on Linux allows an attacker to create and start container instances without user consent via crafted HTML form submissions exploiting client certificate authentication.","cvss":8.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":8.8,"epss":0.00024,"ranking_epss":0.06363,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/canonical/lxd/security/advisories/GHSA-p8hw-rfjg-689h","https://github.com/canonical/lxd/security/advisories/GHSA-p8hw-rfjg-689h"],"published_time":"2025-10-02T10:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-54287","summary":"Template Injection in instance snapshot creation component in Canonical LXD (>= 4.0) allows an attacker with instance configuration \npermissions to read arbitrary files on the host system via specially crafted snapshot pattern templates using the Pongo2 template engine.","cvss":6.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.5,"epss":0.00062,"ranking_epss":0.19587,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/canonical/lxd/security/advisories/GHSA-w2hg-2v4p-vmh6","https://github.com/canonical/lxd/security/advisories/GHSA-w2hg-2v4p-vmh6"],"published_time":"2025-10-02T10:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2025-54288","summary":"Information Spoofing in devLXD Server in Canonical LXD versions 4.0 and above on Linux container platforms allows attackers with root privileges within any container to impersonate other containers and obtain their metadata, configuration, and device information via spoofed process names in the command line.","cvss":6.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":6.8,"epss":0.00055,"ranking_epss":0.1745,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://github.com/canonical/lxd/security/advisories/GHSA-7232-97c6-j525","https://github.com/canonical/lxd/security/advisories/GHSA-7232-97c6-j525"],"published_time":"2025-10-02T10:15:38","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53525","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Allow UD qp_type to join multicast only\n\nAs for multicast:\n- The SIDR is the only mode that makes sense;\n- Besides PS_UDP, other port spaces like PS_IB is also allowed, as it is\n  UD compatible. In this case qkey also needs to be set [1].\n\nThis patch allows only UD qp_type to join multicast, and set qkey to\ndefault if it's not set, to fix an uninit-value error: the ib->rec.qkey\nfield is accessed without being initialized.\n\n=====================================================\nBUG: KMSAN: uninit-value in cma_set_qkey drivers/infiniband/core/cma.c:510 [inline]\nBUG: KMSAN: uninit-value in cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570\n cma_set_qkey drivers/infiniband/core/cma.c:510 [inline]\n cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570\n cma_iboe_join_multicast drivers/infiniband/core/cma.c:4782 [inline]\n rdma_join_multicast+0x2b83/0x30a0 drivers/infiniband/core/cma.c:4814\n ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479\n ucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:1546\n ucma_write+0x639/0x6d0 drivers/infiniband/core/ucma.c:1732\n vfs_write+0x8ce/0x2030 fs/read_write.c:588\n ksys_write+0x28c/0x520 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __ia32_sys_write+0xdb/0x120 fs/read_write.c:652\n do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline]\n __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180\n do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205\n do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248\n entry_SYSENTER_compat_after_hwframe+0x4d/0x5c\n\nLocal variable ib.i created at:\ncma_iboe_join_multicast drivers/infiniband/core/cma.c:4737 [inline]\nrdma_join_multicast+0x586/0x30a0 drivers/infiniband/core/cma.c:4814\nucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479\n\nCPU: 0 PID: 29874 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n=====================================================\n\n[1] https://lore.kernel.org/linux-rdma/20220117183832.GD84788@nvidia.com/","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/02eabb635bc64bd1e3a7cf887d6d182bffb64b99","https://git.kernel.org/stable/c/48e8e7851dc0b1584d83817a78fc7108c8904b54","https://git.kernel.org/stable/c/58e84f6b3e84e46524b7e5a916b53c1ad798bc8f","https://git.kernel.org/stable/c/ae11498851423d6de27aebfe12a5ee85060ab1d5","https://git.kernel.org/stable/c/bb18b9dbac2bbdf7695e0bfaac4bf944ff7b207d"],"published_time":"2025-10-01T12:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53526","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: check 'jh->b_transaction' before removing it from checkpoint\n\nFollowing process will corrupt ext4 image:\nStep 1:\njbd2_journal_commit_transaction\n __jbd2_journal_insert_checkpoint(jh, commit_transaction)\n // Put jh into trans1->t_checkpoint_list\n journal->j_checkpoint_transactions = commit_transaction\n // Put trans1 into journal->j_checkpoint_transactions\n\nStep 2:\ndo_get_write_access\n test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty\n __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2\n\nStep 3:\ndrop_cache\n journal_shrink_one_cp_list\n  jbd2_journal_try_remove_checkpoint\n   if (!trylock_buffer(bh))  // lock bh, true\n   if (buffer_dirty(bh))     // buffer is not dirty\n   __jbd2_journal_remove_checkpoint(jh)\n   // remove jh from trans1->t_checkpoint_list\n\nStep 4:\njbd2_log_do_checkpoint\n trans1 = journal->j_checkpoint_transactions\n // jh is not in trans1->t_checkpoint_list\n jbd2_cleanup_journal_tail(journal)  // trans1 is done\n\nStep 5: Power cut, trans2 is not committed, jh is lost in next mounting.\n\nFix it by checking 'jh->b_transaction' before remove it from checkpoint.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2298f2589903a8bc03061b54b31fd97985ab6529","https://git.kernel.org/stable/c/590a809ff743e7bd890ba5fb36bc38e20a36de53","https://git.kernel.org/stable/c/dbafe636db415299e54d9dfefc1003bda9e71c9d","https://git.kernel.org/stable/c/ef5fea70e5915afd64182d155e72bfb4f275e1fc"],"published_time":"2025-10-01T12:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53527","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()\n\nThe memory allocated in tb_queue_dp_bandwidth_request() needs to be\nreleased once the request is handled to avoid leaking it.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0752bb32aed2c5dd85821195a507a1079c4835f7","https://git.kernel.org/stable/c/596a5123cc782d458b057eb3837e66535cd0befa"],"published_time":"2025-10-01T12:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53528","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix unsafe drain work queue code\n\nIf create_qp does not fully succeed it is possible for qp cleanup\ncode to attempt to drain the send or recv work queues before the\nqueues have been created causing a seg fault. This patch checks\nto see if the queues exist before attempting to drain them.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5993b75d0bc71cd2b441d174b028fc36180f032c","https://git.kernel.org/stable/c/d366642b3099bd322375f5b71ba84ab1d586cd6d","https://git.kernel.org/stable/c/da572f6313aeead1f79e0810666bd8d8ffc794d4"],"published_time":"2025-10-01T12:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53529","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: Fix memory leak in rtw88_usb\n\nKmemleak shows the following leak arising from routine in the usb\nprobe routine:\n\nunreferenced object 0xffff895cb29bba00 (size 512):\n  comm \"(udev-worker)\", pid 534, jiffies 4294903932 (age 102751.088s)\n  hex dump (first 32 bytes):\n    77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00  w000...../-+0...\n    02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00  ..*(.....U......\n  backtrace:\n    [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90\n    [<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb]\n    [<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore]\n    [<ffffffff92b4f2fe>] really_probe+0x18e/0x3d0\n    [<ffffffff92b4f5b8>] __driver_probe_device+0x78/0x160\n    [<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90\n    [<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0\n    [<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0\n    [<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210\n    [<ffffffff92b50935>] driver_register+0x55/0xf0\n    [<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore]\n    [<ffffffff92401153>] do_one_initcall+0x43/0x210\n    [<ffffffff9254f42a>] do_init_module+0x4a/0x200\n    [<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120\n    [<ffffffff92ee6626>] do_syscall_64+0x56/0x80\n    [<ffffffff9300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe leak was verified to be real by unloading the driver, which resulted\nin a dangling pointer to the allocation.\n\nThe allocated memory is freed in rtw_usb_intf_deinit().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/59a3a312009723e3e5082899655fdcc420e2b47a","https://git.kernel.org/stable/c/5bba1ad561a8b5bb14704d8f511cf10466336e3d"],"published_time":"2025-10-01T12:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53530","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()\n\nThe following call trace was observed:\n\nlocalhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete\nlocalhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092\nlocalhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN \"nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291\"\nlocalhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]\nlocalhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G    B   W  OE    --------- ---  5.14.0-70.22.1.el9_0.x86_64+debug #1\nlocalhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022\nlocalhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]\nlocalhost kernel: Call Trace:\nlocalhost kernel: dump_stack_lvl+0x57/0x7d\nlocalhost kernel: check_preemption_disabled+0xc8/0xd0\nlocalhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]\n\nUse raw_smp_processor_id() instead of smp_processor_id().\n\nAlso use queue_work() across the driver instead of queue_work_on() thus\navoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1a541999f31fcb10ea50eba2a563e6c451fd5c7d","https://git.kernel.org/stable/c/25bd0c7def04a272f8e89b36971712fe29c6e438","https://git.kernel.org/stable/c/52c7b41ad6ee53222f4ee2f0c099a6ed8291a168","https://git.kernel.org/stable/c/59f10a05b5c7b675256a66e3161741239889ff80"],"published_time":"2025-10-01T12:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53531","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnull_blk: fix poll request timeout handling\n\nWhen doing io_uring benchmark on /dev/nullb0, it's easy to crash the\nkernel if poll requests timeout triggered, as reported by David. [1]\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:null_timeout_rq+0x4e/0x91\nCall Trace:\n ? null_timeout_rq+0x4e/0x91\n blk_mq_handle_expired+0x31/0x4b\n bt_iter+0x68/0x84\n ? bt_tags_iter+0x81/0x81\n __sbitmap_for_each_set.constprop.0+0xb0/0xf2\n ? __blk_mq_complete_request_remote+0xf/0xf\n bt_for_each+0x46/0x64\n ? __blk_mq_complete_request_remote+0xf/0xf\n ? percpu_ref_get_many+0xc/0x2a\n blk_mq_queue_tag_busy_iter+0x14d/0x18e\n blk_mq_timeout_work+0x95/0x127\n process_one_work+0x185/0x263\n worker_thread+0x1b5/0x227\n\nThis is indeed a race problem between null_timeout_rq() and null_poll().\n\nnull_poll()\t\t\t\tnull_timeout_rq()\n  spin_lock(&nq->poll_lock)\n  list_splice_init(&nq->poll_list, &list)\n  spin_unlock(&nq->poll_lock)\n\n  while (!list_empty(&list))\n    req = list_first_entry()\n    list_del_init()\n    ...\n    blk_mq_add_to_batch()\n    // req->rq_next = NULL\n\t\t\t\t\tspin_lock(&nq->poll_lock)\n\n\t\t\t\t\t// rq->queuelist->next == NULL\n\t\t\t\t\tlist_del_init(&rq->queuelist)\n\n\t\t\t\t\tspin_unlock(&nq->poll_lock)\n\nFix these problems by setting requests state to MQ_RQ_COMPLETE under\nnq->poll_lock protection, in which null_timeout_rq() can safely detect\nthis race and early return.\n\nNote this patch just fix the kernel panic when request timeout happen.\n\n[1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5a26e45edb4690d58406178b5a9ea4c6dcf2c105","https://git.kernel.org/stable/c/a0b4a0666beacfe8add9c71d8922475541dbae73","https://git.kernel.org/stable/c/a7cb2e709f2927cc3c76781df3e45de2381b3b9d"],"published_time":"2025-10-01T12:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53532","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix deinitialization of firmware resources\n\nCurrently, in ath11k_ahb_fw_resources_init(), iommu domain\nmapping is done only for the chipsets having fixed firmware\nmemory. Also, for such chipsets, mapping is done only if it\ndoes not have TrustZone support.\n\nDuring deinitialization, only if TrustZone support is not there,\niommu is unmapped back. However, for non fixed firmware memory\nchipsets, TrustZone support is not there and this makes the\ncondition check to true and it tries to unmap the memory which\nwas not mapped during initialization.\n\nThis leads to the following trace -\n\n[   83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008\n[   83.259537] Modules linked in: ath11k_ahb ath11k qmi_helpers\n.. snip ..\n[   83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   83.287228] pc : __iommu_unmap+0x30/0x140\n[   83.293907] lr : iommu_unmap+0x5c/0xa4\n[   83.298072] sp : ffff80000b3abad0\n.. snip ..\n[   83.369175] Call trace:\n[   83.376282]  __iommu_unmap+0x30/0x140\n[   83.378541]  iommu_unmap+0x5c/0xa4\n[   83.382360]  ath11k_ahb_fw_resource_deinit.part.12+0x2c/0xac [ath11k_ahb]\n[   83.385666]  ath11k_ahb_free_resources+0x140/0x17c [ath11k_ahb]\n[   83.392521]  ath11k_ahb_shutdown+0x34/0x40 [ath11k_ahb]\n[   83.398248]  platform_shutdown+0x20/0x2c\n[   83.403455]  device_shutdown+0x16c/0x1c4\n[   83.407621]  kernel_restart_prepare+0x34/0x3c\n[   83.411529]  kernel_restart+0x14/0x74\n[   83.415781]  __do_sys_reboot+0x1c4/0x22c\n[   83.419427]  __arm64_sys_reboot+0x1c/0x24\n[   83.423420]  invoke_syscall+0x44/0xfc\n[   83.427326]  el0_svc_common.constprop.3+0xac/0xe8\n[   83.430974]  do_el0_svc+0xa0/0xa8\n[   83.435659]  el0_svc+0x1c/0x44\n[   83.438957]  el0t_64_sync_handler+0x60/0x144\n[   83.441910]  el0t_64_sync+0x15c/0x160\n[   83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0)\n[   83.449903] ---[ end trace 0000000000000000 ]---\n\nThis can be reproduced by probing an AHB chipset which is not\nhaving a fixed memory region. During reboot (or rmmod) trace\ncan be seen.\n\nFix this issue by adding a condition check on firmware fixed memory\nhw_param as done in the counter initialization function.\n\nTested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0324300dce3412d4737b4ec5898d0188495a7caa","https://git.kernel.org/stable/c/5a78ac33e3cb8822da64dd1af196e83664b332b0","https://git.kernel.org/stable/c/8faf862d81ab197757761e87d0a99fbb96ab2cf0","https://git.kernel.org/stable/c/a1548363582a8066edd4986f839d785f13dda3aa"],"published_time":"2025-10-01T12:15:57","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53518","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Fix leak in devfreq_dev_release()\n\nsrcu_init_notifier_head() allocates resources that need to be released\nwith a srcu_cleanup_notifier_head() call.\n\nReported by kmemleak.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00014,"ranking_epss":0.02603,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/111bafa210ae546bee7644be730c42df9c35b66e","https://git.kernel.org/stable/c/1640e9c72173911ad0fddb05012c01eafe082c4e","https://git.kernel.org/stable/c/29811f4b8255d4238cf326f3bb7129784766beab","https://git.kernel.org/stable/c/3354c401c68d70567d1ef25d12f4e22a7813a3c6","https://git.kernel.org/stable/c/5693d077595de721f9ddbf9d37f40e5409707dfe","https://git.kernel.org/stable/c/64e6e0dc2d578c0a9e31cb4edd719f0a3ed98f6d","https://git.kernel.org/stable/c/7462483446cb9986568ad7adae746ce5f18d2968","https://git.kernel.org/stable/c/8918025feb2f5f7c73f2495c158f22997e25cb02","https://git.kernel.org/stable/c/ab192e5e5d3b48415909a8408acfd007a607bcc0"],"published_time":"2025-10-01T12:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53519","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-mem2mem: add lock to protect parameter num_rdy\n\nGetting below error when using KCSAN to check the driver. Adding lock to\nprotect parameter num_rdy when getting the value with function:\nv4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.\n\nkworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue\nkworker/u16:3: [name:report&]\n\nkworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:\nkworker/u16:3:  v4l2_m2m_buf_queue+0xd8/0x10c","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01473,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1676748aa29099fc0abd71e0fb092e76e835f25c","https://git.kernel.org/stable/c/56b5c3e67b0f9af3f45cf393be048ee8d8a92694","https://git.kernel.org/stable/c/690dd4780b3f4d755e4e7883e8c3d1b5052f6bf2","https://git.kernel.org/stable/c/7fc7f87725805197388ba749a1801df33000fa50","https://git.kernel.org/stable/c/c71aa5f1cf961264690f2560503ea396b6e3c680","https://git.kernel.org/stable/c/e01ea1c4191ee08440b5f86db98dff695e9cedf9","https://git.kernel.org/stable/c/e52de26cb37459b16213438a2c82feb155dd3bbd","https://git.kernel.org/stable/c/ef009fe2010ea2a3a7045ecb72729cf366e0967b"],"published_time":"2025-10-01T12:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53520","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere's the call trace:\n  <4>[102152.653246] Call Trace:\n  <4>[102152.653254]  hci_suspend_sync+0x109/0x301 [bluetooth]\n  <4>[102152.653259]  hci_suspend_dev+0x78/0xcd [bluetooth]\n  <4>[102152.653263]  hci_suspend_notifier+0x42/0x7a [bluetooth]\n  <4>[102152.653268]  notifier_call_chain+0x43/0x6b\n  <4>[102152.653271]  __blocking_notifier_call_chain+0x48/0x69\n  <4>[102152.653273]  __pm_notifier_call_chain+0x22/0x39\n  <4>[102152.653276]  pm_suspend+0x287/0x57c\n  <4>[102152.653278]  state_store+0xae/0xe5\n  <4>[102152.653281]  kernfs_fop_write+0x109/0x173\n  <4>[102152.653284]  __vfs_write+0x16f/0x1a2\n  <4>[102152.653287]  ? selinux_file_permission+0xca/0x16f\n  <4>[102152.653289]  ? security_file_permission+0x36/0x109\n  <4>[102152.653291]  vfs_write+0x114/0x21d\n  <4>[102152.653293]  __x64_sys_write+0x7b/0xdb\n  <4>[102152.653296]  do_syscall_64+0x59/0x194\n  <4>[102152.653299]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.","cvss":4.7,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":4.7,"epss":0.00013,"ranking_epss":0.02043,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/06e2b5ad72b60f90bfe565c201346532e271f484","https://git.kernel.org/stable/c/573ebae162111063eedc6c838a659ba628f66a0f","https://git.kernel.org/stable/c/e1fa25a91091bbed691ba2996a6cee809e3309a2","https://git.kernel.org/stable/c/f9c8ce5d665653e3cf71a76349d41d7a7f7947e6"],"published_time":"2025-10-01T12:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53521","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix slab-out-of-bounds in ses_intf_remove()\n\nA fix for:\n\nBUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]\nRead of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013\n\nWhen edev->components is zero, accessing edev->component[0] members is\nwrong.","cvss":7.1,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.1,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/0595cdb587726b4f0fa780eb7462e3679d141e82","https://git.kernel.org/stable/c/2fb1fa8425cce2dc4dce298275d22d7077694b73","https://git.kernel.org/stable/c/40af9a6deed723485e05b7d3255a28750692e8db","https://git.kernel.org/stable/c/578797f0c8cbc2e3ec5fc0dab87087b4c7073686","https://git.kernel.org/stable/c/76f7050537476ac062ec23a544fbca8270f2d08b","https://git.kernel.org/stable/c/82143faf01dda831b89eccef60c39ef8575ab08a","https://git.kernel.org/stable/c/87e47be38d205df338c52ead43f23b2864567423","https://git.kernel.org/stable/c/8f9542cad6c27297c8391de3a659f0b7948495d0"],"published_time":"2025-10-01T12:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53522","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup,freezer: hold cpu_hotplug_lock before freezer_mutex\n\nsyzbot is reporting circular locking dependency between cpu_hotplug_lock\nand freezer_mutex, for commit f5d39b020809 (\"freezer,sched: Rewrite core\nfreezer logic\") replaced atomic_inc() in freezer_apply_state() with\nstatic_branch_inc() which holds cpu_hotplug_lock.\n\ncpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex\n\n  cgroup_file_write() {\n    cgroup_procs_write() {\n      __cgroup_procs_write() {\n        cgroup_procs_write_start() {\n          cgroup_attach_lock() {\n            cpus_read_lock() {\n              percpu_down_read(&cpu_hotplug_lock);\n            }\n            percpu_down_write(&cgroup_threadgroup_rwsem);\n          }\n        }\n        cgroup_attach_task() {\n          cgroup_migrate() {\n            cgroup_migrate_execute() {\n              freezer_attach() {\n                mutex_lock(&freezer_mutex);\n                (...snipped...)\n              }\n            }\n          }\n        }\n        (...snipped...)\n      }\n    }\n  }\n\nfreezer_mutex => cpu_hotplug_lock\n\n  cgroup_file_write() {\n    freezer_write() {\n      freezer_change_state() {\n        mutex_lock(&freezer_mutex);\n        freezer_apply_state() {\n          static_branch_inc(&freezer_active) {\n            static_key_slow_inc() {\n              cpus_read_lock();\n              static_key_slow_inc_cpuslocked();\n              cpus_read_unlock();\n            }\n          }\n        }\n        mutex_unlock(&freezer_mutex);\n      }\n    }\n  }\n\nSwap locking order by moving cpus_read_lock() in freezer_apply_state()\nto before mutex_lock(&freezer_mutex) in freezer_change_state().","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.02916,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/34fbb7b45bae20b551dda24337c7761ca13ce69d","https://git.kernel.org/stable/c/3756171b97c307d9df8b8ded1d883eec30172085","https://git.kernel.org/stable/c/57dcd64c7e036299ef526b400a8d12b8a2352f26"],"published_time":"2025-10-01T12:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53523","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ncan: gs_usb: fix time stamp counter initialization\n\nIf the gs_usb device driver is unloaded (or unbound) before the\ninterface is shut down, the USB stack first calls the struct\nusb_driver::disconnect and then the struct net_device_ops::ndo_stop\ncallback.\n\nIn gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more\nRX'ed CAN frames are send from the USB device to the host. Later in\ngs_can_close() a reset control message is send to each CAN channel to\nremove the controller from the CAN bus. In this race window the USB\ndevice can still receive CAN frames from the bus and internally queue\nthem to be send to the host.\n\nAt least in the current version of the candlelight firmware, the queue\nof received CAN frames is not emptied during the reset command. After\nloading (or binding) the gs_usb driver, new URBs are submitted during\nthe struct net_device_ops::ndo_open callback and the candlelight\nfirmware starts sending its already queued CAN frames to the host.\n\nHowever, this scenario was not considered when implementing the\nhardware timestamp function. The cycle counter/time counter\ninfrastructure is set up (gs_usb_timestamp_init()) after the USBs are\nsubmitted, resulting in a NULL pointer dereference if\ntimecounter_cyc2time() (via the call chain:\ngs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() ->\ngs_usb_skb_set_timestamp()) is called too early.\n\nMove the gs_usb_timestamp_init() function before the URBs are\nsubmitted to fix this problem.\n\nFor a comprehensive solution, we need to consider gs_usb devices with\nmore than 1 channel. The cycle counter/time counter infrastructure is\nsetup per channel, but the RX URBs are per device. Once gs_can_open()\nof _a_ channel has been called, and URBs have been submitted, the\ngs_usb_receive_bulk_callback() can be called for _all_ available\nchannels, even for channels that are not running, yet. As cycle\ncounter/time counter has not set up, this will again lead to a NULL\npointer dereference.\n\nConvert the cycle counter/time counter from a \"per channel\" to a \"per\ndevice\" functionality. Also set it up, before submitting any URBs to\nthe device.\n\nFurther in gs_usb_receive_bulk_callback(), don't process any URBs for\nnot started CAN channels, only resubmit the URB.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00018,"ranking_epss":0.04764,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/210a8cffc9c1b044281c0a868485c870c9c11374","https://git.kernel.org/stable/c/5886e4d5ecec3e22844efed90b2dd383ef804b3a"],"published_time":"2025-10-01T12:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53524","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf\n\nAn integer overflow occurs in the iwl_write_to_user_buf() function,\nwhich is called by the iwl_dbgfs_monitor_data_read() function.\n\nstatic bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,\n\t\t\t\t  void *buf, ssize_t *size,\n\t\t\t\t  ssize_t *bytes_copied)\n{\n\tint buf_size_left = count - *bytes_copied;\n\n\tbuf_size_left = buf_size_left - (buf_size_left % sizeof(u32));\n\tif (*size > buf_size_left)\n\t\t*size = buf_size_left;\n\nIf the user passes a SIZE_MAX value to the \"ssize_t count\" parameter,\nthe ssize_t count parameter is assigned to \"int buf_size_left\".\nThen compare \"*size\" with \"buf_size_left\" . Here, \"buf_size_left\" is a\nnegative number, so \"*size\" is assigned \"buf_size_left\" and goes into\nthe third argument of the copy_to_user function, causing a heap overflow.\n\nThis is not a security vulnerability because iwl_dbgfs_monitor_data_read()\nis a debugfs operation with 0400 privileges.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/059e426d666a41e26b184c177c1ca3ee2d6fa1b6","https://git.kernel.org/stable/c/0ad8dd870aa187d0c21d032bb2c6433559075eec","https://git.kernel.org/stable/c/58d1b717879bfeabe09b35e41ad667c79933eb2e","https://git.kernel.org/stable/c/82f877ec9b041edc4c7c509c605cc3393d837bf0","https://git.kernel.org/stable/c/de78456976026102babe66258c228691ca5677c0","https://git.kernel.org/stable/c/eb1ef44efac797b384d361a76e33f77027c29a14"],"published_time":"2025-10-01T12:15:56","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53511","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix fget leak when fs don't support nowait buffered read\n\nHeming reported a BUG when using io_uring doing link-cp on ocfs2. [1]\n\nDo the following steps can reproduce this BUG:\nmount -t ocfs2 /dev/vdc /mnt/ocfs2\ncp testfile /mnt/ocfs2/\n./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1\numount /mnt/ocfs2\n\nThen umount will fail, and it outputs:\numount: /mnt/ocfs2: target is busy.\n\nWhile tracing umount, it blames mnt_get_count() not return as expected.\nDo a deep investigation for fget()/fput() on related code flow, I've\nfinally found that fget() leaks since ocfs2 doesn't support nowait\nbuffered read.\n\nio_issue_sqe\n|-io_assign_file  // do fget() first\n  |-io_read\n  |-io_iter_do_read\n    |-ocfs2_file_read_iter  // return -EOPNOTSUPP\n  |-kiocb_done\n    |-io_rw_done\n      |-__io_complete_rw_common  // set REQ_F_REISSUE\n    |-io_resubmit_prep\n      |-io_req_prep_async  // override req->file, leak happens\n\nThis was introduced by commit a196c78b5443 in v5.18. Fix it by don't\nre-assign req->file if it has already been assigned.\n\n[1] https://lore.kernel.org/ocfs2-devel/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/T/#t","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00012,"ranking_epss":0.01838,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/10fb2e16ee6ffaf1716b9e90d007e6b300bfa457","https://git.kernel.org/stable/c/54aa7f2330b82884f4a1afce0220add6e8312f8b","https://git.kernel.org/stable/c/75a499fc9d66a32271e2b3e4ca71156e8ad3b484"],"published_time":"2025-10-01T12:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53512","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpt3sas: Fix a memory leak\n\nAdd a forgotten kfree().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/28137ea3eb05a87329a7154a8ff410d9e8bcc0a5","https://git.kernel.org/stable/c/30c7c72b6cf9d8c95f9b219c9d2e4e31b15bebe5","https://git.kernel.org/stable/c/378cc0eec4aa546ce1ae17515e2dfab719d4fb1e","https://git.kernel.org/stable/c/54dd96015e8d7a2a07359e2dfebf05b529d1780c","https://git.kernel.org/stable/c/847cdbdcd5a24c1eec9595161a23b88fef91ff42"],"published_time":"2025-10-01T12:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53513","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix incomplete validation of ioctl arg\n\nWe tested and found an alarm caused by nbd_ioctl arg without verification.\nThe UBSAN warning calltrace like below:\n\nUBSAN: Undefined behaviour in fs/buffer.c:1709:35\nsigned integer overflow:\n-9223372036854775808 - 1 cannot be represented in type 'long long int'\nCPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1\nHardware name: linux,dummy-virt (DT)\nCall trace:\n dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78\n show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x170/0x1dc lib/dump_stack.c:118\n ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161\n handle_overflow+0x188/0x1dc lib/ubsan.c:192\n __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206\n __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709\n block_write_full_page+0x1f0/0x280 fs/buffer.c:2934\n blkdev_writepage+0x34/0x40 fs/block_dev.c:607\n __writepage+0x68/0xe8 mm/page-writeback.c:2305\n write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240\n generic_writepages+0xdc/0x148 mm/page-writeback.c:2329\n blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114\n do_writepages+0xd4/0x250 mm/page-writeback.c:2344\n\nThe reason for triggering this warning is __block_write_full_page()\n-> i_size_read(inode) - 1 overflow.\ninode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize.\nWe think it is necessary to limit the size of arg to prevent errors.\n\nMoreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int.\nAssuming the value of arg is 0x80000000000000001) (on a 64-bit machine),\nit will become 1 after the coercion, which will return unexpected results.\n\nFix it by adding checks to prevent passing in too large numbers.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00013,"ranking_epss":0.02149,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/52851d0c3354b397c11d31dfeb8b2a2fc85a0002","https://git.kernel.org/stable/c/55793ea54d77719a071b1ccc05a05056e3b5e009","https://git.kernel.org/stable/c/fab766c8a1aff715bce7075aab40e780266f8e1a","https://git.kernel.org/stable/c/ffb75ffaa68723276365d0f9d00b03362b750657"],"published_time":"2025-10-01T12:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53514","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpu: host1x: Fix memory leak of device names\n\nThe device names allocated by dev_set_name() need be freed\nbefore module unloading, but they can not be freed because\nthe kobject's refcount which was set in device_initialize()\nhas not be decreased to 0.\n\nAs comment of device_add() says, if it fails, use only\nput_device() drop the refcount, then the name will be\nfreed in kobejct_cleanup().\n\ndevice_del() and put_device() can be replaced with\ndevice_unregister(), so call it to unregister the added\nsuccessfully devices, and just call put_device() to the\nnot added device.\n\nAdd a release() function to device to avoid null release()\nfunction WARNING in device_release(), it's empty, because\nthe context devices are freed together in\nhost1x_memory_context_list_free().","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.03198,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/3ab0f5ddb761270b11d8c90b8550a59666cfc9bb","https://git.kernel.org/stable/c/55879dad0f3ae8468444b42f785ad79eac05fe5b","https://git.kernel.org/stable/c/958c6cbc32996c375af42db96ceba021a1959899","https://git.kernel.org/stable/c/dba1aeaaf3d0e2f996cb0a5609e5e85ecf405a5c"],"published_time":"2025-10-01T12:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53515","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-mmio: don't break lifecycle of vm_dev\n\nvm_dev has a separate lifecycle because it has a 'struct device'\nembedded. Thus, having a release callback for it is correct.\n\nAllocating the vm_dev struct with devres totally breaks this protection,\nthough. Instead of waiting for the vm_dev release callback, the memory\nis freed when the platform_device is removed. Resulting in a\nuse-after-free when finally the callback is to be called.\n\nTo easily see the problem, compile the kernel with\nCONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.\n\nThe fix is easy, don't use devres in this case.\n\nFound during my research about object lifetime problems.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00015,"ranking_epss":0.0312,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/2dcb368fe5a8eee498ca75c93a18ce2f3b0d6a8e","https://git.kernel.org/stable/c/3ff54d904fafabd0912796785e53cce4e69ca123","https://git.kernel.org/stable/c/55c91fedd03d7b9cf0c5199b2eb12b9b8e95281a","https://git.kernel.org/stable/c/5b7d5c2dd664eb8b9a06ecbc06e28d39359c422e","https://git.kernel.org/stable/c/97a2d55ead76358245b446efd87818e919196d7a","https://git.kernel.org/stable/c/af5818c35173e096085c6ae2e3aac605d3d15e41","https://git.kernel.org/stable/c/b788ad3b2468512339c05f23692e36860264e674"],"published_time":"2025-10-01T12:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53516","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF\n\nThe previous commit 954d1fa1ac93 (\"macvlan: Add netlink attribute for\nbroadcast cutoff\") added one additional attribute named\nIFLA_MACVLAN_BC_CUTOFF to allow broadcast cutfoff.\n\nHowever, it forgot to describe the nla_policy at macvlan_policy\n(drivers/net/macvlan.c). Hence, this suppose NLA_S32 (4 bytes) integer\ncan be faked as empty (0 bytes) by a malicious user, which could leads\nto OOB in heap just like CVE-2023-3773.\n\nTo fix it, this commit just completes the nla_policy description for\nIFLA_MACVLAN_BC_CUTOFF. This enforces the length check and avoids the\npotential OOB read.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/55cef78c244d0d076f5a75a35530ca63c92f4426","https://git.kernel.org/stable/c/79f44709aa7a744fbfbadd4aef678443290c6991"],"published_time":"2025-10-01T12:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53517","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: do not update mtu if msg_max is too small in mtu negotiation\n\nWhen doing link mtu negotiation, a malicious peer may send Activate msg\nwith a very small mtu, e.g. 4 in Shuang's testing, without checking for\nthe minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then\nn->links[bearer_id].mtu is set to 4294967228, which is a overflow of\n'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().\n\nWith tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:\n\n tipc: Too large msg, purging xmit list 1 5 0 40 4!\n tipc: Too large msg, purging xmit list 1 15 0 60 4!\n\nAnd with tipc_link_entry.mtu 4294967228, a huge skb was allocated in\nnamed_distribute(), and when purging it in tipc_link_xmit(), a crash\nwas even caused:\n\n  general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19\n  RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0\n  Call Trace:\n   <IRQ>\n   skb_release_data+0xf9/0x1d0\n   kfree_skb_reason+0x40/0x100\n   tipc_link_xmit+0x57a/0x740 [tipc]\n   tipc_node_xmit+0x16c/0x5c0 [tipc]\n   tipc_named_node_up+0x27f/0x2c0 [tipc]\n   tipc_node_write_unlock+0x149/0x170 [tipc]\n   tipc_rcv+0x608/0x740 [tipc]\n   tipc_udp_recv+0xdc/0x1f0 [tipc]\n   udp_queue_rcv_one_skb+0x33e/0x620\n   udp_unicast_rcv_skb.isra.72+0x75/0x90\n   __udp4_lib_rcv+0x56d/0xc20\n   ip_protocol_deliver_rcu+0x100/0x2d0\n\nThis patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),\nand not updating mtu if it is too small.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.0291,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/1dd7ae5e0cf5a56e513f7ab7ab9570b7496281d2","https://git.kernel.org/stable/c/259683001d7e879fea4b42084fb6560dd9408a7e","https://git.kernel.org/stable/c/2bd4ff4ffb92113f8acd04dbaed83269172c24b4","https://git.kernel.org/stable/c/56077b56cd3fb78e1c8619e29581ba25a5c55e86","https://git.kernel.org/stable/c/575e84d90a74c0b091b3417ba763ebb237aa0a8c"],"published_time":"2025-10-01T12:15:55","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53504","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAF\n\nib_dealloc_device() should be called only after device cleanup.  Fix the\ndealloc sequence.","cvss":7.8,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":7.8,"epss":0.00018,"ranking_epss":0.04797,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/5363fc488da579923edf6a2fdca3d3b651dd800b","https://git.kernel.org/stable/c/c95863f6d970ef968e7c1f3c481f72a4b0734654"],"published_time":"2025-10-01T12:15:54","vendor":null,"product":null,"version":null},{"cve_id":"CVE-2023-53505","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nclk: tegra: tegra124-emc: Fix potential memory leak\n\nThe tegra and tegra needs to be freed in the error handling path, otherwise\nit will be leaked.","cvss":5.5,"cvss_version":3.0,"cvss_v2":null,"cvss_v3":5.5,"epss":0.00015,"ranking_epss":0.02965,"kev":false,"propose_action":null,"ransomware_campaign":null,"references":["https://git.kernel.org/stable/c/404e9f741acfb188212f7142d91e247630dd77cc","https://git.kernel.org/stable/c/4e59e355f9fcccd9edf65d09f769bb4c163a1c36","https://git.kernel.org/stable/c/53a06e5924c0d43c11379a08c5a78529c3e61595","https://git.kernel.org/stable/c/801c8341f7aff07c494b53e627970b72635af5d3","https://git.kernel.org/stable/c/96bafece6ff380138896f009141fd7337070e680","https://git.kernel.org/stable/c/e969c144d908ea9387442659f103d374c8ff682d","https://git.kernel.org/stable/c/fd1c117bb5d7e033bf1aa25ac97ff421f81a1199"],"published_time":"2025-10-01T12:15:54","vendor":null,"product":null,"version":null}]}